musubix3 0.1.6 → 0.1.8

package/.github/plugin/marketplace.json

@@ -3,13 +3,13 @@
   "owner": { "name": "nahisaho" },
   "metadata": {
     "description": "GitHub Copilot CLI specification-driven development skills",
-    "version": "0.1.6"
+    "version": "0.1.8"
   },
   "plugins": [
     {
       "name": "musubix3",
       "source": ".",
-      "version": "0.1.6",
+      "version": "0.1.8",
       "description": "Evidence-driven SDD without duplicating native Copilot capabilities."
     }
   ]

package/.github/skills/sdd-change/SKILL.md

@@ -3,34 +3,33 @@ name: sdd-change
 description: "Use as the MANDATORY first Skill for requests to develop, build, create, implement, add, change, or fix software, including 「開発」「作成」「実装」. Start requirements and design before code, then propagate through tests, traceability, and quality evidence. ソフトウェア開発依頼では実装前に必ず要求定義・設計から開始。"
 ---
 # Integrated change workflow / 統合変更ワークフロー
-Mandatory entrypoint: never start implementation for a natural-language development request before eliciting and validating requirements and design; skip only for explicitly requested implementation of verified, approved artifacts.
+/* @id CODE-SESSION-SCOPED-DEVELOPMENT-001
+ * @implements REQ-SESSION-SCOPED-DEVELOPMENT-001 REQ-SESSION-SCOPED-DEVELOPMENT-002
+ * @design DES-SESSION-SCOPED-DEVELOPMENT-001
+ */
+Mandatory entrypoint: every new natural-language development request is a new change, even in an existing Copilot session; never reuse prior requirements, approvals, TDD, or change evidence unless the user explicitly names the existing change ID and asks to continue it. never start implementation before validating requirements/design; skip only for verified approved artifacts of that explicitly continued change.
+Never infer approval; show `approval prepare <stage>` and record only its reviewed hash with `approval record <stage> --approver <name> --artifact-sha256 <hash> --confirm`.
 Follow the user's input language. Use native Copilot planning, editing, research, review, security review and subagents.
-Record exactly one final invocation outcome with `npx musubix3 workflow-record
-sdd-change complete --status <status>`; `change-record` separately proves phases.
+Record exactly one final invocation outcome with `npx musubix3 workflow-record sdd-change complete --status <status>`; `change-record` separately proves phases.
 Run `workflow-sanitize <copilot.jsonl> <safe.jsonl>` before review, then
 `workflow-verify <safe.jsonl>`; it validates source-order lifecycles without
 assuming globally monotonic clocks unless `maxEventSkewMs` is explicitly set.
-For large logs, baseline-protect transcript total/line byte limits; never truncate or edit to bypass them.
+Baseline-protect transcript byte limits; never truncate/edit to bypass them.
 For strict evidence, bind an expected UUID; GitHub origin needs strict OIDC.
 Never record multiple declarations per invocation; use only the configured CLI.
-For broad work, use short stages: initialize, requirements, design, real Red,
-Green, integration, trace/formal, quality. Report each result before the next prompt.
-For a staged change, run `change-record <CHANGE-ID> <phase> --requirement
-<REQ-ID...>` after each phase in this exact order: `impact`, `requirements`,
-`design`, `red`, `implementation`, `green`, `quality`.
-List only requirements whose statement or acceptance changes, classify each as
-functional/non-functional, and document other impacts separately. Each listed
-requirement needs fresh Red after `requirements` and Green after `implementation`.
+For broad work, use short stages: initialize, requirements, requirements approval, design, design approval, real Red, Green, integration, trace/formal, quality, release approval. Report each result before the next prompt.
+For a staged change, run `change-record <CHANGE-ID> <phase> --requirement <REQ-ID...>` after each phase in this exact order: `impact`, `requirements`, `design`, `red`, `implementation`, `green`, `quality`.
+List only requirements whose statement/acceptance changes, classify each, and
+document other impacts separately. Each needs fresh Red and Green.
 The CHANGE document must contain `Requirements:` with exactly those normative IDs.
 Persisted monotonic order, not wall-clock time, proves these phase boundaries.
 ## 1. Classify and inspect / 分類と事前確認
 1. Classify the request as a feature, behavior change, defect correction,
-   refactoring, or documentation-only change.
-2. Read the constitution and relevant requirements, designs, ADRs, code and tests.
-3. Run `npx musubix3 trace impact <id-or-path> --json` and, when code exists,
-   `graph index` plus `graph impact <symbol-or-path> --json`.
-4. Separate confirmed intent, assumptions and open questions. When material context is missing, ask exactly one highest-priority question, wait for its answer, then repeat; never batch questions or finalize requirements, design or code while blockers remain.
-
+   refactoring, or documentation-only change. For a new program/feature, create
+   a fresh feature slug and CHANGE artifact; prior session context is not approval.
+2. Read the constitution and relevant requirements, designs, ADRs, code and tests, but treat prior-session artifacts as historical context unless continuation is explicit.
+3. Run `trace impact`; when code exists run `graph index` and `graph impact`.
+4. Separate confirmed intent, assumptions and open questions. When material context is missing, ask exactly one highest-priority question, wait, then repeat; never batch questions or finalize requirements, design or code while blockers remain.
 ## 2. Update specifications first / 仕様を先に更新
 1. For new or changed observable behavior, add or revise EARS requirements and
    measurable acceptance criteria before implementation. Preserve stable IDs
