@awak-app/simy-cli 0.7.15 → 0.7.17

package/src/orchestrator/delivery/references/shared-system-specifications.md

@@ -1,163 +1,6 @@
-# Shared system specifications and delivery review
+# Shared behavior and specifications
+Read existing documentation when it helps understand the change. Keep materially affected descriptions accurate, using the repository's existing structure. Compare related surfaces where the same behavior crosses UI, API, storage or background processing.
 
-Read before planning a Delivery Loop change. The specification belongs to the
-system and its team, not to a single run. Use existing team paths and conventions;
-if none exist, start `docs/systems/<system-id>/` with an index and the applicable
-views below. Repository paths here are a convention, not a demand to move existing
-documents or to create a new service. Keep one canonical source for each concept.
+Do not require twelve views, a new specification set, a source ledger, an independent approval or SQM paperwork before implementation. Explain a consequential design choice where it helps maintainers, without duplicating source code or existing documents.
 
-## Shared baseline and proposed change
-
-The system index records its owner/maintainers, repository/document links, stable
-system ID, As-Is source revision(s) and environment, verified date, and gaps.
-Distinguish source-code behavior, locally observed behavior, and deployed behavior.
-An old design or green PR is not proof of current production behavior.
-
-At the start of each run:
-
-1. Freeze the experience contract from the original request before proposing a
-   solution: beneficiary/context, goal, complete usable outcome, observable
-   moments with what the person sees, understands, and can do next, recovery and
-   forbidden experiences, and the observation method. Read-only discovery may
-   inform this record. Give every moment a stable UX/acceptance ID.
-2. Read the existing index and current linked views. Reconcile relevant As-Is with
-   code and actual behavior; label unknowns, cite evidence, and correct documented
-   drift without claiming that the drift was part of the requested feature.
-3. Reconcile why the change matters against that contract: current difficulty,
-   observable success, and non-goals. Preserve the user's original request as an
-   independent acceptance source; do not replace their outcome with a component
-   or implementation inventory.
-4. Prepare a proposed To-Be on a branch/change proposal linked from the shared
-   system index. Record its baseline revision, affected stable IDs, before/after
-   behavior, dependencies and acceptance oracles. Reuse unchanged views by reference;
-   do not copy the whole specification into every run or generate empty diagrams.
-5. Link each experience ID to workflow, screen/control, state/sequence, API/event,
-   data/relationship, permission and runtime boundaries as applicable. Map these
-   stable system IDs to the run's criterion rows and implementation/evidence locations.
-6. Freeze the delivery-level review plan. At levels that require a separate
-   design review, obtain it before implementation; at level 3 the independent
-   final-candidate review may cover design, implementation and evidence together.
-   Supply the original request, shared baseline, To-Be and affected links. Missing
-   evidence or contradictory views remains pending/failed, never silently accepted.
-
-After the exact local candidate is built, update the existing acceptance matrix
-and its readable table for those same experience IDs. Compare expected experience,
-actual user observation, independent system result, evidence, status, and next
-repair across the whole journey. This is a view of the canonical acceptance data,
-not another specification. A gap between working parts blocks local user-journey
-promotion even if every part passed a narrower test.
-
-The twelve-view index must account for every category: present (with a canonical
-link), unchanged (with a revision), not applicable (with a reason), or unknown
-(with an owner/next action). Only create/update a diagram where it describes a
-real system concept. For CLI/skill systems, chat/terminal interactions can be the
-interface views; do not invent application screens, APIs, tables or infrastructure.
-
-| View | Primary content | Consistency checks against other views |
-| --- | --- | --- |
-| art-01-screen-inventory-final | Screens or user interaction surfaces and stable IDs | Every referenced screen/control in workflows, transitions and wireframes exists |
-| art-02-screen-transitions | Navigation, entry/exit, failure/recovery | Reachable inventory entries, correct permission guards and state conditions |
-| art-03-wireframes | Controls, content, empty/loading/error/success states | Each action has a requirement, transition and downstream sequence; no dead control |
-| art-04-functional-requirements | Purpose, beneficiary, outcomes, invariants, acceptance | Every request maps to implementation and evidence through the other affected views |
-| art-05-state-machines | Legal states, guards, terminal outcomes, retry/cancel | Sequences/events trigger legal transitions; UI messages match actual final state |
-| art-06-permissions | Actor/role, action, resource, authority boundary | UI guards, API checks, ownership and execution roles agree |
-| art-07-user-workflows | User goal, steps, completion and recovery experience | Requirements covered end to end through screens, APIs, persistence and runtime |
-| art-08-data-dictionary | Fields, meaning, type, requiredness, lifecycle and owner | API/event payloads, ER cardinality and state invariants use the same definitions |
-| art-09-sequences | Calls/events through components, errors, asynchronous completion | API names/payloads, states, authorization and deployed component boundaries agree |
-| art-10-api-design | Existing APIs, commands or file contracts, errors and compatibility | Sequence inputs/outputs, data meanings and permission checks agree |
-| art-11-er-diagram | Entities, relationships, ownership and cardinality | Dictionary and API reads/writes agree; label logical artifact models as non-DB |
-| art-12-infrastructure | Repositories, execution environments, services and trust boundaries | Every sequence participant has an actual host/owner; revision/rollout dependencies align |
-
-## Review evidence and neutral agents
-
-Required reviews use independent agents/sessions; an agent must not approve work
-it authored. Follow the risk-proportionate plan in `delivery-levels.md` instead of
-creating design, cross-view, implementation and PR reviews by default. A reviewer
-may cover several review kinds in one receipt when the candidate inputs are the
-same, and can re-review fixes it did not implement. Supply raw sources, not desired
-answers; require inspected references, discrepancies, uncertainty and a reasoned
-verdict. Use the repository-required model (gpt-5.5 / xhigh where mandated and
-available). If a required independent review is unavailable, report that gate as
-blocked.
-
-Persist a compact review receipt: reviewer/session identity, review kind, original
-request and shared baseline/To-Be references, candidate revisions, inspected views
-and evidence, findings, result, and re-review links. An independent reviewer checks:
-
-- coverage of the original request, user benefit and acceptance oracles;
-- consistency for every affected cross-view link, including unchanged neighbors;
-- behavior after actual operation, reload/session return and final persistence or
-  integration outcome where applicable;
-- implementation and tests against the proposed To-Be, not just against each other;
-- missing/extra functionality, stale evidence and unresolved historical regressions.
-
-A diagram syntax/link checker helps, but cannot replace semantic cross-view review.
-Do not declare neutral review merely by renaming the implementer's role.
-
-## SQM before and after PR creation
-
-Use the installed SQM loop skill. Respect explicit SQM opt-in, existing session and
-service authority. Explain unavailable gates; do not install global hooks, weaken
-rules, force an upload or switch organizations to obtain a pass.
-
-For each phase use fresh, separate local paths outside the diff (for example an
-ignored `.artifacts/delivery/<run>/sqm/pre-pr/` or `post-pr/` directory):
-
-```sh
-simy sqm min-check --base <actual-pr-base> --output <phase>/min.json
-simy sqm check --base <actual-pr-base> --min-result <phase>/min.json --proof <phase>/proof.json --signed-evidence <phase>/proof.json.signed.json
-```
-
-Use supported no-upload options when required by the authorized sharing scope.
-Read the proof and verify its repository, head, base, working-tree/diff identity,
-knowledge bundle version/digest and `outcome.status == passed`; verify the bound
-signature using SQM tooling. Exit zero alone is insufficient. Do not edit or commit
-between min-check and check. Pin the commit before the pre-PR check; writing proof
-into the committed diff would invalidate its identity.
-
-Before the pre-PR phase, inventory relevant known incidents from the team's shared
-incident records, SQM knowledge and repository regression history. Record incident
-or source ID, failure boundary, applicable/unaffected/unknown classification,
-regression command and result, SQM rule match/coverage, and residual gaps. Link this
-ledger from the shared specification so the next task can reuse and improve it.
-Separate confirmed incidents from synthetic risk scenarios; never invent history.
-Record the proof's outcome reasons and actual `executions`: matched module and
-rule counts, scenario evaluation statuses, and blocking versus advisory scope.
-Scenario evaluations do not assert that a real browser/provider journey executed.
-A zero-match/no-applicable-rules proof does not establish historical coverage.
-Use concrete regressions for relevant uncovered incidents and have an independent
-reviewer assess coverage; keep missing incident history or untested boundaries
-visible. No finite test promises absence of all future bugs.
-
-Draft creation: after authority and local regressions, publish a Draft so the exact
-remote candidate can be inspected. Draft existence is not gate approval.
-
-Before Ready or merge, pass the frozen review plan. When the explicitly opted-in
-plan requires SQM, run it against the final candidate; repair findings within the
-bounded loop and rerun affected gates. On an unavailable/failed required proof,
-retain Draft/not-ready and report the exact blocker while continuing independent
-authorized preparation.
-
-Post-PR: fetch and verify the actual PR head/base and current CI. Reuse the pre-PR
-SQM proof only when repository, head, base, working-tree/diff, specification,
-policy, knowledge bundle, evidence and relevant environment identities are exactly
-unchanged and the signed proof verifies. Rerun into a new path when any identity
-changed or a PR-only scanner/policy becomes applicable. Apply the same rule to
-independent review. If a required gate fails, retain the PR as draft/not-ready,
-repair and rerun affected gates. Preserve superseded receipts as history.
-Promote Ready only with current required gates, including applicable combined-state
-verification. Merge and deployment still require their own authority and evidence.
-
-## Team maintenance after verification
-
-Merge reviewed specification changes with the corresponding implementation through
-the normal team review process. Record proposed, implemented locally, merged and
-verified-in-environment status separately. Advance As-Is only for the revision and
-environment actually verified; a merged To-Be is not automatically production As-Is.
-Preserve the prior baseline and decisions in version history. If another change
-updates a shared view, reconcile its semantics and re-review affected links even
-when Git reports no textual conflict. Do not overwrite concurrent edits.
-
-Each run stores pointers, deltas and evidence in its receipt, not another competing
-master specification. Record unresolved drift with an owner, source and next action.
-Never lower the intended outcome merely to make an implementation match a diagram.
+Test the combined behavior when multiple repositories contribute to the requested result. Distinguish proposed, locally working, merged and deployed behavior. Avoid overwriting concurrent edits. Use SQM only when explicitly requested; its score or report does not establish a working user journey.

