Open PR fan-in — 2026-05-11

Scratch note for queue inspection, #1787 verification, docs fan-in disposition, and validation record.

Important operating rule (two passes)

Work in two passes. Do not collapse them into one chaotic session.

Pass A — only #1787

• Inspect the PR and CI.
• Reproduce validation (fmt, clippy, targeted tests, guest WASM check).
• Diagnose the benchmark “Compare Against Base” failure (fix workflow, document false positives, or policy label).
• Confirm review-thread invariants remain intact (no weakening).
• Stop with a clean summary.

Do not start Pass B until Pass A is done: #1787 is either green, fixed, or explicitly documented as blocked only by a benchmark-policy decision you accept.

Pass B — #1780–#1786 only after Pass A

• Docs fan-in, truth alignment, handoff notes.
• This handoff’s Phase 3 validation and fan-in branch describe Pass B work already executed in-repo; new sessions should still treat Pass A as the gate if #1787 is not yet merged or benchmark-disposition is unsettled.

No mega-PR (branch hygiene)

Unless there is literally no alternative, do not mix runtime changes (#1787 / icn-baseline-lock, boundary, lockfile) with the docs fan-in on one PR.

Prefer separate branches (and commits), for example:

1. #1787 — runtime stabilization and benchmark disposition only.
2. Docs — docs(project-index): fan in coverage and subsystem maps.
3. Public surfaces — docs(web,pilot-ui): align public demo truth boundaries (or equivalent scope).
4. Handoff — disposition / queue note (docs/handoffs/…).

The fan-in branch docs/open-pr-fanin-1780-1786 in this repo follows that split: it is docs-only relative to main; #1787 stays on baseline-lock-loop.

PR disposition table

#1787 file list (runtime)

• docs/manual/FOUNDATIONAL_MANUAL_EXECUTABLE_BASELINE_LOOP.md
• icn/Cargo.toml, icn/Cargo.lock
• icn/crates/icn-baseline-lock/** (src, tests, README, fixtures WASM)
• icn/crates/icn-baseline-lock-guest/**
• icn/crates/icn-boundary/**
• scripts/build-baseline-lock-guest.sh

Benchmark triage (#1787, run 25672700166)

• Failing job: Benchmarks → Compare Against Base → step Check for regressions (not benchmark execution).
• Root cause: `.github/workflows/benchmark.yml` counts lines matching (Performance has regressed|regressed|change:.*\+[0-9]+\.[0-9]+%). Criterion prints intervals like change: [-0.5% -0.2% +0.03%]; the positive upper bound matches the regex even when the next line is No change in performance detected → many false positives (workflow detection bug).
• Secondary: Lines with explicit Performance has regressed may still reflect CI noise or lockfile indirect effects; triage those separately if reproducing locally matters.
• Bypass (do not apply unless instructed): PR label perf-regression-ok per workflow.
• PR comment draft (post to #1787 when ready): see Appendix A below.

Appendix A — Draft PR comment for #1787 (benchmark gate)

The Benchmarks workflow failed only on Compare Against Base → Check for regressions (not on running benches). The step counts lines matching a broad regex in `.github/workflows/benchmark.yml` (see REGRESSION_COUNT / grep around lines 146–177). Criterion prints confidence intervals such as change: [-0.5% -0.2% +0.03%]; the positive upper bound matches change:.*\+[0-9]+\.[0-9]+% even when the following line is No change in performance detected, which inflates the regression count (for example 79 matches on this PR). Treat most hits as false positives until the workflow is tightened. Any line that explicitly says Performance has regressed still deserves a quick human look; some may be CI noise after Cargo.lock churn. Merge options: add label perf-regression-ok (repo-defined bypass) or land a small follow-up PR to fix the detection regex.

Phase 2 — Local verification (#1787)

Branch: baseline-lock-loop (local matches PR #1787).

Review invariants (covered by tests + projector.rs / host.rs; do not weaken): vote signer vs member_pubkey; input vs executed module_hash; duplicate vote semantics; MissingReservation vs ReservationConsumed; non-vote receipt signer authority (BaselineFixtureAuthority).

GitHub reviews: no APPROVED / CHANGES_REQUESTED blocking state in API snapshot; Codex/Copilot commented; human threads empty in summary.

Phase 3 — Docs validation

Edits on fan-in (beyond raw merges): shortened `remote-work-plan.md` to a superseded pointer; extended `project-index/README.md` map table; linked #1787 from `GOVERNANCE_PROPOSAL_FIXTURE_HANDOFF.md`; allowlisted docs/handoffs/ in `registry.toml`; aligned GOVERNANCE YAML Status with docs/demo/ registry defaults.

Canonical constraints (edit pass)

• Phase 0–1 complete; Phase 2 in progress / partner-bound (not “complete”).
• NYCN = partnership track unless canonical doc explicitly says “pilot”.
• No overclaim: live federation, production readiness, full mobile UX, Tool Commons live, service hosting implemented, formal pilot, fully fixture-backed demo — unless code/tests back it.
• Vocabulary: obligation, allocation, settlement, unit, position, receipt, provenance; avoid misleading payment/currency/balance/wallet in current-facing copy.

Final disposition summary

Merge order suggestion: land #1787 first if you want demo docs to cite merged baseline-lock on main; otherwise merge fan-in first and rebase #1787 doc links—either order works because links use PR URL for #1787 until merged.