You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
M1-06: Document M1 evidence boundary and completion criteria #9
协作与发布:
Implementation may begin immediately.
Merge order is controlled by Qy through the Merge Gate.
If a prerequisite has not merged, keep the PR as Draft or rebase
before final review.
Issue #6 is complete at main@aa7ea761b2ac5e78535387e0a7d04d45485cdfb1, with merged-main quality-gate SUCCESS.
Issue #9 remains blocked until #6, #8, and #20 are all independently merged to main and the latest merged-main quality-gate succeeds. Completion of #6 alone does not open #9.
Issue #9 may begin M1 closeout planning from this exact baseline.
Ready means only that the dependency gate is cleared. It is not SCOPE_CONFIRMED, implementation authorization, QA PASS, Maintainer Review, Merge Gate, or merge authorization.
Proposed writable scope for Maintainer confirmation:
README.md
docs/real-vs-mock.md
approved M1 closeout documentation only
First required evidence:
a closed, path-specific Work Plan;
an exact main fact inventory covering Schema, Decision Engine, the three synthetic fixtures, test counts, Issues, PRs, commits, and the M2 starting point.
Moving #9 to In Progress starts planning only. No branch, worktree, file modification, commit, or implementation PR may be created before Maintainer scope confirmation.
The Work Plan must preserve these boundaries:
describe only capabilities already merged to main;
state that frontend, backend, Moss, Monad, and live evidence are not implemented;
state that MANUAL_REVIEW is not a safety conclusion, approval, authorization, execution guarantee, or permission to sign;
do not modify business code, Schema, Decision Engine, Fixture data, ADRs, workflows, or governance configuration.
This is the closed, path-specific implementation plan for Issue #9. It is based on the dependency-gate record and Builder claim already recorded on this Issue. It authorizes no implementation by itself.
If origin/main changes before implementation begins, Builder must stop, rescan the new exact baseline and its merged-main CI, and obtain a scope amendment whenever facts, conflicts, or the proposed paths differ. Builder must not silently bind implementation evidence to an obsolete SHA.
2. Goal
Document the M1 engineering deliverables that are actually present in the checkout, their evidence and trust boundaries, and the criteria for a later Maintainer closure assessment.
Issue #9 is an M1 documentation delivery. It is not the M1 closure operation. Merging a future Closes #9 PR must not automatically close tracker #4, close the M1 Milestone, mark either Done, or claim that M1 has passed its separate Maintainer closure assessment.
3. Proposed implementation branch and isolated worktree
Only after an explicit Maintainer SCOPE_CONFIRMED / IMPLEMENTATION_AUTHORIZED record:
Base: the Maintainer-confirmed exact origin/main SHA
Do not reuse an Issue #8 or #20 worktree or branch.
4. Closed writable file list
Exactly three repository paths are writable:
README.md
docs/real-vs-mock.md
docs/m1-completion-evidence.md (new; this is the proposed approved M1 completion-evidence document)
There are no wildcard paths. No fourth path may be added without a new Maintainer Scope Gate. The third path is not approved until the Maintainer explicitly confirms this plan.
5. Stable content contract by file
README.md
Update the current-state summary and links so the checkout is described accurately and concisely:
Preserve the M0 repository and architecture baseline.
Preserve the M1-01 engineering foundation: pnpm workspace with packages/*, Node 22/pnpm 11 constraints, strict no-emit TypeScript, Biome, Vitest, and the quality-gate workflow.
Record the public PreflightReport v0.1 runtime Schema and the strict DecisionInput boundary.
Record the public Decision Engine v0.1 package as pure, synchronous, offline, deterministic and fail-closed.
Record all three synthetic development Fixtures by stable role:
MANUAL_REVIEW success;
tokenOut mismatch STOP;
amountIn mismatch STOP while simulation remains SUCCESS.
Link to docs/m1-completion-evidence.md for the exact issue/PR/commit/CI inventory.
Remove the stale claim that the repository has no STOP Fixture.
The README must still state that the repository is not a runnable application and has no frontend, backend, Moss, Monad RPC, protocol quote integration, wallet, signing, transaction broadcast, live simulation, or real-chain evidence. It must not describe Schema, Engine, Fixtures, tests, tooling, documentation, or green CI as product functionality, real evidence, authorization, or a safety guarantee.
docs/real-vs-mock.md
Correct the evidence-boundary inventory without weakening its trust model:
Record the M0 baseline and the current M1 tooling, Schema, Decision Engine, and three-Fixture foundation.
Identify all three files as provenance: FIXTURE synthetic development data.
State that Fixture identifiers, raw payloads, Quotes, Receipts, Outcomes, simulation records, references and decisions are synthetic, not observed protocol or chain evidence.
State that the Decision Engine consumes already-validated DecisionInput, recomputes a deterministic fail-closed decision, and neither creates source evidence nor calculates Alignment.
State that MANUAL_REVIEW is not a safety conclusion, approval, authorization, execution guarantee, or permission to sign.
State that STOP is a structured fail-closed result, not proof of safety, transaction authorization, or real-chain observation.
State that toolchain, documentation, tests and green CI are not mock or real protocol evidence and are not a safety guarantee.
Remove the stale claim that no STOP Fixture exists.
Preserve the list of capabilities that are still absent: runnable demo, frontend/backend, report-generation orchestration, Moss/Monad/RPC integration, live protocol Quotes/Receipts/Outcomes/simulation, wallet/signing/broadcast, real addresses or secrets, and any other live-chain evidence.
docs/m1-completion-evidence.md
Create one durable evidence inventory and completion-criteria document. It must be factual, linkable and explicit that evidence inventory is not closure authority. It will contain:
Purpose and boundary: inventories M1 engineering deliverables present in the checkout; does not close M1-00: Evidence Contract Delivery Tracker #4 or the M1 Milestone and does not authorize M2 work.
Exact baseline evidence: the confirmed main SHA, Node/pnpm versions, strict quality-gate, clean-checkout run URL, and 13/655 passing test result.
Lifecycle facts in the evidence document must be framed as an exact-SHA/date snapshot or linked to GitHub as the live source of truth. README and real-vs-mock must contain stable checkout facts, not transient Draft/Review/Merge Gate narration.
6. Fixed evidence and semantics
The implementation must not invent or reinterpret contracts. It must preserve:
The stale no STOP Fixture claim has zero matches. Any no Decision Engine wording must not survive as a current-state claim.
Risk terms may appear only in explicit limitation/negation statements; every match is reviewed in context.
All M1 issue/PR/commit and CI references are checked against GitHub and the repository.
Exact diff contains only the three approved documentation paths.
pnpm check remains green with the existing expected 13 test files / 655 tests unless the authorized baseline changes and the fact inventory is formally refreshed.
The future PR exact-head quality-gate job is SUCCESS and still named quality-gate.
9. Non-goals and prohibited changes
This plan does not authorize:
changes to Schema, Decision Engine, Fixture JSON/README/tests, ADRs, TypeScript, dependencies, workspace, package scripts, lockfile, CI workflow, SECURITY, architecture, governance or application code;
frontend, backend, Moss, Monad, RPC, protocol, wallet, signing, transaction, live simulation, real address, secret, deployment or release work;
claiming that M1, a product Gate, a safety Gate, or any M2 Gate has passed;
beginning, assigning or authorizing M2 implementation.
10. Risk controls
Overstatement risk: every capability sentence must distinguish engineering contracts/test data from runnable or live behavior.
Fixture provenance risk: every Fixture mention must retain synthetic FIXTURE provenance and non-evidence language.
Decision semantics risk: MANUAL_REVIEW and STOP wording must match accepted contracts exactly; documentation cannot imply authorization or safety.
Staleness risk: stable checkout facts belong in README/real-vs-mock; exact historical SHA/status/CI facts belong in the evidence snapshot or live GitHub links.
Scope-creep risk: exact three-path diff is mandatory; any new path stops implementation for a new Scope Gate.
11. Rollback
The future implementation must be one small documentation-only change set. Rollback is the ordinary revert of that future commit/PR; no Schema, package, workflow, protection or runtime migration is involved.
12. Draft PR and handoff requirements
The future Draft PR must:
use title docs: document M1 evidence boundary and completion criteria;
include Closes #9 only, never Closes #4;
link this Work Plan and the Maintainer scope-confirmation record;
report the exact base and head SHA, exact three-file diff, local command results, 13/655 test result and exact-head CI URL;
state that all evidence is repository/test/Fixture evidence, not Moss/Monad/protocol/wallet/chain evidence;
state that MANUAL_REVIEW is not a safety conclusion, approval, authorization, execution guarantee, or permission to sign;
After a Maintainer eventually merges #9, a separate Maintainer-controlled #4 closure assessment must verify the new exact main SHA and its push quality-gate. That later assessment is outside this Work Plan.
13. Maintainer Scope Gate request
Please record either:
SCOPE_CONFIRMED / IMPLEMENTATION_AUTHORIZED for exactly the three paths and behavior above; or
SCOPE_CHANGES_REQUESTED with the specific required change.
Until that record exists, Builder will create no branch, worktree, file change, commit or PR for #9.
This Work Plan makes no Issue, Project, Milestone, review, merge or permission change.
The current README and Real-versus-Mock document still contain obsolete no-STOP-Fixture statements, while the current checkout contains the merged Decision Engine and all three synthetic Fixtures. The proposed closeout documentation is therefore required and factually grounded.
Confirmed scope
Implementation is authorized for exactly these three repository paths:
README.md
docs/real-vs-mock.md
docs/m1-completion-evidence.md
No fourth path is authorized. There may be no Schema, Decision Engine, Fixture JSON/README/test, ADR, TypeScript, dependency, workspace, package script, lockfile, workflow, security, architecture, governance, application, Issue/Project/Milestone, protection, required-check, permission, #8/#20, or M2 implementation change.
Required documentation contract
README and Real-versus-Mock must contain stable checkout facts only, not Draft/Review/Merge Gate narration.
Remove obsolete current-state claims that no Decision Engine or no STOP Fixture exists.
Record the public report-schema and decision-engine boundaries and all three synthetic Fixture roles without describing them as a runnable application, product capability, real protocol evidence, or chain evidence.
Preserve that the Decision Engine consumes validated input, does not create/strengthen evidence, does not calculate Alignment, and returns only MANUAL_REVIEW or fail-closed STOP.
Preserve that MANUAL_REVIEW is not a safety conclusion, approval, authorization, execution guarantee, or permission to sign.
Preserve that STOP is a structured fail-closed result, not proof of safety, transaction authorization, or real-chain observation.
Continue to state that frontend, backend, Moss, Monad/RPC, protocol integration, report orchestration, wallet, signing, broadcast, live simulation, and real-chain evidence are absent.
docs/m1-completion-evidence.md must be a dated/exact-SHA evidence inventory, not a closure certificate. It must include the verified M1 Issue/PR/commit mapping, current CI/test evidence, ADR/runtime/Fixture inventory, completion criteria for the later #4 assessment, explicit non-implementation boundaries, and a clearly labeled planning-only M2 snapshot.
Lifecycle facts must be bound to an exact SHA/date or linked to GitHub as the live source of truth. The document may link #9 and #4, but must not assert that either is closed before GitHub records that state.
Closure boundary
The future PR may include Closes #9 only. It must not include Closes #4, close or mark Done tracker #4, close the M1 Milestone, claim M1 has passed, or authorize/assign/start M2 work.
After #9 is eventually squash merged and its new main commit passes the push quality-gate, Maintainer Qy must perform a separate clean-main #4/M1 closure assessment. That assessment and all control-plane closure operations remain outside this authorization.
Verification boundary
Builder must use Node 22 / pnpm 11, pass full pnpm check, review every risk-term match in context, verify all Issue/PR/commit/CI facts, keep the exact diff to these three documentation paths, pass git diff --check, obtain exact-head GitHub quality-gate SUCCESS, publish the Implementation Report and Pre-PR QA handoff, freeze the head, and stop.
Authorization
Builder Qy may create codex/issue-9-m1-closeout from the authorized baseline and open one Draft PR titled docs: document M1 evidence boundary and completion criteria with Closes #9. If main advances before branch creation, stop and rescan the new baseline before implementation.
This record is implementation authorization only. It is not QA PASS, Maintainer Review, READY_TO_MERGE, Merge Gate, #4 closure, M1 completion, or merge authorization.
This completes Issue #9 delivery only. Tracker #4 and the M1 Milestone remain open pending their separate Maintainer closure assessment. No M2 implementation is authorized or started by this record.
Activity
docs: accept PreflightReport v0.1 schema contract (#13)
2 remaining items
pillowtalk-Qy commentedon Aug 3, 2026
DEPENDENCY_STATUS
Issue #6 is complete at
main@aa7ea761b2ac5e78535387e0a7d04d45485cdfb1, with merged-main quality-gate SUCCESS.Issue #9 remains blocked until #6, #8, and #20 are all independently merged to main and the latest merged-main quality-gate succeeds. Completion of #6 alone does not open #9.
M1-05: add tokenOut mismatch STOP fixture (#67)
M1-09: add amountIn mismatch STOP fixture (#68)
pillowtalk-Qy commentedon Aug 4, 2026
DEPENDENCY_GATE_CLEARED
Issues #6, #8, and #20 are merged into
main@9e0d5c074517c3f95ab2ccecc35c2c0176ef7faf.The current merged-main push quality-gate is SUCCESS:
https://github.com/Moss-Mini-Demo/moss-mini-demo/actions/runs/30937008262/job/92085564423
Issue #9 may begin M1 closeout planning from this exact baseline.
Ready means only that the dependency gate is cleared. It is not SCOPE_CONFIRMED, implementation authorization, QA PASS, Maintainer Review, Merge Gate, or merge authorization.
pillowtalk-Qy commentedon Aug 4, 2026
BUILDER_CLAIM
Builder:
pillowtalk-QyBase:
origin/main@9e0d5c074517c3f95ab2ccecc35c2c0176ef7fafPlanned branch:
codex/issue-9-m1-closeoutPlanned isolated worktree:
/Users/qy/Documents/moss-mini-demo-issue-9Proposed writable scope for Maintainer confirmation:
README.mddocs/real-vs-mock.mdFirst required evidence:
Moving #9 to In Progress starts planning only. No branch, worktree, file modification, commit, or implementation PR may be created before Maintainer scope confirmation.
The Work Plan must preserve these boundaries:
pillowtalk-Qy commentedon Aug 4, 2026
Final Implementation Work Plan - M1 Evidence Boundary and Completion Criteria - Awaiting Maintainer Scope Confirmation
Status:
PLANNING_ONLY / AWAITING_MAINTAINER_SCOPE_CONFIRMATIONThis is the closed, path-specific implementation plan for Issue #9. It is based on the dependency-gate record and Builder claim already recorded on this Issue. It authorizes no implementation by itself.
1. Exact planning baseline and verified facts
origin/main@9e0d5c074517c3f95ab2ccecc35c2c0176ef7faf(M1-09: add amountIn mismatch STOP fixture (#68)).quality-gate: SUCCESS on Node22.23.1and pnpm11.16.0.quality-gate; conversation resolution and linear-history controls remain outside this Issue.If
origin/mainchanges before implementation begins, Builder must stop, rescan the new exact baseline and its merged-main CI, and obtain a scope amendment whenever facts, conflicts, or the proposed paths differ. Builder must not silently bind implementation evidence to an obsolete SHA.2. Goal
Document the M1 engineering deliverables that are actually present in the checkout, their evidence and trust boundaries, and the criteria for a later Maintainer closure assessment.
Issue #9 is an M1 documentation delivery. It is not the M1 closure operation. Merging a future
Closes #9PR must not automatically close tracker #4, close the M1 Milestone, mark either Done, or claim that M1 has passed its separate Maintainer closure assessment.3. Proposed implementation branch and isolated worktree
Only after an explicit Maintainer
SCOPE_CONFIRMED / IMPLEMENTATION_AUTHORIZEDrecord:codex/issue-9-m1-closeout/Users/qy/Documents/moss-mini-demo-issue-9origin/mainSHADo not reuse an Issue #8 or #20 worktree or branch.
4. Closed writable file list
Exactly three repository paths are writable:
README.mddocs/real-vs-mock.mddocs/m1-completion-evidence.md(new; this is the proposed approved M1 completion-evidence document)There are no wildcard paths. No fourth path may be added without a new Maintainer Scope Gate. The third path is not approved until the Maintainer explicitly confirms this plan.
5. Stable content contract by file
README.mdUpdate the current-state summary and links so the checkout is described accurately and concisely:
packages/*, Node 22/pnpm 11 constraints, strict no-emit TypeScript, Biome, Vitest, and thequality-gateworkflow.docs/m1-completion-evidence.mdfor the exact issue/PR/commit/CI inventory.The README must still state that the repository is not a runnable application and has no frontend, backend, Moss, Monad RPC, protocol quote integration, wallet, signing, transaction broadcast, live simulation, or real-chain evidence. It must not describe Schema, Engine, Fixtures, tests, tooling, documentation, or green CI as product functionality, real evidence, authorization, or a safety guarantee.
docs/real-vs-mock.mdCorrect the evidence-boundary inventory without weakening its trust model:
provenance: FIXTUREsynthetic development data.Preserve the list of capabilities that are still absent: runnable demo, frontend/backend, report-generation orchestration, Moss/Monad/RPC integration, live protocol Quotes/Receipts/Outcomes/simulation, wallet/signing/broadcast, real addresses or secrets, and any other live-chain evidence.
docs/m1-completion-evidence.mdCreate one durable evidence inventory and completion-criteria document. It must be factual, linkable and explicit that evidence inventory is not closure authority. It will contain:
quality-gate, clean-checkout run URL, and 13/655 passing test result.@moss-mini-demo/report-schemapublic validation boundary;@moss-mini-demo/decision-enginepublic evaluator/error boundary;edd37e0b977fe2821752dda4d4c3b4715238ffe8;a210d9c297ddef4b42648b2c1343da5b9c19a407;aa7ea761b2ac5e78535387e0a7d04d45485cdfb1;316dd1478b46185df862be80499963e42d73855b;c52384448e0016d36f2e723f8cdf37f10315e1c8;27a9bc66f483a25d6602fdac2748099bfb32d67e;9e0d5c074517c3f95ab2ccecc35c2c0176ef7faf;quality-gateretained;Lifecycle facts in the evidence document must be framed as an exact-SHA/date snapshot or linked to GitHub as the live source of truth. README and real-vs-mock must contain stable checkout facts, not transient Draft/Review/Merge Gate narration.
6. Fixed evidence and semantics
The implementation must not invent or reinterpret contracts. It must preserve:
evaluateDecisionV0_1andDecisionInputErrorV0_1;DecisionV0_1andStopReasonCodeV0_1remain type exports.packages/report-schema/fixtures/README.md.This Issue documents these facts only. It does not modify, extend, retest through copied logic, or redefine them.
7. Implementation sequence after authorization
origin/main, Issue M1-06: Document M1 evidence boundary and completion criteria #9 state, no conflicting open PR, and a clean source checkout.codex/issue-9-m1-closeoutfrom the authorized baseline.docs/m1-completion-evidence.mdfrom verifiable Git/repository/GitHub facts only.docs: document M1 evidence boundary and completion criteriawithCloses #9.quality-gateSUCCESS, freeze the head, and return to Pre-PR QA.8. Local verification and acceptance
Run with Node
22.23.1and pnpm11.16.0:Documentation-specific checks:
Acceptance interpretation:
no STOP Fixtureclaim has zero matches. Anyno Decision Enginewording must not survive as a current-state claim.pnpm checkremains green with the existing expected 13 test files / 655 tests unless the authorized baseline changes and the fact inventory is formally refreshed.quality-gatejob is SUCCESS and still namedquality-gate.9. Non-goals and prohibited changes
This plan does not authorize:
10. Risk controls
FIXTUREprovenance and non-evidence language.11. Rollback
The future implementation must be one small documentation-only change set. Rollback is the ordinary revert of that future commit/PR; no Schema, package, workflow, protection or runtime migration is involved.
12. Draft PR and handoff requirements
The future Draft PR must:
docs: document M1 evidence boundary and completion criteria;Closes #9only, neverCloses #4;After a Maintainer eventually merges #9, a separate Maintainer-controlled #4 closure assessment must verify the new exact
mainSHA and its pushquality-gate. That later assessment is outside this Work Plan.13. Maintainer Scope Gate request
Please record either:
SCOPE_CONFIRMED / IMPLEMENTATION_AUTHORIZEDfor exactly the three paths and behavior above; orSCOPE_CHANGES_REQUESTEDwith the specific required change.Until that record exists, Builder will create no branch, worktree, file change, commit or PR for #9.
This Work Plan makes no Issue, Project, Milestone, review, merge or permission change.
pillowtalk-Qy commentedon Aug 4, 2026
SCOPE_CONFIRMED / IMPLEMENTATION_AUTHORIZED
Reviewed closed Work Plan:
#9 (comment)
Authorized baseline:
main@9e0d5c074517c3f95ab2ccecc35c2c0176ef7fafThe dependency gate is satisfied: Issues #6, #8, and #20 are Closed / Project Done, and the exact current-main push
quality-gateis SUCCESS on Node 22 / pnpm 11 with 13 test files / 655 tests:https://github.com/Moss-Mini-Demo/moss-mini-demo/actions/runs/30937008262
The current README and Real-versus-Mock document still contain obsolete no-STOP-Fixture statements, while the current checkout contains the merged Decision Engine and all three synthetic Fixtures. The proposed closeout documentation is therefore required and factually grounded.
Confirmed scope
Implementation is authorized for exactly these three repository paths:
README.mddocs/real-vs-mock.mddocs/m1-completion-evidence.mdNo fourth path is authorized. There may be no Schema, Decision Engine, Fixture JSON/README/test, ADR, TypeScript, dependency, workspace, package script, lockfile, workflow, security, architecture, governance, application, Issue/Project/Milestone, protection, required-check, permission, #8/#20, or M2 implementation change.
Required documentation contract
MANUAL_REVIEWor fail-closedSTOP.MANUAL_REVIEWis not a safety conclusion, approval, authorization, execution guarantee, or permission to sign.STOPis a structured fail-closed result, not proof of safety, transaction authorization, or real-chain observation.docs/m1-completion-evidence.mdmust be a dated/exact-SHA evidence inventory, not a closure certificate. It must include the verified M1 Issue/PR/commit mapping, current CI/test evidence, ADR/runtime/Fixture inventory, completion criteria for the later #4 assessment, explicit non-implementation boundaries, and a clearly labeled planning-only M2 snapshot.Lifecycle facts must be bound to an exact SHA/date or linked to GitHub as the live source of truth. The document may link #9 and #4, but must not assert that either is closed before GitHub records that state.
Closure boundary
The future PR may include
Closes #9only. It must not includeCloses #4, close or mark Done tracker #4, close the M1 Milestone, claim M1 has passed, or authorize/assign/start M2 work.After #9 is eventually squash merged and its new main commit passes the push
quality-gate, Maintainer Qy must perform a separate clean-main #4/M1 closure assessment. That assessment and all control-plane closure operations remain outside this authorization.Verification boundary
Builder must use Node 22 / pnpm 11, pass full
pnpm check, review every risk-term match in context, verify all Issue/PR/commit/CI facts, keep the exact diff to these three documentation paths, passgit diff --check, obtain exact-head GitHubquality-gateSUCCESS, publish the Implementation Report and Pre-PR QA handoff, freeze the head, and stop.Authorization
Builder Qy may create
codex/issue-9-m1-closeoutfrom the authorized baseline and open one Draft PR titleddocs: document M1 evidence boundary and completion criteriawithCloses #9. If main advances before branch creation, stop and rescan the new baseline before implementation.This record is implementation authorization only. It is not QA PASS, Maintainer Review,
READY_TO_MERGE, Merge Gate, #4 closure, M1 completion, or merge authorization.pillowtalk-Qy commentedon Aug 4, 2026
POST_MERGE_AUDIT
PR #69 was squash-merged under the exact Maintainer Merge Gate.
7bb476bf18a45a8afe0cb3db1489bcf08709ec54main@9e0d5c074517c3f95ab2ccecc35c2c0176ef7fafaae0397da1ba4924422d5a456123e9a4243b17972026-08-04T18:58:50ZThis completes Issue #9 delivery only. Tracker #4 and the M1 Milestone remain open pending their separate Maintainer closure assessment. No M2 implementation is authorized or started by this record.