Skip to content

M1-06: Document M1 evidence boundary and completion criteria #9

Closed

Description

@pillowtalk-Qy

Fallback owner: Qy

协作与发布:
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.

范围:

  • 更新 README 与 real-vs-mock.md。
  • 记录 M1 的真实完成内容与仍未实现内容。
  • 记录 Fixture 语义、Decision Engine 边界和 M1 验收结果。

验收:

  • 不把 Fixture 说成真实链上证据。
  • 不把 MANUAL_REVIEW 说成安全保证。
  • M2 前不实现的内容明确列出。
  • 所有 M1 子 Issue 链接和完成状态可追踪。

Activity

  1. 2 remaining items

  2. pillowtalk-Qy commented on Aug 3, 2026

    @pillowtalk-Qy
    ContributorAuthor

    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.

  3. pillowtalk-Qy commented on Aug 4, 2026

    @pillowtalk-Qy
    ContributorAuthor

    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.

  4. added and removed
    status:blockedBlocked by an unresolved dependency
    on Aug 4, 2026
  5. self-assigned this
    on Aug 4, 2026
  6. pillowtalk-Qy commented on Aug 4, 2026

    @pillowtalk-Qy
    ContributorAuthor

    BUILDER_CLAIM

    Builder: pillowtalk-Qy

    Base: origin/main@9e0d5c074517c3f95ab2ccecc35c2c0176ef7faf

    Planned branch: codex/issue-9-m1-closeout
    Planned isolated worktree: /Users/qy/Documents/moss-mini-demo-issue-9

    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.
  7. pillowtalk-Qy commented on Aug 4, 2026

    @pillowtalk-Qy
    ContributorAuthor

    Final Implementation Work Plan - M1 Evidence Boundary and Completion Criteria - Awaiting Maintainer Scope Confirmation

    Status: PLANNING_ONLY / AWAITING_MAINTAINER_SCOPE_CONFIRMATION

    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.

    1. Exact planning baseline and verified facts

    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:

    • Branch: codex/issue-9-m1-closeout
    • Isolated worktree: /Users/qy/Documents/moss-mini-demo-issue-9
    • 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:

    1. README.md
    2. docs/real-vs-mock.md
    3. 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:

    1. 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.
    2. Exact baseline evidence: the confirmed main SHA, Node/pnpm versions, strict quality-gate, clean-checkout run URL, and 13/655 passing test result.
    3. Contract artifacts: ADR 0001 through ADR 0004 and the accepted M1-07: Clarify DecisionInput and MANUAL_REVIEW contract #18 clarification, with repository or GitHub links.
    4. Runtime artifact summary:
      • @moss-mini-demo/report-schema public validation boundary;
      • @moss-mini-demo/decision-engine public evaluator/error boundary;
      • three named synthetic Fixtures and their expected MANUAL_REVIEW/STOP semantics.
    5. M1 delivery traceability table covering every M1 Milestone Issue:
    6. Supporting records, clearly separated from M1 child delivery: ADR 0001 PR docs: accept PreflightReport v0.1 schema contract #13, ADR 0002 PR docs: fix PreflightReport v0.1 implementation values #14, ADR 0003 PR docs: freeze Decision Engine v0.1 contract #17, and STOP presentation PR docs: define STOP presentation requirements #12 / Issue docs: define two-layer STOP presentation requirements #11.
    7. Completion-criteria checklist for the later M1-00: Evidence Contract Delivery Tracker #4 assessment:
      • all required M1 artifacts merged;
      • strict required quality-gate retained;
      • clean-main CI successful at the closure-assessment SHA;
      • Schema/Engine public package imports and complete test suite successful;
      • three synthetic Fixtures parse and reproduce their documented decisions;
      • evidence/non-evidence and MANUAL_REVIEW/STOP limitations remain explicit;
      • M1-06: Document M1 evidence boundary and completion criteria #9 documentation merged and its merged-main CI successful.
    8. Explicit non-implementation boundary and prohibited capability claims.
    9. M2 handoff snapshot for planning only:

    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:

    • PreflightReport v0.1 Schema and DecisionInput boundaries from accepted ADRs 0001-0004 and M1-07: Clarify DecisionInput and MANUAL_REVIEW contract #18.
    • Decision Engine public runtime API: evaluateDecisionV0_1 and DecisionInputErrorV0_1; DecisionV0_1 and StopReasonCodeV0_1 remain type exports.
    • Engine behavior: pure, synchronous, offline, deterministic, fail-closed, no input modification, complete closed 22-code STOP matrix.
    • MANUAL_REVIEW only when the accepted pass conditions hold; no reasons are attached to MANUAL_REVIEW.
    • SourceReference ownership and canonical JSON Pointer associations.
    • Fixture provenance and limitations already recorded in 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

    1. Reconfirm exact origin/main, Issue M1-06: Document M1 evidence boundary and completion criteria #9 state, no conflicting open PR, and a clean source checkout.
    2. Create the isolated worktree and codex/issue-9-m1-closeout from the authorized baseline.
    3. Read the three target files and the accepted ADR/Fixture/public-package sources before editing.
    4. Create docs/m1-completion-evidence.md from verifiable Git/repository/GitHub facts only.
    5. Make the minimum stable-fact corrections to README and real-vs-mock; do not refactor unrelated prose.
    6. Scan all three files for stale capability claims, transient PR lifecycle text, Fixture-as-real-evidence language and unsafe MANUAL_REVIEW wording.
    7. Confirm the diff contains exactly the three approved paths.
    8. Run the complete local verification on Node 22.23.1 and pnpm 11.16.0.
    9. Commit and push the single-purpose documentation branch.
    10. Open one Draft PR titled docs: document M1 evidence boundary and completion criteria with Closes #9.
    11. Record an Implementation Report and Pre-PR QA handoff containing exact head, files, command results, test count and exact-head CI URL.
    12. Wait for the exact-head quality-gate SUCCESS, freeze the head, and return to Pre-PR QA.

    8. Local verification and acceptance

    Run with Node 22.23.1 and pnpm 11.16.0:

    node --version
    pnpm --version
    pnpm install --frozen-lockfile
    pnpm check
    git diff --check 9e0d5c074517c3f95ab2ccecc35c2c0176ef7faf...HEAD
    git diff --name-status 9e0d5c074517c3f95ab2ccecc35c2c0176ef7faf...HEAD
    git status --short

    Documentation-specific checks:

    rg -n 'no STOP Fixture|no Decision Engine' README.md docs/real-vs-mock.md docs/m1-completion-evidence.md
    rg -n 'MANUAL_REVIEW|safety|approval|authorization|execution guarantee|permission to sign' README.md docs/real-vs-mock.md docs/m1-completion-evidence.md
    rg -n 'Moss|Monad|wallet|signing|transaction|live|real-chain|FIXTURE' README.md docs/real-vs-mock.md docs/m1-completion-evidence.md
    rg -n 'Issue #|PR #|quality-gate|655|9e0d5c074517c3f95ab2ccecc35c2c0176ef7faf' docs/m1-completion-evidence.md

    Acceptance interpretation:

    • 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;
    • creation or modification of M1-05: Add tokenOut mismatch STOP fixture #8/M1-09: Add amountIn mismatch STOP fixture #20 Fixtures;
    • changes to Issue/Project/Milestone state, branch protection, required checks, permissions or OAuth scope;
    • GitHub Review, Approve, Ready for Review, Merge Gate, merge, release, or main mutation by Builder;
    • closing tracker M1-00: Evidence Contract Delivery Tracker #4 or the M1 Milestone;
    • 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.
    • Closure-authority risk: M1-06: Document M1 evidence boundary and completion criteria #9 delivery and M1-00: Evidence Contract Delivery Tracker #4/Milestone closure are separate operations. Only the later independent Maintainer assessment can perform closure control changes.
    • 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;
    • remain Draft and be returned to Pre-PR QA;
    • state explicitly that Builder performed no Review, Ready, Merge Gate, merge, M1-00: Evidence Contract Delivery Tracker #4 closure or Milestone closure operation.

    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.

  8. pillowtalk-Qy commented on Aug 4, 2026

    @pillowtalk-Qy
    ContributorAuthor

    SCOPE_CONFIRMED / IMPLEMENTATION_AUTHORIZED

    Reviewed closed Work Plan:
    #9 (comment)

    Authorized baseline: main@9e0d5c074517c3f95ab2ccecc35c2c0176ef7faf

    The dependency gate is satisfied: Issues #6, #8, and #20 are Closed / Project Done, and the exact current-main push quality-gate is 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:

    1. README.md
    2. docs/real-vs-mock.md
    3. 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.

  9. pillowtalk-Qy commented on Aug 4, 2026

    @pillowtalk-Qy
    ContributorAuthor

    POST_MERGE_AUDIT

    PR #69 was squash-merged under the exact Maintainer Merge Gate.

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:docsDocumentation and evidence-boundary workpriority:P1High prioritytype:docsDocumentation changes

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions