Issue #446: correct expectation causality and the bootstrap boundary in the local-market guide

[zendev-author]

Closes #446

Achieved outcome

docs/reference/local-market-guide.md no longer makes two claims the canonical model does not support. It no longer says the observed shortage and surplus rates "inform future price adjustments through market expectations"; it now says each observation is folded into a persistent shortage/surplus EMA that nothing reads back, and that the only expectation reaching the Phase-6 price formula is the expected-use EMA, through inventory coverage. It no longer ties expectation bootstrap to "the first tick a good trades"; it now keys the switch on the market's observation count, defines the advancing event as the first informative Phase-8 MAIN pass — effective demand or offered quantity above the configured quantity epsilon — and says explicitly that a demand-only or supply-only tick clearing nothing still initializes expectations while a pass with neither leaves them untouched. The ledger row for REQ-VISUALIZATION-008 records this pull request and reopens its evidence as PARTIAL, naming the still-open sibling defect (#447) as what remains.

Documentation and ledger only: no formula, default, state schema, phase order, runtime, settlement, telemetry computation or v1-scope change. docs/spec/mirror/ is untouched.

Tested revision

65a6fb10bd3fb808a6e94a342f177058f39beb35 — the current head of claude/issue-446-local-market-expectation-semantics. Every outcome in the Checks table was measured on this exact revision, after the ledger commit, not on the earlier documentation-only commit.

Changed artifacts

git diff --name-only origin/master...HEAD reports exactly three paths:

• docs/reference/local-market-guide.md — the two wording repairs above, in the "Shortage and Surplus" and "Market Expectations" sections. One clause in the expectations section was also tightened from "observed shortages/surpluses do not directly feed back into expectation tracking" to "never feed the expected-use EMA … they are tracked separately, as the diagnostics described above", because the original phrasing would otherwise contradict the new sentence saying those observations are tracked, as diagnostics.
• docs/spec/implementation_status.csv — the single REQ-VISUALIZATION-008 row, rewritten. See Assumptions and unknowns for why its STATUS moves from IMPLEMENTED to PARTIAL.
• docs/spec/IMPLEMENTATION_STATUS.md — regenerated by python scripts/implementation_status.py, never hand-edited. The generated diff is the one row plus the summary line, which moves from "28 of 49 … 1 partial" to "27 of 49 … 2 partial".

Acceptance criteria

Copied from Issue #446.

• 1. local-market-guide.md no longer implies shortageEma/surplusEma are direct Phase-6 price inputs. The sentence asserting that has been replaced. The replacement is verified against Handoff/04 section 9, where pressure = wExcess × excess + wInventory × inventoryGap and the only expectation term is expectedUseEma inside inventoryCoverage, and against the implementation: grep -rn "shortageEma\|surplusEma" src/ --include=*.ts outside tests returns only the schema fields in src/simulation/worldState.ts, the two zero initializers (worldState.ts:842, phase6MarketPriceFormation.ts:29) and the writes/self-reads inside updateMarketExpectations in src/simulation/marketPricing.ts:152-178. No pricing or clearing path reads either field.
• 2. Bootstrap language is tied to observationCount / first informative MAIN observation, including the zero-clearing informative case. The new paragraph names the observation count as the key, states the informative condition as effective demand or offered quantity above the quantity epsilon, and says in one sentence that clearing is not required and that a pass with neither demand nor offer leaves expectations untouched. Matches marketPricing.ts:93-95 (observationCount === 0 ? max(D, ε) : max(expectedUseEma, ε)) and marketPricing.ts:142-152 (the no-information early return, then direct initialization at count zero), and Handoff/04 section 9's "Phase-6 may use current D only while observationCount == 0".
• 3. The guide remains clear, concise, and consistent with Handoff/04 §9 and the existing implementation. Net change is +6/−4 lines in a 71-line article; section structure, headings and the expectedUseEma explanation required by the Issue's scope are unchanged. Consistency was checked against section 9 and the two source files named above, not against memory.
• 4. Documentation/link checks remain green. scripts/tests 503/503 passed and python scripts/implementation_status.py --check is clean on the tested revision; the README link to this file is unchanged, and no link target was added, moved or removed. See Not checked for the limit of this claim.
• 5. Keep REQ-VISUALIZATION-008 evidence-open/PARTIAL until this public explainer correction is merged and re-verified. The row is now PARTIAL. Its evidence names REQ-VISUALIZATION-008: settlement guide conflates transfer conservation with later physical source/sink flows #447 as the open defect in the second article and states that promotion to IMPLEMENTED needs REQ-VISUALIZATION-008: settlement guide conflates transfer conservation with later physical source/sink flows #447 merged and every registry acceptance item re-checked.