package/src/orchestrator/delivery/references/state-and-receipts.md

@@ -1,247 +1,6 @@
-# State and Receipt Contract
+# State needed to continue safely
+Keep enough existing controller state to resume the same task: its original request and corrections, current result, remaining defects, active operation, target identity, permissions, user stop and budget. Do not require separate delivery receipts, approval forms, matrices or evidence packages.
 
-Read this reference for multi-attempt, resumable, cross-repository, concurrent,
-merge, deployment, paid, or externally mutating work.
+Use single-writer updates or compare-and-set for concurrent execution. Preserve operation IDs and provider acknowledgments where they prevent duplicate effects. The same operation ID with different content is a conflict. Reconcile unknown external results before retrying; an absent response is not proof of failure.
 
-## Delivery snapshot
-
-Persist one controller-owned snapshot with at least:
-
-- `run_id`, `state`, monotonic `revision`, and terminal disposition;
-- immutable explicit conditions and their stable digest;
-- frozen experience-contract identities, their mapping to acceptance rows, and
-  the current readable local-experience table path and digest;
-- acceptance-source identities and digests, architecture boundaries, applicable
-  rule decisions, human-decision receipt IDs, approved canonical sources and
-  their precedence and fallback semantics, risk tier, requested/effective
-  delivery levels, numbering version, safety floor and reason, complete five-level
-  comparison with per-level hour estimates and assumptions, recommendation and
-  rationale, and actual user selection receipt only when applicable; preserve legacy numbering and record
-  verified conversions separately rather than rewriting historical choices;
-- repository, base SHA, head SHA, companion SHAs, merge SHA, image digests, and
-  deployed revision;
-- target environments, user journey, user/tenant fixture identities, and
-  required artifacts;
-- applicable gates and their current status;
-- frozen acceptance charter digest, current matrix/table paths and digests,
-  superseded matrix snapshots, and the acceptance validator result for each gate;
-- verification-boundary changes, deferred-debt references, and applicable
-  outcome and guardrail measures, rollout policy, current rollout stage and
-  latest deterministic release decision;
-- attempt number, retry/time/cost budgets, and failure fingerprints;
-- append-only receipt IDs, evidence references, timestamps, and cleanup state.
-
-Use compare-and-set or an equivalent single-writer protocol. Replaying the same
-receipt must be a no-op. Reusing an idempotency key with different content is
-an integrity failure.
-
-## Typed receipts
-
-Use the smallest applicable receipts rather than free-form completion claims:
-
-- `CharterReceipt`
-- `HumanDecisionReceipt`
-- `FailureReproductionReceipt`
-- `ImplementationReceipt`
-- `LocalVerificationReceipt`
-- `AcceptanceEvidenceReceipt` (matrix completeness, not overall completion)
-- `IndependentReviewReceipt`
-- `PRCIReceipt`
-- `IntegrationVerificationReceipt`
-- `ContainerEnvironmentReceipt`
-- `ChromeUserJourneyReceipt`
-- `MergeReceipt`
-- `DeploymentIdentityReceipt`
-- `RolloutStageReceipt`
-- `OutcomeEvaluationReceipt`
-- `HealthReceipt`
-- `LiveEvidenceReceipt`
-- `CleanupReceipt`
-- `CompletionReceipt`
-- `FailureReceipt`
-
-Each receipt should contain:
-
-- schema version, Run ID, module, result ID, input digest, idempotency key, and
-  production time;
-- `success`, `retryable_error`, or `terminal_error`;
-- source revisions and environment identity;
-- executed action and observed result;
-- evidence references such as commands, exit codes, logs, screenshots, video,
-  network traces, DB rows, artifact hashes, CI/deploy URLs, and timestamps;
-- a typed error category and retryability when unsuccessful.
-
-A `HumanDecisionReceipt` additionally stores or immutably references the exact
-decision packet presented to the human. Preserve the question and scope; every
-option's user benefit, user and operational risk, compatibility and migration
-effects, fallback behavior, reversibility, support and maintenance cost,
-security and trust-boundary constraints, validation plan, and material evidence
-gaps; any excluded unsafe or non-compliant option and its reason; and any
-recommendation separately from the decision. Record the selected option's exact
-text and stable ID or digest, conditions attached to the selection, decision
-maker, timestamp, and a stable approval reference such as a message or turn ID
-or an immutable transcript or artifact digest, with its channel and context when
-applicable. The selection may reference a viable presented option or an explicit
-user-authored modification or combination. When the user's decision is clear,
-executable, and introduces no undisclosed material trade-off, update the packet
-and record that same message as approval without requesting confirmation again.
-If the decision is ambiguous or introduces a material trade-off not yet explained,
-clarify only the unresolved point before proceeding with dependent work. Mandatory
-security, privacy, data-integrity, and external-contract constraints still apply.
-
-For a reversible delegated decision, record an AI decision in the existing
-snapshot: source evidence, alternatives, selected option, rationale, assumptions,
-rollback and verification. It is not a HumanDecisionReceipt and does not create
-new provider authority. Do not emit needs_hil merely because sources conflict,
-risk is high or an AI recommendation needs a choice. Apply the 102 perspectives
-as critique of the grounded AI judgment.
-
-A successful `HumanDecisionReceipt` still requires an explicit selection when
-irreversible consequences or an explicitly reserved human choice require it.
-Only that operation remains needs_hil; independent authorized work proceeds.
-Silence is not approval of an irreversible operation. When the matching decision
-arrives, continue within the existing task without a second resume request,
-unless the user explicitly stopped/paused it.
-
-## Monitor verdict and policy action
-
-The controller persists `thread_state.objective_contract` with the baseline,
-current version, digest and explicit human revision lineage. Each attempt stores
-`outcome_progress` with its objective digest, independently supported criterion
-IDs, unproven IDs and assessment availability. `evaluateOutcomeProgress` separates
-current `verified_ids`, `failed_ids`, and `unassessed_ids`; executor test counts,
-commits, evidence hashes and reference paths cannot create progress. A new
-independently verified criterion resets `no_progress_attempts`. A prior proof
-missing from the current review remains unassessed, rather than silently passing.
-The historical verified-ID set is used only for comparison, so repeating an old
-proof after a regression cannot manufacture new progress.
-
-Progress continuation uses `{ policy: "progress", maxNoProgressAttempts: 3 }`
-with `assessOutcomeProgress`. Three attempts without new verified outcomes,
-including attempts that never reach independent review, mark `stalled` with a
-specific `stall_reason`. The pure evaluator accepts the same threshold for
-Delivery. Legacy runs retain their original stopping policy until the controller
-selects progress continuation. Partial independent proof can show progress even
-when the overall audit fails; a complete passing audit is still required for
-completion. Human and external blockers remain visible alongside machine repairs
-in `blockers` and `next_actions`; they do not imply every criterion is blocked.
-
-Audits bound to a different objective or current candidate evidence identity
-cannot supply progress. Revisions reset the comparison baseline and require a
-fresh independent review. An old review cannot settle a newer
-objective version. Legacy snapshots without an objective contract remain
-readable but lose completion status on restore; their original baseline cannot
-be reconstructed retrospectively. `USER-GOAL` is tracked separately from
-caller-supplied criteria and requires direct independent outcome evidence.
-
-The executor can propose evidence, and the independent auditor can assess it.
-Only the controller computes the progress verdict and state transition. No new
-database is required. The CLI writes a redacted private local snapshot before
-publishing a state, restores it after restart, and retries Web ledger updates.
-The authenticated daemon periodically rechecks PR-ready runs while it is
-running. Neither the local record nor the daemon proves that a user outcome
-was achieved without independent operation and postcondition evidence.
-
-The semantic monitor may emit:
-
-```text
-status:
-  on_track
-  insufficient_evidence
-  goal_drift
-  retryable_failure
-  needs_hil
-  blocked
-  completed
-
-recommended_action:
-  continue
-  retry_current
-  propose_replan
-  request_hil
-  abort
-  complete
-```
-
-The deterministic policy gate checks authorization, applicable state routes,
-revision identity, evidence completeness, idempotency, retry budget, repeated
-failure fingerprints, and external-effect ambiguity before accepting the
-recommendation.
-
-Do not expose hidden chain-of-thought. Publish only the typed verdict, concise
-reason, selected action, and evidence references.
-
-## Evidence invalidation
-
-Evidence is revision-bound:
-
-| Change | Invalidate |
-|---|---|
-| Charter or explicit success conditions | All affected downstream gates |
-| Human decision, canonical source, precedence, or fallback | All dependent implementation and verification evidence |
-| Acceptance source, test oracle, assertion, or CI/security gate changes | The affected gate and all dependent downstream evidence |
-| Head SHA or generated source changes | Local, CI, integration, container, and live evidence |
-| Base SHA or companion revision changes | Integration and later evidence |
-| Container image digest changes | Container user journey and later runtime evidence |
-| Merge SHA changes | Deployment identity and live evidence |
-| Deployed revision changes | Health and live evidence |
-| Browser profile, tenant, or fixture changes | Affected user-journey evidence |
-| Outcome/guardrail signal, source, window, threshold, decision, or owner changes | Affected release and outcome evidence |
-| Rollout stage, exposure, recovery control, or kill switch changes | Affected rollout and later live evidence |
-
-Do not discard historical receipts; mark them superseded for the current gate.
-
-## Failure handling
-
-Classify failures before retrying:
-
-- code defect;
-- stale or wrong revision;
-- environment/configuration drift;
-- weak or contaminated fixture;
-- external provider, authorization, rate limit, or timeout;
-- contract/schema drift;
-- persistence, concurrency, projection, cache, or replica race;
-- evidence collection failure.
-
-Retry only when the classification and policy permit it. Reconcile ambiguous
-external effects before retrying. Preserve passing work and repair the smallest
-affected surface. Repeated fingerprints require root-cause repair, replan, or
-human input rather than identical retries.
-
-## Completion predicate
-
-For the full delivery mode:
-
-```text
-done =
-  reproduction_verified
-  && acceptance_evidence_complete
-  && minimum_functional_evidence_verified
-  && locally_verified
-  && pr_ci_green
-  && integration_verified
-  && user_like_local_verified
-  && merged
-  && deployed_exact_revision
-  && health_verified
-  && live_verified
-  && production_outcome_evaluated
-  && cleanup_verified
-  && completion_receipt_created
-```
-
-Remove only genuinely non-applicable terms and record why; production outcome
-evaluation is non-applicable when no production-impacting release is in scope. If merge or deploy
-is outside current authority, stop at the highest proven pre-authority state.
-
-Acceptance evidence must cover every applicable criterion for the target gate,
-with current context and the required user/system layers. After each evaluated
-action, refresh the JSON matrix and its readable table; append a receipt for the
-update. Keep the frozen charter distinct from mutable results. A charter patch
-supersedes the old digest only after the controller verifies its authority.
-For `user_like_local_verified`, the current table must cover the frozen experience
-contract from real trigger to usable outcome for the exact local candidate. A
-collection of narrower passing rows does not waive a missing end-to-end row.
-
-The CLI records minimum evidence in observed_evidence.minimum_completion, independently of executor status. The independent audit is bound to its matrix digest. Legacy v2 histories remain readable, but missing minimum evidence cannot be reused as passing evidence on resume/recheck. Missing or unsupported charters require a refresh; they do not disable verification.
+Bind a result to the version and environment actually checked. A local result does not establish deployment. Recheck affected behavior after relevant inputs change, without discarding unaffected results. Record actual user authorization in existing state; never invent approval or request it again when it is already clear.