@@ -38,10 +37,11 @@ Persisted monotonic order, not wall-clock time, proves these phase boundaries.
 2. For a bug where implementation violates an existing requirement, keep that
    requirement and record that no specification change is needed. Never rewrite
    a requirement merely to make incorrect behavior appear compliant.
-3. Update design responsibilities, interfaces, constraints and requirement links.
-   Add or supersede an ADR only for a real architectural or trade-off decision.
+3. Update design responsibilities/interfaces/constraints/links and ADRs for real decisions.
 4. Run requirements, constitution and design validation. Stop on invalid
    artifacts instead of continuing with unapproved assumptions.
+5. Stop before design for explicit current `requirements` approval; stop before
+   Red/implementation for explicit current `design` approval. Changes re-open approval.
 ## 3. Implement and prove coverage / 実装と網羅性
 1. For observable behavior changes and defect fixes, write the smallest meaningful
    test first. Include its `TEST-*` ID in the test name/output and link it to the
@@ -57,10 +57,8 @@ Persisted monotonic order, not wall-clock time, proves these phase boundaries.
 3. Implement the smallest complete change, preserving the test, then run
    `tdd green` with the same IDs and command. Refactor only after Green and record
    `tdd refactor` after the refactored code passes.
-4. Maintain unique `CODE-*` / `TEST-*` IDs and `@implements`, `@design`,
-   `@verifies` annotations in the authoritative implementation and test files.
-   Never create proxy or placeholder source files solely to satisfy trace coverage.
-   Links are evidence locations, not proof by themselves.
+4. Maintain unique IDs and trace annotations in authoritative files; never add
+   proxies for coverage. Links locate evidence, not proof.
 5. Run focused tests, then configured typecheck, build and complete test commands.
 Documentation/prototypes may omit TDD only when policy allows; record the reason.
 ## 4. Rebuild evidence and finish / 根拠更新と完了
@@ -71,7 +69,8 @@ Documentation/prototypes may omit TDD only when policy allows; record the reason
    A required `formal` check enforces modeled fraction and configured solver.
 3. Run `gate --changed --json` and `status --json`. Repair failures, dangling
    links and stale evidence; never weaken requirements or policy to obtain green.
-4. Complete only when required checks pass and `status.gate.ready` is true.
-   Otherwise report the exact blocker and which artifacts remain incomplete.
-If the user limits the task to one phase, state which downstream work remains;
-never treat an implementation-only change as a complete SDD change.
+4. Treat the first otherwise-passing gate as the release candidate. Before any
+   release operation, prepare/show its exact hash, ask one human approve/reject
+   question and wait; record only that hash, then rerun gate/status.
+5. Complete only when required checks pass and `status.gate.ready` is true;
+   otherwise report blockers. One-phase work must state downstream work.

package/.github/skills/sdd-design/SKILL.md

@@ -11,6 +11,8 @@ After the work, run `npx musubix3 workflow-record sdd-design complete --status
 completed` exactly once.
 
 1. Read requirements and constitution; identify requirement IDs before designing.
+   Run `approval validate` and stop unless current `requirements` approval is
+   explicitly recorded when required. A passing validator is not approval.
 2. Edit `.musubix/features/<slug>/design.md` with `## DES-FEATURE-001: Title`.
    Each component needs `Responsibilities:`, `Interfaces:`, `Constraints:`,
    `Requirements: REQ-FEATURE-001`, and `ADRs: ADR-0001`. Use `Depends-On:` for
@@ -23,4 +25,8 @@ completed` exactly once.
 5. Run `npx musubix3 trace build` then `npx musubix3 trace check`.
    Do not hand-edit `trace.json`. Ask native review to inspect coupling and
    coverage; use `sdd-formal-codegraph` for compiler-based impact checks.
-6. Hand off responsibilities, interfaces, constraints and IDs to implementation.
+6. Before implementation or Red, run `approval prepare design`, show its exact
+   artifacts/hash, ask one explicit approve/reject question, then wait. On approval
+   only, record that hash with `approval record design --approver <name>
+   --artifact-sha256 <hash> --confirm`; rejection or changes require renewed review.
+7. Hand off responsibilities, interfaces, constraints and IDs to implementation.

package/.github/skills/sdd-implementation/SKILL.md

@@ -13,9 +13,11 @@ After the work, run `npx musubix3 workflow-record sdd-implementation complete
 --status completed` exactly once.
 
 1. Before editing implementation code, verify that approved requirements and
-   design artifacts exist and both validators pass. If either is absent or invalid,
+   design artifacts exist, both validators pass, and `approval validate` reports
+   current requirements and design approval. If either is absent, stale, or invalid,
    stop and return to `sdd-change`, invoking `sdd-requirements` and `sdd-design`
-   as needed. Do not infer approval from a natural-language request such as
+   as needed. `tdd red` also enforces design approval. Do not infer approval from
+   validation or a natural-language request such as
    "develop", "build", 「開発」, 「作成」, or 「実装」.
 2. For behavior changes and bug fixes, write a meaningful failing test before
    implementation. Configure the selected command with `tddArgs` containing

package/.github/skills/sdd-quality/SKILL.md

@@ -3,15 +3,11 @@ name: sdd-quality
 description: "Use when deciding release readiness from actual checks, measurable policy, architecture and trace evidence, including incremental change checks. 品質ゲート・リリース判定時に使用。"
 ---
 # Quality / 品質
-Follow the user's input language (日本語 / English). Use native Copilot review and
-security review for their specialist reasoning; this skill does not replace them.
+Follow the user's input language. Native review/security review remain separate.
 After the work, run `npx musubix3 workflow-record sdd-quality complete --status
 completed` exactly once.
-1. Inspect `.musubix/config.json` and `.musubix/policy-baseline.json` before
-   running commands. Only execute trusted project configuration. Commands are
-   executable/argument arrays, not shell text. Never edit the baseline without
-   explicit independent approval. Use only the exact `musubix3` CLI; never
-   substitute similarly named npm packages.
+1. Inspect config/baseline first. Execute only trusted argument-array commands;
+   never edit baseline without independent approval or substitute another CLI.
 2. Configure real tests/build/typecheck commands and timeouts. Use an explicit
    custom report or a built-in Vitest/Jest, pytest, Go test, Cargo, JUnit or .NET
    adapter. Require executable native adapter contracts in CI; JUnit targets use
@@ -64,8 +60,9 @@ completed` exactly once.
    Treat zero executed or non-passing tests as incomplete evidence after exit zero; run `mutation doctor`;
    musubix3 validates evidence and does not bundle a mutation engine.
    Missing required tools, commands, artifacts or evidence block readiness.
-5. Use native review/security-review as needed, recording their findings
-   separately from machine evidence. Never fabricate review or test results.
+   A candidate gate may fail only because release approval is missing; that is
+   not final readiness and must not be described as pass.
+5. Record native review/security findings separately; never fabricate evidence.
 6. For static CI provenance, configure trusted Ed25519 public keys, freshness
    bounds and `ci-required`; sign `attestation payload` outside musubix3. For
    GitHub Actions identity, opt into strict `githubOidc`, derive the key-bound
@@ -74,5 +71,8 @@ completed` exactly once.
    check all configured claims; offline strict verification fails closed.
    Ensure the baseline protects CI-required mode, strict OIDC and key binding.
    Never store a private key or overstate OIDC as proof of arbitrary runner work.
-7. Run `npx musubix3 status --json`; stale evidence must be refreshed. Report
-   limitations and residual risks before handoff; no resident watcher or REPL.
+7. After required non-approval checks pass, run `approval prepare release`, show
+   its exact hash and residual risks, ask one approve/reject question, then wait.
+   On approval only record that hash with `approval record release --approver
+   <name> --artifact-sha256 <hash> --confirm`; rejection stops. Rerun gate/status;
+   stale approval blocks commit/push/publish/deploy; no resident watcher or REPL.

package/.github/skills/sdd-requirements/SKILL.md

@@ -3,16 +3,23 @@ name: sdd-requirements
 description: "Use when eliciting, refining, or validating EARS requirements and measurable constitution rules for specification-driven development. 要求定義・EARS検証・憲章策定に使用。"
 ---
 # Requirements / 要求
-
+/* @id CODE-SESSION-SCOPED-DEVELOPMENT-002
+ * @implements REQ-SESSION-SCOPED-DEVELOPMENT-001 REQ-SESSION-SCOPED-DEVELOPMENT-002
+ * @design DES-SESSION-SCOPED-DEVELOPMENT-002
+ */
 Respond and generate guidance in the user's input language (日本語 / English).
 Use Copilot's native planning, questions, research and editing; do not create an
 interview engine or research agent framework.
 After the work, run `npx musubix3 workflow-record sdd-requirements complete
 --status completed` exactly once.
 
-1. Inspect `.musubix/constitution.md` and the feature's existing requirements.
-   If absent, preview `npx musubix3 init --dry-run` before installing.
-2. Use native planning to clarify scope, stakeholders, measurable acceptance and
+1. For every new natural-language development request, create/use a fresh
+   `.musubix/features/<new-slug>/requirements.md`; do not edit or reuse a prior
+   session's feature, approval, or change evidence unless continuation is explicit.
+   Inspect `.musubix/constitution.md` and relevant existing requirements only as
+   context. If absent, preview `npx musubix3 init --dry-run` before installing.
+2. Treat a request such as 「○○を開発」/"develop ○○" as requirements elicitation,
+   not permission to start coding. Use native planning to clarify scope, stakeholders, measurable acceptance and
    failure behavior. Separate assumptions from confirmed requirements. If required
    context is missing, use native elicitation to ask exactly one highest-priority
    question and wait for the answer before asking the next. Never batch questions.
@@ -23,12 +30,14 @@ After the work, run `npx musubix3 workflow-record sdd-requirements complete
    unique. Keep one obligation per entry; add `Acceptance: ...`.
    Acceptance must be non-placeholder and measurably testable. For semantics
    that must enter formal coverage, add strict one-line `Formal:` JSON using
-   branch-scoped `conditional`, integer `numeric`, `temporal` with required
-   `withinMs` and optional nonnegative `afterMs`, or deterministic `transition`.
+   branch-scoped `conditional` (`condition`/`consequence`), integer `numeric`
+   (`metric`/`operator` one of `<`,`<=`,`=`,`>=`,`>`/`value`), `temporal`
+   (`trigger`/`response`/required `withinMs`/optional nonnegative `afterMs`), or
+   deterministic `transition` (`from`/`event`/`to`).
    For numeric constraints, use compatible duration (`ms`/`s`/`min`) or size
    (`bytes`/`kib`/`mib`) units when conversion is intended; never translate
    arbitrary prose or incompatible dimensions by guesswork. A non-functional deterministic
-   budget uses `Performance:` with `counter`, integer `max`, and `testId`.
+   budget uses strict one-line `Performance:` JSON with `counter`, integer `max`, and `testId`.
 4. Use all six controlled EARS forms as appropriate:
    - The system shall respond.
    - When an event occurs, the system shall respond.
@@ -41,5 +50,10 @@ After the work, run `npx musubix3 workflow-record sdd-requirements complete
 5. Validate with `npx musubix3 requirements validate <file> --json` and
    `npx musubix3 constitution validate --json`. Rules use `PRINC-001`, `RULE-001`,
    a supported `Metric:` and numeric `Limit:`. Validation is not execution evidence.
-6. Hand off confirmed IDs and unresolved assumptions to `sdd-design`; use native
+6. Validation is not human approval. Before design, run `approval prepare
+   requirements`, show its exact artifacts/hash, ask one explicit approve/reject
+   question, then wait. On approval only, record that hash with `approval record
+   requirements --approver <name> --artifact-sha256 <hash> --confirm`; rejection
+   or any intervening artifact change stops and requires renewed review.
+7. Hand off confirmed IDs and unresolved assumptions to `sdd-design`; use native
    review for semantic completeness, not merely syntactic conformance.

package/CHANGELOG.md

@@ -2,6 +2,54 @@
 
 ## Unreleased
 
+## 0.1.8 - 2026-09-09
+
+- Treat every new natural-language development request as a fresh change, even within an existing Copilot session.
+- Reuse requirements, approvals, TDD, and change evidence only when the user explicitly names the existing CHANGE ID and asks to continue it.
+- Trace musubix3 Skill contracts without leaking installed Skill annotations into consumer project trace graphs.
+- Add regression coverage for fresh-change routing and explicit continuation.
+
+## 0.1.7 - 2026-09-08
+
+- Add artifact-bound human approval gates for requirements, design, and release.
+  `approval prepare` displays the exact review manifest/hash and `approval record`
+  requires that still-current hash plus explicit confirmation. Requirements
+  approval gates design validation, design approval gates TDD Red, and release
+  recording recomputes all required non-approval checks instead of trusting cached
+  quality evidence. Ordinary JSONL project inputs remain bound while recognized
+  logs are excluded. Status exposes every stage, Skills stop for one native human
+  decision, legacy configs remain compatible, and local approver text is documented
+  as non-authenticated.
+- Fix TDD test fingerprints for non-TypeScript sources: an indented single-line
+  block annotation such as `  /* @id TEST-APP-001 */` hashed an empty slice, so
+  test mutation after Red and `TDD_TEST_STALE` went undetected in PHP, Java, Go,
+  Rust, Python and every other generic-comment language.
+- Report the concrete cause of `REQ_FORMAL_SCHEMA` failures (unknown kind,
+  unexpected keys, missing keys, or the invalid field with its expected type)
+  instead of one opaque sentence.
+- Explain in `REQ_EARS` when a statement declares more than one obligation, and
+  list the valid pattern vocabulary in `REQ_PATTERN`.
+- List the known keys when configuration rejects an unknown key.
+- Add `mutation identity` so deterministic `MUT-*` values no longer require a
+  two-pass gate-and-scrape workflow, and say where `mutation validate` looks for
+  evidence instead of silently passing when none is present.
+- Report `TDD_EVIDENCE_REUSED` from the structured report hash rather than console
+  output, so quiet runners such as PHPUnit no longer produce false positives while
+  genuinely duplicated reports are still rejected.
+- Detect Composer projects in `mutation doctor` and recommend Infection together
+  with the coverage driver it requires.
+- Resolve PHP same-namespace trait composition and grouped `use A, B;` lists as
+  internal imports instead of reporting external dependencies, and drop
+  self-referencing trait edges.
+- Name the concrete remedy in TDD legacy/Red/Green diagnostics: move
+  `.musubix/evidence/tdd.json` aside and re-record every cycle; there is no
+  partial prune and hand-editing is unsupported.
+- Document the `musubix-json` report schema, that the `junit` adapter drives the
+  Java JUnit Platform Console launcher and not JUnit-XML producers such as
+  PHPUnit, and that PHP annotations must use `/* */` rather than PHPDoc because
+  PHPDoc reserves `@implements`. Align the `sdd-requirements` Skill with the
+  strict JSON `Formal:`/`Performance:` formats and their exact keys.
+
 ## 0.1.6 - 2026-09-08
 
 - Make `sdd-change` the mandatory first Skill for natural-language software

package/README-ja.md

@@ -1,6 +1,6 @@
 # musubix3
 
-**最新リリース v0.1.4 · GitHub Copilot CLI 専用 · Node.js ≥20 · TypeScript · MIT**
+**最新リリース v0.1.8 · GitHub Copilot CLI 専用 · Node.js ≥20 · TypeScript · MIT**
 
 [English](README.md)
 
@@ -168,20 +168,27 @@ Copilot の提案を記号的検査で制約する構成であり、独自の「
 要求を確定しません。
 
 1. ネイティブ計画・調査で意図と測定可能な受入条件を明確化。
-2. `change-record CHANGE-ID impact` を記録してから要求を編集・検証し、
-   `requirements` checkpointを記録。
-3. コンポーネントとADRを更新して `design` checkpointを記録。
+2. `change-record CHANGE-ID impact` を記録して要求を編集・検証し、
+   `requirements` checkpoint後、設計前にartifact-boundな人間の
+   `requirements`承認を明示的に記録。
+3. コンポーネントとADRを更新して `design` checkpointを記録し、
+   実装前にartifact-boundな人間の`design`承認を明示的に記録。
 4. 注釈付きテストを作成し、構造化結果を伴う `tdd red` と変更の `red` を記録。
 5. 最小実装後に `implementation`、成功する `tdd green`、変更の `green` を記録。
 6. 注釈とグラフを更新して変更影響・網羅性を確認。
-7. 実コマンドを設定して品質ゲートを実行。必要なレビューとセキュリティレビューは
-   別途ネイティブ機能で行い、未実施を成功扱いしない。
+7. 実コマンドで候補品質ゲートを実行。承認以外の必須checkがすべて合格した後、
+   人間が`release`承認を記録してgate/statusを再実行し、その後だけ
+   commit・push・publish・deployへ進む。検証結果や自然言語から承認を推測しない。
 
 ```sh
 npx musubix3 requirements validate .musubix/features/example/requirements.md --json
 npx musubix3 constitution validate --json