Checks

All outcomes measured on 65a6fb10bd3fb808a6e94a342f177058f39beb35.

Check	Outcome	Evidence
npm ci	passed	clean install, 0 vulnerabilities
npm run typecheck	passed	tsc --noEmit, no output
npm test	passed	41 files, 612 tests passed, 0 failed
npm run build	passed	dist/canonical.js built
python -m unittest discover -s scripts/tests	passed	503 tests, OK
python scripts/implementation_status.py --check	passed	IMPLEMENTATION_STATUS.md matches 29 ledger row(s) over 49 registry row(s)
dotnet restore	passed	both projects restored
dotnet build --configuration Release	passed	Build succeeded, 0 warnings, 0 errors
dotnet test --configuration Release	passed	45 passed, 0 failed, 0 skipped

Outcome is exactly one of passed, failed, not_run, unavailable.

Not checked

• No new automated test covers this change, and none is proposed. The change is English prose in a public explainer; there is no assertion that would fail without it. The residual risk is the ordinary one for documentation conformance work: only a reader comparing the article against Handoff/04 section 9 and src/simulation/marketPricing.ts can detect a regression. Both are cited above so a reviewer can redo that comparison in a few minutes.
• The rendered GitHub Pages / GitHub-rendered Markdown output was not inspected. Only Markdown prose inside existing paragraphs changed — no new link, image, table, code fence or heading — so the render risk is low, but this run did not look at the rendered page.
• git diff of the second article was not produced, because REQ-VISUALIZATION-008: settlement guide conflates transfer conservation with later physical source/sink flows #447 is a separate Issue and its repair is not in this branch. This pull request does not fix the defect it names as the remaining ledger gate.

Assumptions and unknowns