package/src/orchestrator/delivery/references/state-model.md

@@ -1,187 +1,6 @@
-# Delivery Loop の統合状態モデル
+# Delivery state
+Continue the original request through implementation, direct verification and repair. Finish at the requested endpoint when the behavior works. Explicitly requested independent review is supported; it is not a default stage.
 
-現行CLIの正本。対象は CLI Agentic Loop (`src/orchestrator/loop.js`) と、
-そのexecutorが従うDelivery workflow。ローカルhook型Loopとは区別する。
-図は新しいruntime enumや自動スケジューラを追加しない。
+Wait for actual external dependencies and preserve the resumption condition. Respect user stops and permissions. Reconcile uncertain operations before replaying them. A reference-document update does not invalidate a working result.
 
-## 1. 利用者が判断する全体図
-
-目的は、元の依頼を満たした証拠が揃うまで、安全に実装・検証を続けること。
-「今どこまで証明できたか」「次に何をするか」「今回の終了理由」を分けて保持する。
-以下はexecutor/auditorの行動契約であり、各矢印がCLIに自動実装済みという意味ではない。
-
-```mermaid
-flowchart TD
-  Contract[目的・体験・成功条件・権限・終了地点を固定] --> Baseline[現状と再現を確認・リスク相応のレビュー計画]
-  Baseline --> Work[実装・修正・不足証拠の取得]
-  Work --> Verify[現在の版で検証・チェックリスト更新]
-  Verify --> Review[独立レビュー・元の依頼と証拠を照合]
-  Review --> Decision{未達の原因と次の行動}
-  Decision -->|安全に修正・再検証できる| Work
-  Decision -->|CI等が進行中| Wait[上限のある待機・再確認]
-  Wait --> Verify
-  Decision -->|本当の権限・入力不足／進捗停止| Hold[未完了を記録・独立して進められる作業は続行]
-  Hold -->|不足解消・必要な承認・再開| Verify
-  Decision -->|全行と適用ゲートが合格| Endpoint{固定した終了地点}
-  Endpoint -->|PRまで| PR[PRの検証結果・残る非対象作業を記録]
-  Endpoint -->|配備までの権限あり| Release[マージ・exact revision配備・段階的な公開]
-  Release --> Live[health・実利用経路・成果とguardrailを観測]
-  Live -->|未達・回帰| Recovery[公開保留／権限内のrollback・修正]
-  Recovery --> Work
-  Live -->|合格| Cleanup[cleanupと最終証拠を確認・As-Is更新]
-  PR --> Final[元の依頼・全行・終了地点を最終照合]
-  Cleanup --> Final
-  Final -->|現在の証拠で全条件合格| Complete[依頼範囲の完了を報告]
-  Final -->|不足・失効| Decision
-```
-
-- チェックリストの◎相当は現行表記の **✅**。適用する体験・技術の両層に、
-  現在の候補と条件に束縛された合格証拠が必要。🟡・❌は完了ではない。
-- 目的・体験ID・受入条件は保持する。全行を消さずに修正→検証→更新を繰り返す。
-  個別の軽微な指摘の扱いは実際の監査判定に従い、未達の受入条件を軽微扱いして免除しない。
-- PRのみの依頼はmerge/deployを許可しない。一方、配備までの依頼をPR作成で終えない。
-- 自動待機を装わない。利用できるbounded wait/recheckまたは承認済みmonitorを使い、
-  継続不能なら具体的な制約と再開条件を残す。停止指示は尊重する。
-- 修正によってhead/base/設定/依存版/環境/成功条件が変われば、影響する証拠を失効させて
-  再検証する。過去の合格履歴は消さず、現在も合格とは扱わない。
-
-## 2. 証明済みの到達段階と品質ゲート
-
-次の13段階は成果のmilestoneであり、下節のcontroller stateとは別。
-順番だけで昇格せず、適用証拠を確認する。非該当は理由を明示する。
-
-```mermaid
-flowchart LR
-  chartered --> reproduction_verified --> implemented --> locally_verified
-  locally_verified --> pr_ci_green --> integration_verified --> user_like_local_verified
-  user_like_local_verified --> merged --> deployed_exact_revision
-  deployed_exact_revision --> health_verified --> live_verified --> cleanup_verified --> done
-```
-
-| 昇格箇所 | 保持すべき品質ゲート |
-|---|---|
-| chartered / reproduction_verified | 元の依頼・完全な利用体験・As-Is差分・成功契約・権限・レビュー計画 |
-| implemented / locally_verified | 修正、体験全体と技術的不変条件、必要な独立レビュー、現行証拠 |
-| PR準備と検証 | PR preparationの8行と4条件付きsafeguard、最新remote base/current head、CI・E2E・skip開示・差分・cleanup。明示opt-in時のSQM |
-| integration_verified / user_like_local_verified | 統合候補と実利用同等の経路。CI greenだけでは代替しない |
-| merged / deployed_exact_revision | 各操作の権限、正確な配備版、rolloutのpromote/hold/rollback条件 |
-| health_verified / live_verified | 稼働確認と利用者の成果を区別し、必要な観測windowとguardrailを検証 |
-| cleanup_verified / done | 適用する後片付け・最終受入条件・receipt。検証済みAs-Isを更新 |
-
-この表はworkflow上の要求。各条件の機械検証範囲は既存validatorとcollectorに従い、
-図だけを根拠に検証済みとはしない。詳細は [state and receipts](state-and-receipts.md)、
-[minimum completion](minimum-completion.md)、[acceptance evidence](acceptance-evidence.md)。
-PR範囲の完了を報告しても、未配備のmilestoneを `done` に進めない。
-
-## 3. 現行controllerの実際の制御
-
-以下は `loop.js` / `audit.js` と保存済みworker結果の復帰経路。`Gate`、`Receipt`、`RecheckGate`、`Failure` は説明用の判定節点。
-新規runの契約不備は `waiting_human`。resume時も目的・minimum契約を再検査する。
-
-```mermaid
-flowchart TD
-  queued --> Gate{目的・minimum契約の検査}
-  Gate -->|不備| waiting_human
-  Gate -->|新規| risk_classifying
-  risk_classifying -->|charter不備| waiting_human
-  risk_classifying -->|有効| chartering
-  chartering --> Receipt{保存済みworker結果の検査}
-  Gate -->|resume・既存attempt・契約有効| Receipt
-  Receipt -->|保存結果なし| dispatching
-  Receipt -->|保存結果が不正| waiting_human
-  Receipt -->|有効な完了結果・同じattemptを復帰| collecting_evidence
-  dispatching --> coding --> collecting_evidence --> auditing
-  coding -->|完了結果の保存失敗・復帰対象外で照合待ち| failed
-  collecting_evidence & auditing & independent_auditing -->|有効な保存結果あり・controller例外| failed
-  collecting_evidence -->|保存結果あり・収集の再試行も失敗| waiting_human
-  independent_auditing -->|保存結果あり・証拠再収集の再試行も失敗| waiting_human
-  auditing -->|合格| independent_auditing
-  auditing -->|不合格| Failure{失敗原因・進捗・再試行判定}
-  independent_auditing -->|証拠を再収集し監査・独立レビュー不合格| Failure
-  independent_auditing -->|両方合格・PR条件未達| pr_ready_for_review
-  independent_auditing -->|両方合格・PR条件全合格| merge_ready
-  Failure -->|修正可能| re_instructing
-  re_instructing --> dispatching
-  Failure -->|同一失敗／成果の進捗なし| blocked
-  Failure -->|人の入力が必要／連続して評価不能| waiting_human
-  pr_ready_for_review -->|callerまたはdaemonのrecheck| RecheckGate{目的契約とレビューの目的digest}
-  merge_ready -->|callerまたはdaemonのrecheck| RecheckGate
-  RecheckGate -->|不備| waiting_human
-  RecheckGate -->|有効| checking_pr
-  checking_pr -->|現在の証拠・レビュー束縛を含むPR条件未達| pr_ready_for_review
-  checking_pr -->|現在のPR条件全合格| merge_ready
-  blocked -->|原因解消・許可されたresume| Gate
-  waiting_human -->|入力・許可されたresume| Gate
-  failed -->|復旧対象の完了結果あり・runnerで復元| waiting_human
-  waiting_human -->|中断復元・有効な完了結果・daemonの認証と作業権限確認| Gate
-```
-
-- 実行中のstop確認点で `stopped` に戻る。図は割込みを全辺に描いていない。
-  停止を自動解除しない。`local_stop_requested` を保持し、手動停止をdaemonの復帰対象にしない。
-- `handleFailedAudit` は失敗原因を決定論的に分岐する。修正可能な失敗は
-  `re_instructing` から次のattemptへ。成果評価不能は成果の停滞と同一視しない。
-- `budget.js` は現在 `local_limits_removed: true`。token/回数は観測・通知の値で、
-  `canStartProvider` は消費量で止めず `codingAttemptCeiling` は無限。
-  旧版の「3回／予算切れ→終了」を現行の通常経路として復活させない。
-  残っているbudget停止用コードは現行の到達可能な通常経路として描いていない。
-  外部providerの制約や停止・承認・進捗保護を無視してよいという意味ではない。
-- `runCodingLoop` はPR readinessを返すと終了する。既存attemptがあり、保存済み
-  `completed_worker_result` がない非resume呼出しは `checking_pr` で再評価し、
-  再実装・新しい独立レビューは行わない。修正や新しいレビューが必要なら、
-  適切なresumeで新attemptを実行する。保存済み結果がある場合は下記の復帰経路になる。
-  既存の認証済みdaemonは稼働中、作業実行が許可され、他のoperation/childがない
-  PR-ready runを定期recheckする（`agent.js` / `runner.js`）。daemon不在・認証切れでは
-  この監視を期待できず、recheck自体は修正attemptを開始しない。
-  この資料は追加のmonitorや自動resumeを起動しない。
-- 有効な `completed_worker_result` があれば、同じattemptのworkerを再実行せず
-  `collecting_evidence` から監査・独立監査をやり直す（`completed_worker_result_recovered`）。
-  保存結果は受入証拠ではなく、run・目的digest・attempt等への束縛を再検査する。
-  不正な結果は `WORKER_RESULT_UNVERIFIED` で `waiting_human`。
-  保存結果がある証拠収集は最大2回再試行し、失敗が続けば結果を保持したまま
-  `EVIDENCE_COLLECTION_UNAVAILABLE` で `waiting_human`。再開時も同じattemptから再収集する。
-  完了結果の永続化失敗は `worker_result_persistence_failed` をrunnerへ伝え、
-  `failed` と照合待ちを記録する。保存に失敗した結果を安全な復帰用receiptと扱わない。
-- 既存daemonは、中断状態（または `controller_result_recovery` 付きの `failed`）を
-  復元すると、目的・結果・actor束縛・認証・作業権限を確認し、停止要求や他のoperation/childが
-  なければ `recoverCompletedLocalCodingRun` で検証を自動復帰する。
-  すべての `waiting_human` を自動解除する機能ではなく、通常のPR recheckとも別経路。
-  この既存の復帰制御を説明する資料であり、新しいdaemonやLoopの起動を許可するものではない。
-- recheck前の目的契約不正、または評価済み成果の `outcome_progress.objective_digest` 不一致は
-  `waiting_human`。head/base等に対する `evidence_identity_sha256` の失効・不足は
-  PR readinessの未達として `pr_ready_for_review` になり、同じ扱いではない。
-- `pr_ready_for_review` はpending状態で、名前だけでは実装の合格さえ保証しない。
-  recheckで古い証拠が失効した場合もこの状態になる。checksとpending reasonsを読む。
-- `merge_ready` と `done_gate_passed` は現在のPR readiness判定。
-  マージ実行、配備、元の依頼全体の完了を証明しない。
-
-## 4. 最終報告と証拠の失効
-
-`verified_complete / best_available / blocked / failed / cancelled` はworkflowの
-終了理由。controller enumと混ぜたり、すべてを `done` に変換したりしない。
-`verified_complete` は固定した依頼範囲の全条件が現在の証拠で満たされた場合のみ。
-
-| 変化・停止 | 必要な行動 |
-|---|---|
-| head/base/環境/依存版の変化 | 影響する証拠をpendingに戻し、同じ受入IDで再取得・独立照合 |
-| 承認された目的変更 | successor契約として履歴保持。旧目的のレビューを再利用しない |
-| CIや依存処理の実行中 | bounded wait/recheck。重複jobを起動せず、未変化だけでblockedにしない |
-| 人の権限・入力が本当に不足 | affected IDs、根拠、必要入力、owner、再開条件を記録。独立作業は継続 |
-| 同じ失敗・成果停滞 | 原因と別の安全な方針を検討し、controllerの保護を迂回せず再開 |
-| 中止 | チェックポイントと最高到達段階を保持し、未完了として報告 |
-
-これは既存制御の説明とexecutor/auditorへの契約であり、追加の遷移強制validatorではない。
-
-## 5. 過去版との比較と採用理由
-
-| 版 | 採用する点 | 単独では足りない点 |
-|---|---|---|
-| [9月8日 Slack仕様](https://specialist-doctors.slack.com/archives/C04URHQBJV7/p1788832579923809) | 13 milestones、単一controller、証拠・終了理由の分離 | 当時の回数・予算停止を現行に適用できない |
-| [9月14日 #79](https://github.com/SpecialistDoctors-Inc/simy-cli/pull/79) | 未達→修正→再検証、確認不能からの復帰、minimumと全体完了の区別 | 体験全体・PR準備・rolloutの詳細が足りない |
-| [9月16日 #97](https://github.com/SpecialistDoctors-Inc/simy-cli/pull/97) | 体験・レビュー計画・PR preparation・段階的配備・As-Is更新 | 主経路中心で、待機・修正・再開や実装との対応が読み取りづらい |
-| 現行CLI 0.6.11 / 基準commit `3b9b453` | 実際の修正ループ、完了済みworker結果からの検証復帰、証拠再取得、進捗保護、PR recheck | workflowの13 milestonesとcontroller stateを一つの状態として読むと誤解する |
-| 本統合版 | 全体判断図＋到達段階と品質ゲート＋実装制御図を相互参照 | 図や指示による保証範囲を超えた自動制御は追加しない |
-
-8月31日・9月2日のSlack ZIP添付は存在と名称のみ確認でき、本文を取得できなかったため、
-内容の優劣を断定していない。上表は読めた一次資料と現行ソースに基づく選定。
-未マージPRの機能は現行として含めない。更新時は `loop.js`、`audit.js`、`budget.js`、
-`outcome-monitor.js`、`checklist-continuation.js`、`coding-run-recovery.js`、`runner.js`、`agent.js` と突合し、3層を一緒に見直す。
+Controller states describe execution and actual remaining work. They must not advance merely because paperwork is complete, or remain blocked merely because a form is absent. Local implementation, PR readiness, merge and deployment describe different outcomes.