+npx musubix3 approval prepare requirements --json
+npx musubix3 approval record requirements --approver "要求責任者" --artifact-sha256 "$REVIEWED_HASH" --confirm
 npx musubix3 design validate .musubix/features/example/design.md --json
 npx musubix3 design c4 .musubix/features/example/design.md
+npx musubix3 approval prepare design --json
+npx musubix3 approval record design --approver "設計責任者" --artifact-sha256 "$REVIEWED_HASH" --confirm
 npx musubix3 change-record CHANGE-0001 design --requirement REQ-EXAMPLE-001
 npx musubix3 tdd red TEST-EXAMPLE-001 --requirement REQ-EXAMPLE-001 --command test
 # テストを変更せず、最小限の振る舞いを実装
@@ -192,6 +199,10 @@ npx musubix3 trace check --strict --json
 npx musubix3 graph index
 npx musubix3 graph impact src/service.ts
 npx musubix3 gate --changed --json
+npx musubix3 approval prepare release --json
+npx musubix3 approval record release --approver "リリース責任者" --artifact-sha256 "$REVIEWED_HASH" --confirm
+npx musubix3 gate --changed --json
+npx musubix3 approval validate --json
 npx musubix3 status --json
 ```
 
@@ -210,6 +221,9 @@ npx musubix3 status --json
 | `constitution validate [file]` | 版・原則・測定可能な規則の定義検査 |
 | `design validate <file>` | 必須項目・要求ID・既存ADRの参照検査 |
 | `design c4 <file>` | 明示的なコンポーネントと依存から Mermaid 図 |
+| `approval prepare <requirements\|design\|release>` | 人間が確認する決定的manifestとhashを表示 |
+| `approval record <stage> --approver <name> --artifact-sha256 <hash> --confirm` | 確認済みhashが現在も一致するときだけ承認を記録 |
+| `approval validate` | 各承認をapproved・missing・staleとして表示し、検証結果から承認を推測しない |
 | `trace build` | リポジトリ全体のグラフと機能別コピーを生成 |
 | `trace check [--strict]` | 未解決ID、陳腐化、必須要求の網羅性 |
 | `trace impact <id-or-path>` | 説明経路付きの双方向探索 |
@@ -226,6 +240,7 @@ npx musubix3 status --json
 | `model-correspondence validate` | Formal JSON→生成trace→正本passing testの証拠を再検証 |
 | `evidence refresh [--changed]` | 同じfail-closed gate pipelineで派生証拠を再生成 |
 | `mutation validate` | 要求scopeのschema-v1 killed-mutant証拠を再検証 |
+| `mutation identity <REQ-ID> <TEST-ID> <sourcePath> <operator> <line> <column>` | mutation reportが宣言すべき決定的な`MUT-*`識別子を出力 |
 | `tdd validate` | 保存済みRed/Green/Refactorの順序、指紋、実行時間、hash-chainを検証 |
 | `tdd red\|green\|refactor <TEST-ID> --requirement <REQ-ID> --command <name>` | 検証可能なTDDフェーズを実行・記録 |
 | `workflow-record <skill> <phase> --status <status>` | 自己申告のworkflow宣言を記録 |
@@ -333,6 +348,9 @@ apostrophe commentを扱います。これらは文字列中の記載をリン
 その他の言語では対応する行commentまたはblock commentを使用します。
 Pythonは連続した`#` commentを使用してください。docstring内のannotationは無視され、
 `TRACE_ANNOTATION_IN_PYTHON_DOCSTRING`で配置変更を案内します。