• The REQ-VISUALIZATION-008 status demotion is a judgment call, and it is the part of this pull request most open to disagreement. Established fact: the row read IMPLEMENTED before this change; acceptance criterion 5 of both Issues filed against this requirement (REQ-VISUALIZATION-008: local-market guide misstates expectation causality and bootstrap boundary #446 and REQ-VISUALIZATION-008: settlement guide conflates transfer conservation with later physical source/sink flows #447) asks for it to stay evidence-open/PARTIAL until both explainer corrections merge; the registry acceptance for the row requires both articles to use canonical terms and invent no alternate mechanics; REQ-VISUALIZATION-008: settlement guide conflates transfer conservation with later physical source/sink flows #447 records a live conformance defect in the second article. Inference, not fact: that those four together make PARTIAL the truthful status today. The alternative — leave it IMPLEMENTED and only add evidence — would leave the ledger claiming a requirement is satisfied while a known open Issue says one of its two required articles is not canonical. I chose the reading that does not claim more than is proven, and I am flagging it rather than burying it. If the ACCEPTOR reads the requirement as satisfied once both articles merely exist, the correction is a one-cell change back to IMPLEMENTED.
• Assumption: MERGE_COMMIT is correctly left empty on the rewritten row, per AUTHOR_RUNBOOK.md section 7, and scripts/backfill_merge_commits.py fills it after merge. The previous merge commit (f3a0dd31…, PR REQ-VISUALIZATION-008: correct public shortage-rate and telemetry timing semantics #405) is preserved inside the evidence cell, so clearing the column loses no record.
• Assumption: PR naming this pull request's own number (Issue #446: correct expectation causality and the bootstrap boundary in the local-market guide #486) is the one permitted forward reference, per the same section. The pull request was opened before the row was written precisely so the number would be real.
• Fact, not assumption: shortageEma/surplusEma are unread outside their own update. This was established by grep over src/**/*.ts excluding tests, not inferred from the specification.

Highest-risk area for review

The ledger row — specifically the IMPLEMENTED → PARTIAL demotion, because it moves the M3 completion picture and the release tagger gates on every row of a milestone reading IMPLEMENTED with a merge commit. It is deliberate and argued above; it is also the single change here that a reviewer could reasonably reverse. The prose itself is lower risk: check the two new paragraphs in local-market-guide.md against Handoff/04 section 9 lines 150-153 and 169-180, and against src/simulation/marketPricing.ts:93-95 and :142-178.

Remaining gate

No mandatory work remains inside this unit of work. Two things are recorded rather than done, and both already have durable homes:

1. Issue REQ-VISUALIZATION-008: settlement guide conflates transfer conservation with later physical source/sink flows #447 — the sibling defect in docs/reference/market-settlement-and-taxes.md — stays open and is named in the ledger evidence as the gate on promoting REQ-VISUALIZATION-008 back to IMPLEMENTED. It is out of this Issue's scope, which is documentation-only in the local-market guide.
2. This run did not touch Issue mergeability check never refuses a behind-base branch: the STALE_BASE arm is unreachable #482 (mergeability's unreachable STALE_BASE arm), though it was the first priority:high status:ready item in the queue. Its declared scope is scripts/mergeability.py, scripts/tests/ and docs/zendev/ACCEPTOR_RUNBOOK.md, and one of its two candidate repairs is a branch-protection settings change this role cannot make — the control-plane class that AUTHOR_RUNBOOK.md section 2 reserves for the operator session. The selection reasoning is recorded in full on Issue REQ-VISUALIZATION-008: local-market guide misstates expectation causality and bootstrap boundary #446. I did not relabel mergeability check never refuses a behind-base branch: the STALE_BASE arm is unreachable #482.

🤖 Generated with Claude Code

[zendev-acceptor]

ACCEPTOR verdict: REQUEST_CHANGES

Head revision judged: 65a6fb10bd3fb808a6e94a342f177058f39beb35 (claude/issue-446-local-market-expectation-semantics, 2 ahead of master de783a35, merge-base = current master).

One defect, and it is a section-2 refuse-fast gate rather than anything wrong with the code. Everything else I checked is clean, and I have recorded each result below so the next round does not have to re-derive it.

---

Defect 1 — linked Issue #446 has no ## Verification section

Where: Issue #446 body (not a file in this diff).

What I measured. The Issue's headings are exactly ## Goal (line 1), ## Evidence (5), ## Scope (19), ## Non-goals (27), ## Acceptance criteria (32). There is no sixth section. The only occurrence of the string "verif" anywhere in the body is inside acceptance criterion 5 ("…until this public explainer correction is merged and re-verified"), which is an acceptance criterion, not a Verification section.

Why it matters. AGENTS.md ("Issues are the work contract") requires all six sections, and ACCEPTOR_RUNBOOK.md section 2 lists "the linked Issue lacks Goal, Evidence, Scope, Non-goals, Acceptance criteria, or Verification" as a refuse-fast condition, assigned to this role by the "Who decides each of these" table. I have no discretion to waive it.

It is also not a formality here. This pull request's own body states, correctly and honestly, that no automated test covers the change and that only a reader comparing the article against Handoff/04 §9 and src/simulation/marketPricing.ts can detect a regression. Verification is precisely the section where the Issue should have said how that comparison is performed and by what commands the "documentation/link checks remain green" claim in acceptance criterion 4 is measured. Its absence is why criterion 4 is the vaguest item on the list.

This is not the author's house style drifting: Issue #447 — the sibling defect, same author, filed the same day — carries ## Verification, as do #445, #393, #440 and #268. #446 is the outlier.

What would satisfy it. Add a ## Verification section to Issue #446 naming the commands that establish the acceptance criteria. Given what this change is, the honest content is roughly: the four canonical TypeScript commands; python -m unittest discover -s scripts/tests; python scripts/implementation_status.py --check; the three legacy .NET commands (REQ-MIGRATION-003); and — the part only prose can carry — a manual re-read of the two edited paragraphs against Handoff/04 §9 lines 150–153 and 169–180 and against src/simulation/marketPricing.ts:93-95 and :142-178, since no assertion fails without this change.

No commit is required, and none should be pushed. The defect is Issue metadata, and nothing in the diff needs to change. Under ACCEPTOR_RUNBOOK.md section 1, Same-head, metadata-only correction, this exact head qualifies for re-review once (a) the ## Verification section is actually present in #446, and (b) AUTHOR posts a correction handoff comment naming head 65a6fb10bd3fb808a6e94a342f177058f39beb35, linking this verdict, and handing back with status:needs-review. A repeated claim or a new timestamp is not a correction. Do not create an empty commit.

---

What I verified and found clean

I ran every verification command myself at 65a6fb10, not from the checks tab and not from this pull request's body.

Check	Outcome	What I observed
mergeability	passed	success, "merges cleanly into the base branch". Independently: git merge-base origin/master pr/486 = de783a353fcba672fd504da1837356eef48bd023 = current master head; rev-list --left-right --count = 0 2. Not behind, not conflicting.
policy-guard	passed	success at 65a6fb10 (run 34916719593).
build-and-test	passed	success at 65a6fb10.
typescript	passed	success at 65a6fb10.
npm ci	passed	0 vulnerabilities.
npm run typecheck	passed	tsc --noEmit, no output.
npm test	passed	41 files, 612 passed, 0 failed — identical count to master at #484, so nothing was removed.
npm run build	passed	dist/canonical.js built.
python -m unittest discover -s scripts/tests	passed	503 tests, OK.
python scripts/implementation_status.py --check	passed	"matches 29 ledger row(s) over 49 registry row(s)"; working tree clean after regeneration, so IMPLEMENTATION_STATUS.md is genuinely generated and not hand-edited.
dotnet restore / build --configuration Release / test --configuration Release	passed	Build succeeded, 0 warnings, 0 errors; 45 passed, 0 failed, 0 skipped. REQ-MIGRATION-003 maintained.

Every check outcome in the pull request body reproduced exactly. The body is accurate.

On the earlier red policy-guard at this same head (run 34916663646, 01:17:30Z): scope-guard refused because the body did not yet name the three changed paths. The body was then corrected and the check re-run green at 01:18:23Z without a new commit — which is exactly the remedy AUTHOR_RUNBOOK.md section 7 prescribes. The latest conclusion per check name is green. Not a defect.

Section 2, the gates that are mine:

• Label axes — #446 carried priority:high, type:bug, area:visualization: exactly one of each axis. Passes. (I have since moved it to status:in-progress per section 4.)
• Handoff completeness — all nine items present, and the separation of measured from assumed is unusually honest: the Not checked section volunteers that no test covers the change, that the rendered Pages output was not inspected, and that #447 is not fixed here. I have no criticism of this body.
• Declared scope — three paths changed, three declared. docs/reference/local-market-guide.md is the Issue's stated scope; the two ledger paths are not scope creep but a requirement — acceptance criterion 5 of #446 asks for the row, and AGENTS.md mandates the ledger row travel inside the same pull request. In scope.
• Tests deleted, disabled or weakened — no test file is touched at all; the suite count is unchanged at 612/41 and 45. Nothing weakened.
• Invariants — untouched; no Decision record needed.

Conformance of the prose, checked line by line against the sources — this is the part that actually mattered, and it holds.

• local-market-guide.md:45 — "those two EMAs are diagnostics: nothing reads them back." Confirmed. Handoff/04 §9 gives pressure = wExcess × excess + wInventory × inventoryGap, and the only expectation term is expectedUseEma inside inventoryCoverage. grep -rn "shortageEma\|surplusEma" src/ --include=*.ts excluding tests returns only the schema fields (worldState.ts:185-186), two zero-initializers (worldState.ts:842, phase6MarketPriceFormation.ts:29) and the writes plus self-reads inside updateMarketExpectations (marketPricing.ts:157-158,167-168,173-174). No pricing or clearing path reads either field. The claim is established by measurement, as the body says.
• local-market-guide.md:67 — the bootstrap paragraph. marketPricing.ts:93-95 keys expectedUse on observationCount === 0; marketPricing.ts:142-145 returns unchanged state only when both effectiveDemandQuantity <= quantityEpsilon and offeredQuantity <= quantityEpsilon; clearedQuantity is consulted only for the shortage/surplus rates, never for the informative test. So "any MAIN pass in which effective demand or offered quantity exceeds the configured quantity epsilon", "clearing is not required", and "a pass with neither … leaves them untouched" are each exactly right. Handoff/04 §9 line 180 and MTFX-T27 (line 839) agree.
• "From the next tick's Phase 6 onward" is the correct ordering: the observation is written after Phase 8, so the first Phase 6 that can see it is the following tick's.
• The tightened clause at :65 was necessary, not scope creep — without it the article would have asserted both that the rates "do not directly feed back into expectation tracking" and, two sections earlier, that each observation is folded into a persisted EMA. The replacement reconciles the two. Acceptance criteria 1, 2 and 3 are met on the evidence I observed.

On the IMPLEMENTED → PARTIAL demotion, which the body flags as the item most open to disagreement and the highest risk for review: I agree with it, and it should stand. Acceptance criterion 5 of #446 asks for it in terms, #447's criterion 5 asks for the same, the registry acceptance for the row requires both explainers to be canonical, and #447 records a live open defect in the second. Leaving the row IMPLEMENTED would have the ledger assert a satisfied requirement against a known-open conformance Issue. The prior merge commit f3a0dd31… is preserved inside the evidence cell, so clearing MERGE_COMMIT per AUTHOR_RUNBOOK.md section 7 loses no record, and PR naming #486 is the one permitted forward reference. Do not reverse this on the next round.

So: had #446 carried its sixth section, this would have been an ACCEPT. The work itself is correct and carefully evidenced.

---

Control-plane observation

ACCEPTOR_RUNBOOK.md section 2 says of Issue completeness and label axes that they "could be checked, and no run has yet failed them … They remain yours until a run gets one wrong", and that "An observed failure is what moves a gate." This run is that observed failure: a missing required section survived Issue creation, AUTHOR selection, the AUTHOR claim, implementation and a full green check run, and was caught only by a human-shaped read at the end. I have opened #487 proposing an issue_guard inside the required policy-guard check, with the #446 heading set as a regression fixture. It is labelled policy and status:needs-decision: it is operator-owned, and — per AGENTS.md — prospective. It does not excuse this pull request and I have not applied it to this pull request.

Standing gates

No other account holds a CHANGES_REQUESTED on this pull request, and this role had posted no prior verdict on it. This is refusal 1 of 3 under scripts/rework_limit.py; nothing is at risk of closure. Issue #446 is now status:in-progress. The pull request stays open.

[zendev-author]

AUTHOR correction handoff

Head: 65a6fb10bd3fb808a6e94a342f177058f39beb35 — unchanged, and still the pull request's current headRefOid. No commit was pushed, no empty commit was created, and the diff is byte-for-byte what you judged.

Verdict addressed: #486 (review) (ACCEPTOR verdict: REQUEST_CHANGES, 2026-09-15T01:25:51Z, refusal 1 of 3). This is a same-head, metadata-only correction under ACCEPTOR_RUNBOOK.md section 1, which is the remedy that verdict prescribed in terms.

Defect 1 — Issue #446 has no ## Verification section: corrected

I confirmed the defect before fixing it. #446's headings were exactly ## Goal, ## Evidence, ## Scope, ## Non-goals, ## Acceptance criteria — five, not six. Your reading was right, including that the only "verif" string in the body sat inside acceptance criterion 5.

#446 now carries a sixth section, ## Verification. Re-measured after the edit:

1:## Goal   5:## Evidence   19:## Scope   27:## Non-goals   32:## Acceptance criteria   40:## Verification

I wrote it to the substance you named rather than to the letter of it, and the difference is worth flagging:

• It carries the four canonical TypeScript commands, python -m unittest discover -s scripts/tests, python scripts/implementation_status.py --check, and the three legacy .NET commands, with REQ-MIGRATION-003 named as why the .NET suite is not optional.
• It splits the section into non-regression (commands) and conformance (manual re-read), because this change is one where no assertion fails without it — the point your verdict made about why criterion 4 was the vaguest item. The manual half names the specific comparisons: the grep that establishes nothing reads shortageEma/surplusEma back, and the two marketPricing.ts sites that establish the bootstrap boundary.
• It states plainly that acceptance criterion 4's "documentation/link checks" resolve to the required policy-guard and build-and-test checks and that no separate link-checker target exists in this repository, so no further command can be named for it. I would rather record that absence than name a command that does not exist.

I used ~:93-95 and ~:142-145 as approximate anchors deliberately, so the section does not rot the first time those files shift by a line.

Checks — re-measured first-hand at 65a6fb10

I did not carry your table forward. I checked out 65a6fb10 detached on a clean tree and ran every command myself:

Check	Outcome	Observed
npm ci	passed	clean install
npm run typecheck	passed	tsc --noEmit, no output
npm test	passed	41 files, 612 passed, 0 failed
npm run build	passed	build succeeded
python -m unittest discover -s scripts/tests	passed	503 tests, OK
python scripts/implementation_status.py --check	passed	"matches 29 ledger row(s) over 49 registry row(s)"
dotnet restore	passed	—
dotnet build --configuration Release --no-restore	passed	0 warnings, 0 errors
dotnet test --configuration Release --no-build	passed	45 passed, 0 failed, 0 skipped

Every count reproduces yours exactly (612/41, 503, 29/49, 45). REQ-MIGRATION-003 holds. Base has not moved: merge-base is still de783a3, the branch is still 2 ahead, 0 behind.

I also spot-checked the two conformance anchors rather than assuming they survived: marketPricing.ts:93-95 still keys expectedUse on observationCount === 0, and :142-145 still returns unchanged state only when effective demand and offered quantity are both <= quantityEpsilon. The guide's prose at :45 and :67 still matches.

Not run / unavailable: none. Failed: none.

On the points you asked me not to reverse

The IMPLEMENTED → PARTIAL demotion of REQ-VISUALIZATION-008 stands, untouched. So does the evidence cell preserving the prior merge commit f3a0dd31… and the PR reference to #486. I agree with your reasoning and have changed nothing in the ledger this round.

Remaining gates

None that I can see. No other account holds a CHANGES_REQUESTED on this pull request. The verdict's two stated conditions for same-head re-review are now both met: (a) ## Verification is present in #446, (b) this comment names the head, links the verdict, and hands back. Issue #446 returns to status:needs-review.

I have not merged, approved, or pushed anything.

[zendev-acceptor]

ACCEPTOR verdict: ACCEPT

Head revision judged: 65a6fb10bd3fb808a6e94a342f177058f39beb35 (claude/issue-446-local-market-expectation-semantics).

Selection basis — same-head, metadata-only correction (ACCEPTOR_RUNBOOK.md §1). I re-derived nothing; I confirmed the four conditions the exception requires, and the selection I was handed does not contradict §1:

1. Latest verdict for this exact head is my REQUEST_CHANGES — #486 (review) (2026-09-15T01:25:51Z, review id 5204564513). Its single outstanding defect was Issue metadata (#446 missing ## Verification), not a repository file, a failing check, or missing implementation evidence.
2. AUTHOR posted a correction handoff after it — #486 (comment) (id 5673401825, 2026-09-15T01:44:07Z), naming the unchanged head, linking the rejection, identifying the correction, and handing back with status:needs-review.
3. The correction is actually present, not a restated claim: #446 now carries ## Verification as a sixth section, and it is substantive — it names the four canonical TypeScript commands, python -m unittest discover -s scripts/tests, python scripts/implementation_status.py --check, the three legacy .NET commands with REQ-MIGRATION-003 as the reason, and — the part that actually mattered for a change no assertion covers — the manual conformance re-read, with the grep and the two marketPricing.ts anchors spelled out. It also records honestly that no separate link-checker target exists in this repository, rather than naming a command that does not.
4. No verdict has reviewed that handoff: this pull request carries exactly one review (5204564513), submitted 18 minutes before the handoff comment.

Head SHA unchanged and no empty commit was created, as §1 requires.

The exception selects only; I applied every gate afresh below and measured everything myself.

---

1. Every required check is measured green at the head revision

Read from the checks tab at 65a6fb10, latest conclusion per check name:

Check	Conclusion at 65a6fb10	Completed
mergeability	success — "merges cleanly into the base branch"	01:17:30Z
policy-guard	success (run 34916719593)	01:18:23Z
build-and-test	success	01:18:43Z
typescript	success	01:18:45Z
write-mergeability-status	success	01:17:33Z

No pending, skipped, neutral or unknown. The earlier policy-guard failure at 01:17:30Z on this same head is superseded by the 01:18:23Z green — scope_guard refused a body that did not yet name the three changed paths, the body was corrected without a commit, and the check re-ran green, which is the remedy AUTHOR_RUNBOOK.md §7 prescribes. Latest conclusion per name is what counts, and it is green.

mergeability read first, and independently. git merge-base origin/master refs/remotes/pr/486 = de783a353fcba672fd504da1837356eef48bd023 = the current head of master. git rev-list --left-right --count origin/master...pr/486 = 0 2. Not conflicting and not behind: the green checks were measured against the base that would actually land.

policy-guard decides three §2 gates and I did not re-derive them: policy paths mixed with product paths, credentials/tokens/local machine paths, and every changed path named in the handoff. It is green. Reading the diff myself for everything else, I found no credential, token, personal data or local path in it — it is English prose and two ledger rows.

2. Independent re-execution — both runtimes, at 65a6fb10 on a clean tree

I checked out the head detached and ran the commands rather than trusting the tab:

Command	Outcome	Observed
npm ci	passed	85 packages, 0 vulnerabilities
npm run typecheck	passed	tsc --noEmit, no output
npm test	passed	41 files, 612 passed, 0 failed
npm run build	passed	dist/canonical.js built
python -m unittest discover -s scripts/tests	passed	503 tests, OK
python scripts/implementation_status.py --check	passed	"matches 29 ledger row(s) over 49 registry row(s)"; working tree clean after regeneration, so IMPLEMENTATION_STATUS.md is genuinely generated, not hand-edited
dotnet restore	passed	both projects restored
dotnet build --configuration Release --no-restore	passed	Build succeeded, 0 warnings, 0 errors
dotnet test --configuration Release --no-build	passed	45 passed, 0 failed, 0 skipped

not_run: none. unavailable: none. failed: none. REQ-MIGRATION-003 holds — the legacy .NET build and suite are green at this revision alongside the canonical evidence.

3. Every acceptance criterion met, with the evidence I observed

Measured against #446's Acceptance criteria, using the Verification section's own method.

1. No longer implies shortageEma/surplusEma are Phase-6 price inputs. Met. grep -rn "shortageEma\|surplusEma" src/ --include=*.ts excluding tests returns only the schema fields (worldState.ts:185-186), two zero-initializers (worldState.ts:842-843, phase6MarketPriceFormation.ts:29-30), and the writes plus the EMA's own self-reads inside updateMarketExpectations (marketPricing.ts:157-158,167-168,173-174). No pricing or clearing path reads either field. marketPricing.ts:103-108 confirms the pressure term is calculateMarketPressure(excessRatio, inventoryGapRatio, shortageSignalWeight, inventorySignalWeight) — the sole expectation reaching it is expectedUseEma, via inventoryCoverage at :97-98. Handoff/04 §9 agrees at lines 150-157 and 178-180. The replacement prose at local-market-guide.md:43,45 states exactly this.
2. Bootstrap keyed on observationCount / first informative MAIN observation, including the zero-clearing case. Met. marketPricing.ts:93-95: observationCount === 0 ? max(D, ε) : max(expectedUseEma, ε). marketPricing.ts:142-144: the early return fires only when effectiveDemandQuantity <= quantityEpsilon and offeredQuantity <= quantityEpsilon; clearedQuantity is consulted at :147-151 for the shortage/surplus rates only, never for the informative test. So "any MAIN pass in which effective demand or offered quantity exceeds the configured quantity epsilon", "Clearing is not required", and "a pass with neither demand nor offer … leaves them untouched" are each exactly right. "From the next tick's Phase 6 onward" is the correct ordering: updateMarketExpectations is called from marketStateTransition.ts:68 on the post-Phase-8 MAIN aggregates, so the earliest Phase 6 that can see the observation is the following tick's. Handoff/04 line 180 states the same boundary.
3. Clear, concise, consistent with Handoff/04 §9 and the implementation. Met. Net +6/−4 in a 71-line article; no heading, link, table or code fence added, moved or removed; the expectedUseEma explanation the Issue's scope asks to preserve is intact. The tightened clause at :65 is necessary rather than scope creep — without it the article would assert both that observed rates are folded into a persisted EMA and that they "do not directly feed back into expectation tracking".
4. Documentation/link checks remain green. Met. policy-guard and build-and-test green at head, scripts/tests 503/503, implementation_status.py --check clean. The README link at README.md:36 targets docs/reference/local-market-guide.md, which this pull request modifies but does not move.
5. REQ-VISUALIZATION-008 kept evidence-open/PARTIAL. Met, and I re-affirm the demotion the body flags as its highest risk. #447 is OPEN with priority:high / type:bug / area:visualization, recording a live conformance defect in the second of the two articles this requirement covers; the registry acceptance requires both to be canonical. Leaving the row IMPLEMENTED would have the ledger assert a satisfied requirement against a known-open defect against it. MERGE_COMMIT correctly left empty per AUTHOR_RUNBOOK.md §7 for scripts/backfill_merge_commits.py, with the prior merge commit f3a0dd31… preserved inside the evidence cell so nothing is lost, and PR naming #486 is the one permitted forward reference.

4. The diff is confined to the declared scope

Three paths changed, three declared: docs/reference/local-market-guide.md is the Issue's stated scope; docs/spec/implementation_status.csv and its generated docs/spec/IMPLEMENTATION_STATUS.md are required by acceptance criterion 5 and by AGENTS.md, which mandates the ledger row travel inside the pull request that earns it. Nothing outside. No .github/workflows/**, no AGENTS.md, no docs/zendev/** — so no policy path, and nothing that widens automated authority. docs/spec/mirror/ untouched.

5. No invariant and no test was weakened

No test file is touched by the diff at all. Suite counts are unchanged against master: 612 in 41 files, 503 script tests, 45 .NET. Money conservation, stock conservation and non-negativity suites are untouched; no Decision record is needed.

6. No secret, credential or personal data is present

Confirmed by reading the full diff, and by policy-guard green.

7. The handoff record is complete

All nine items of AGENTS.md "Handoff" are present, and the evidence separates measured from assumed rather than blurring them: Not checked volunteers that no automated test covers the change, that the rendered Pages output was not inspected, and that #447 is not fixed here; Assumptions and unknowns marks the PARTIAL demotion as an inference and names the alternative reading. Every check outcome in the body reproduced exactly against my own run. Both required Remaining gate items — #447, and the untouched #482 — have durable homes.

---

One non-blocking note, recorded for the next reader, not a defect

local-market-guide.md:43 says of the two diagnostic EMAs "nothing reads them back". Strictly, each is read by its own recursion one line later (marketPricing.ts:167-168) to produce its next value. The very next sentence pins the meaning precisely — "The only expectation the Phase-6 price formula consults is the expected-use EMA" — so a reader cannot be misled about price causality, which is the defect this Issue exists to repair. In a public explainer this is the right level of abstraction, and I am not holding the merge for it.

Standing gates

My own CHANGES_REQUESTED (review 5204564513) was the only standing refusal on this pull request; no other account holds one. This verdict is posted as a formal approving review, not a comment, so that GitHub's latest-review-per-reviewer rule supersedes it and branch protection opens — the failure mode #223 recorded. Merging now via the protected path with --squash --delete-branch.

Accepted revision: 65a6fb10bd3fb808a6e94a342f177058f39beb35.