+PHPでは`/** ... */`のPHPDocではなく素の`/* ... */`を使用してください。PHPDocは
+`@implements`をgeneric型宣言に予約しているため、要求IDの列挙はPHPStan/Psalmで
+`phpDoc.parseError`になります。musubix3はどちらの形式も読み取ります。
 網羅率だけを満たす代理JS/TSファイルは作成しません。
 
 ```ts
@@ -396,6 +414,7 @@ version: 1.0.0
   "formal": { "solver": "none", "minModeledFraction": 0, "timeoutMs": 12000 },
   "mutation": { "mode": "compatible" },
   "tdd": { "redPreflightCommands": [] },
+  "approval": { "mode": "required" },
   "workflow": {
     "mode": "compatible",
     "maxAgeSeconds": 3600,
@@ -427,6 +446,18 @@ glob は `*` / `**` / `?` に対応し、外部依存は `npm:` 接頭辞で表
 `recommended`はstrict Code Graph、TDD、構造化test identityも要求し、
 `release`はformal、mutation、workflow、変更、performance、CI attestationを
 含む完全なrelease checkを要求します。不足設定や弱い設定を証拠で補ったことにはしません。
+新規初期化projectの`approval.mode`は`required`で、requirements・design・releaseの
+現在の承認を要求します。`approval`を省略した既存schema-v1 configは`compatible`として
+読み込みます。`approval prepare`で確認対象のmanifest/hashを表示し、その同じhashを
+`approval record`へ渡します。途中変更は拒否され、記録後の対象artifact変更はstaleに
+なります。承認fileはstage、approver、`approvedAt`、artifactごとのSHA-256、決定的
+manifest SHA-256を保持します。release記録はcache済みquality evidenceを信頼せずgateを
+再計算し、承認以外の必須checkがすべてpassした場合だけ成功します。
+approver文字列は明示的なlocal証拠であり、認証済みidentityではありません。
+独立identityが必要なrepositoryではprotected review、CODEOWNERS、CI/OIDCも併用します。
+local承認証拠は明示的な意思を記録しますが、承認者の暗号学的な本人確認ではありません。
+release権限はrepository review、CODEOWNERS/branch protection、またはCI/OIDC attestationで
+保護してください。
 `tdd.redPreflightCommands`にはformatter等のplain command名を指定でき、
 Redのtest fingerprintを取得する前に成功が必須です。
 通常ファイルの`pyvenv.cfg`を含む`.venv`と`venv`に加え、生成された
@@ -454,7 +485,7 @@ command reportでpassしたことを要求します。欠落・改変・stale・
 機械診断コードと詳細は英語、主要な状態表示は日英併記です。
 
 `.musubix/policy-baseline.json` は必須チェック、閾値、アーキテクチャ、
-Formalポリシー、mutation mode、workflow strict/session/freshness、CI必須attestation、
+Formalポリシー、mutation/approval mode、workflow strict/session/freshness、CI必須attestation、
 strict OIDC identity/key binding、必須コマンド名の最低条件です。Red preflightを
 要求するbaselineは正規化済み`commands`定義も保持し、同名formatterへの
 すり替えを拒否します。弱体化は拒否され、
@@ -471,6 +502,13 @@ strict OIDC identity/key binding、必須コマンド名の最低条件です。
 TDD用コマンドには明示的な`tddArgs`と`tddReport`、または組込みの
 `vitest`、`jest`、`pytest`、`go-test`、`cargo`、`junit`、`dotnet` adapterが必要です。
 明示設定を優先し、adapterは対象引数を導出してnative JSON/JSONL/XMLを正規化します。
+`junit` adapterはJava JUnit Platform Console launcherを駆動するものであり、
+JUnit XMLを出力するだけのrunner（PHPUnit等）には使えません。その場合は
+`tddArgs`/`tddReport`（および`testReport`）を明示設定してください。
+custom `musubix-json` reportは
+`{"schemaVersion":1,"tests":[{"id":"TEST-APP-001","status":"passed"}]}`形式で、
+`status`は`passed`/`failed`/`skipped`/`error`、任意の`"operations":{"counter":12}`が
+決定的な性能counterを保持します。
 Vitest/Jestの無関係なskipped結果は対象TDDから除外します。pytestにはJSON pluginと
 `test_TEST_APP_001`形式、Goには`TEST-*`名のsubtest、Cargoには`test_app_001`形式、
 JUnitには正確な`@Tag("TEST-APP-001")`と、IDを含むmethod名または`@DisplayName`を推奨します。
@@ -487,7 +525,15 @@ Green前にはテスト以外のプロジェクト入力が変更されている
 TDDと変更checkpointは共通の単調order ledgerを持ち、Red/Green境界ではこれを
 正本とし、wall-clock時刻は情報用途に限定します。orderを持たない旧chronologyは
 明示的なmigration診断で失敗します。欠落・並べ替え・改変・孤立レコードは
-証拠を無効にします。
+証拠を無効にします。旧cycleは新しい記録では置き換えられません。test scope付き
+provenanceや有効なRed/Greenを欠くcycleがある場合は、`.musubix/evidence/tdd.json`を
+退避し、全cycleをclean Red baselineから再記録してください。部分的なprune commandは
+意図的に提供せず、証拠の手編集は未対応です。
+
+決定的なmutant識別子は`musubix3 mutation identity <REQ-ID> <TEST-ID> <sourcePath>
+<operator> <line> <column>`で取得できます。`mutation validate`は
+`.musubix/evidence/mutation.json`を読み取り、設定した`mutationReport`はgateがこの
+ファイルへ変換するため、gate実行前の検証は「証拠なし」を報告します。
 
 CIではVitest、Jest、
 `pytest-json-report`付きpytest、Go test、Cargo test、固定版JUnit Platform Consoleの

package/README.md

@@ -1,6 +1,6 @@
 # musubix3
 
-**Latest release v0.1.4 · GitHub Copilot CLI only · Node.js ≥20 · TypeScript · MIT**
+**Latest release v0.1.8 · GitHub Copilot CLI only · Node.js ≥20 · TypeScript · MIT**
 
 [日本語](README-ja.md)
 
@@ -172,22 +172,29 @@ question at a time and waits for the answer; it does not batch questions or
 finalize requirements while blockers remain.
 
 1. Use native planning/research to establish intent and measurable acceptance.
-2. Record `change-record CHANGE-ID impact`, then edit/validate requirements and
-   record the `requirements` checkpoint.
-3. Design explicit components, record trade-offs in ADRs, then record `design`.
+2. Record `change-record CHANGE-ID impact`, edit/validate requirements, record
+   the `requirements` checkpoint, then obtain explicit artifact-bound human
+   `requirements` approval before design.
+3. Design explicit components, record trade-offs in ADRs, record `design`, then
+   obtain explicit artifact-bound human `design` approval before implementation.
 4. Write an annotated behavior test, record a structured failing `tdd red`, then
    record the change `red` checkpoint.
 5. Implement the minimum change, record `implementation`, run passing `tdd green`,
    then record `green` and refactor.
 6. Add trace annotations, build graphs, inspect impact and fix missing coverage.
-7. Configure real checks, run `gate --changed`, use native review/security review,
-   and inspect status before release. Do not weaken policy simply to pass.
+7. Configure real checks and run the candidate `gate --changed`. After every
+   required non-approval check passes, obtain explicit human `release` approval,
+   rerun the gate/status, and only then commit, push, publish, or deploy.
 
 ```sh
 npx musubix3 requirements validate .musubix/features/example/requirements.md --json
 npx musubix3 constitution validate --json
+npx musubix3 approval prepare requirements --json
+npx musubix3 approval record requirements --approver "Requirements Owner" --artifact-sha256 "$REVIEWED_HASH" --confirm
 npx musubix3 design validate .musubix/features/example/design.md --json
 npx musubix3 design c4 .musubix/features/example/design.md
+npx musubix3 approval prepare design --json
+npx musubix3 approval record design --approver "Design Owner" --artifact-sha256 "$REVIEWED_HASH" --confirm
 npx musubix3 change-record CHANGE-0001 design --requirement REQ-EXAMPLE-001
 npx musubix3 tdd red TEST-EXAMPLE-001 --requirement REQ-EXAMPLE-001 --command test
 # Implement the minimum behavior without changing the test.
@@ -198,6 +205,10 @@ npx musubix3 trace check --strict --json
 npx musubix3 graph index
 npx musubix3 graph impact src/service.ts
 npx musubix3 gate --changed --json
+npx musubix3 approval prepare release --json
+npx musubix3 approval record release --approver "Release Owner" --artifact-sha256 "$REVIEWED_HASH" --confirm
+npx musubix3 gate --changed --json
+npx musubix3 approval validate --json
 npx musubix3 status --json
 ```
 
@@ -217,6 +228,9 @@ validation/gate or requested solver failure, **2** usage, I/O or malformed confi
 | `constitution validate [file]` | Versioned principles and measurable rule definitions |
 | `design validate <file>` | Fields, global requirement IDs, existing ADR references |
 | `design c4 <file>` | Mermaid component/dependency diagram from explicit fields |
+| `approval prepare <requirements\|design\|release>` | Display the exact deterministic manifest and hash for human review |
+| `approval record <stage> --approver <name> --artifact-sha256 <hash> --confirm` | Record approval only if the reviewed hash is still current |
+| `approval validate` | Report each approval as approved, missing, or stale; never infer approval from validation |
 | `trace build` | Generate global trace snapshot and feature copies |
 | `trace check [--strict]` | Dangling IDs, stale inputs/paths, mandatory coverage |
 | `trace impact <id-or-path>` | Bidirectional breadth-first traversal with explanation paths |
@@ -233,6 +247,7 @@ validation/gate or requested solver failure, **2** usage, I/O or malformed confi
 | `model-correspondence validate` | Revalidate Formal JSON → generated trace → authoritative passing test evidence |
 | `evidence refresh [--changed]` | Regenerate derived evidence through the same fail-closed gate pipeline |
 | `mutation validate` | Revalidate requirement-scoped schema-v1 killed-mutant evidence |
+| `mutation identity <REQ-ID> <TEST-ID> <sourcePath> <operator> <line> <column>` | Print the deterministic `MUT-*` identity a mutation report must declare |
 | `tdd validate` | Validate persisted Red/Green/Refactor order, fingerprints, durations, and hash-chain evidence |
 | `tdd red\|green\|refactor <TEST-ID> --requirement <REQ-ID> --command <name>` | Execute and record a verified TDD phase |
 | `workflow-record <skill> <phase> --status <status>` | Record a compact self-reported workflow declaration |
@@ -347,6 +362,9 @@ export function guard() { /* actual implementation */ }
 ```
 
 One block comment per entity; comma/space-separated targets. `@design` is optional.
+In PHP, use plain `/* ... */` blocks rather than `/** ... */` PHPDoc: PHPDoc reserves
+`@implements` for generic type declarations, so PHPStan/Psalm report `phpDoc.parseError`
+on requirement-ID lists inside doc comments. musubix3 reads either form.
 Mandatory implementation coverage may be direct or through a linked design;
 tests must directly verify a requirement. Links alone are not semantic proof.
 Each feature's `trace.json` holds the complete repository snapshot, including
@@ -396,6 +414,7 @@ Example `.musubix/config.json` (adapt command arguments to your own project):
   "formal": { "solver": "none", "minModeledFraction": 0, "timeoutMs": 12000 },
   "mutation": { "mode": "compatible" },
   "tdd": { "redPreflightCommands": [] },
+  "approval": { "mode": "required" },
   "workflow": {
     "mode": "compatible",
     "maxAgeSeconds": 3600,
@@ -428,6 +447,20 @@ commands fail closed. Globs support `*`, `**`, `?`; external imports use `npm:`.
 identities, and `release` requires the complete formal, mutation, workflow,
 change, performance and CI-attestation checks. Stronger profiles reject missing
 or weakened settings rather than silently filling in evidence.
+`approval.mode` is `required` in newly initialized projects and requires current
+requirements, design, and release approvals. Existing schema-v1 configs that
+omit `approval` load in `compatible` mode. Approval files store the stage,
+approver, `approvedAt`, per-artifact SHA-256 values, and a deterministic manifest
+SHA-256. Run `approval prepare` before review and pass that exact hash to
+`approval record`; an intervening change is rejected and later changes become
+stale. Release recording recomputes the gate and requires every required
+non-approval check to pass rather than trusting cached quality evidence.
+The approver string is explicit local evidence, not authenticated identity;
+repositories that require independent identity must also use protected review,
+CODEOWNERS, or CI/OIDC controls.
+Local approval evidence records explicit intent but does not cryptographically
+authenticate the approver; protect release authorization with repository review,
+CODEOWNERS/branch protection, or CI/OIDC attestation.
 Use `tdd.redPreflightCommands` to reference plain configured formatter commands;
 they must pass before Red captures the authoritative test fingerprint.
 Conventional `.venv` and `venv` Python environments containing a regular
@@ -460,7 +493,7 @@ unchanged test file. Test names/output must contain their `TEST-*` ID.
 diagnostic codes are stable English; human status labels include Japanese.
 
 `.musubix/policy-baseline.json` records minimum required checks, coverage,
-architecture, formal policy, mutation mode, workflow strict/session/freshness settings,
+architecture, formal policy, mutation and approval modes, workflow strict/session/freshness settings,
 CI-required attestation and strict OIDC identity/key binding, and required
 command names. A baseline that requires TDD Red preflights must also include
 their normalized `commands` definitions, which prevents replacing a trusted
@@ -477,6 +510,13 @@ nonblocking unless a constitution rule rejects the measured count. No configured
 commands is skipped, not passed.
 TDD commands require either command-specific `tddArgs` plus a `tddReport`, or a
 built-in `vitest`, `jest`, `pytest`, `go-test`, `cargo`, `junit`, or `dotnet` adapter.
+The `junit` adapter drives the Java JUnit Platform Console launcher, not arbitrary
+JUnit-XML producers; runners such as PHPUnit that only emit JUnit XML need explicit
+`tddArgs`/`tddReport` (or `testReport`) configuration instead. A custom
+`musubix-json` report is a single-line-safe JSON document
+`{"schemaVersion":1,"tests":[{"id":"TEST-APP-001","status":"passed"}]}` where
+`status` is `passed`, `failed`, `skipped` or `error`, and an optional
+`"operations":{"counter":12}` map carries deterministic performance counters.
 Explicit custom configuration takes precedence. Adapters derive targeted
 arguments and normalize native JSON/JSONL/XML into `musubix-json`. Vitest/Jest
 reports may contain unrelated skipped tests; targeted TDD selects only the
@@ -501,7 +541,18 @@ change checkpoints additionally share a persisted monotonic order ledger, which
 is authoritative for Red/Green boundaries; wall-clock timestamps are
 informational. Legacy chronology without order evidence fails with an explicit
 migration diagnostic. Missing, reordered, altered or orphaned records invalidate
-the evidence.
+the evidence. Superseded cycles are never replaced by a newer recording: if any
+cycle lacks test-scoped provenance or a valid Red/Green, move
+`.musubix/evidence/tdd.json` aside and re-record every cycle from a clean Red
+baseline. There is deliberately no partial prune command, and hand-editing the
+evidence is unsupported.
+
+Deterministic mutant identities come from `musubix3 mutation identity
+<REQ-ID> <TEST-ID> <sourcePath> <operator> <line> <column>`, which prints the
+exact `MUT-*` value a schema-v1 mutation report must declare. `mutation
+validate` reads `.musubix/evidence/mutation.json`; a configured `mutationReport`
+is converted into that file by the gate, so validating before a gate run reports
+absent rather than passing evidence.
 
 CI executes isolated native contracts for Vitest, Jest,
 pytest with `pytest-json-report`, Go test, Cargo test, and the pinned JUnit

package/dist/packages/analysis/src/adapters.d.ts

@@ -1,5 +1,5 @@
 import type { CommandConfig } from './config.js';
-import type { MusubixTestReport } from './tdd.js';
+import type { MusubixTestReport } from './test-report.js';
 export type TestAdapter = NonNullable<CommandConfig['adapter']>;
 export interface AdapterInvocation {
     args: string[];

package/dist/packages/analysis/src/approval-record.d.ts

@@ -0,0 +1,6 @@
+import { type ApprovalEvidence, type ApprovalStage } from './approval.js';
+/** @id CODE-HUMAN-APPROVAL-GATES-002
+ * @implements REQ-HUMAN-APPROVAL-GATES-001 REQ-HUMAN-APPROVAL-GATES-006
+ * @design DES-APPROVAL-002 DES-APPROVAL-003
+ */
+export declare function recordApproval(root: string, stage: ApprovalStage, approver: string, expectedArtifactSha256: string): Promise<ApprovalEvidence>;