phronomy 0.29.0 → 0.30.1

data/docs/architecture/structured-output-and-scope.md

@@ -0,0 +1,183 @@
+# Structured Agent output and application lifetimes
+
+This contract supersedes the parser fallback described in the earlier Generation
+ownership documents. Agent owns the promise made by `output_schema:`; Generation
+owns the draft/review protocol and evaluation; the application owns publication,
+authorization and any decision to start another attempt.
+
+## Public behavior
+
+`Agent::Base#invoke`, `invoke_async`, `stream`, `stream_async` and
+`start_reserved_async` accept `output_schema: nil`. `run_once` forwards this option.
+Without a schema the existing free-text behavior remains. With a schema, successful
+`output` and `result` are deeply frozen JSON objects with String keys; `raw_output`
+preserves the model text. Token events are provisional, not validated objects.
+The final Task and terminal event are produced only after validation. Output
+filters run before validation and cannot silently break the promised shape.
+
+```ruby
+schema = {
+  type: "object", properties: {answer: {type: "string"}},
+  required: ["answer"], additionalProperties: false
+}
+value = Phronomy::Agent.open_scope do |scope|
+  agent = scope.create(AnswerAgent)
+  agent.invoke_async("Explain the result", output_schema: schema)
+end
+puts value.fetch(:output).fetch("answer")
+```
+
+C17 `OutputParser::JsonSchemaParser.new(schema:).parse(text)` performs strict JSON
+decoding and JSON Schema validation. It does not extract fenced JSON, remove model
+control tokens, coerce numbers, clamp scores or repair missing fields. Duplicate
+keys, comments, invalid escapes, control characters and nonfinite values fail.
+Existing extraction-oriented parsers remain available for their separate purposes;
+they do not define Agent's structured-output guarantee.
+
+The supported vocabulary is `$schema`, `$defs`, `$ref`, title, description, type,
+enum, const, anyOf, properties, required, additionalProperties, items, minItems,
+maxItems, minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf,
+minLength, maxLength and pattern. The root must declare type object. Nested nullable
+values and local JSON Pointer references are supported; external/cyclic references,
+unknown keywords, invalid patterns and invalid schemas are rejected before model
+or Tool execution. The dialect is JSON Schema 2020-12. Schema input accepts JSON
+values and String/Symbol keys, snapshots recursively, and rejects duplicate normalized
+keys, Ruby objects and cycles. Generic schema interpretation belongs to C17, not
+Tool::Schema, Agent's caller or Generation.
+
+## Native transport and completion facts
+
+C09 `LLMAdapter::Request#response_schema` carries the immutable schema; each model
+turn retains it. RubyLLM `with_schema` sends native schema configuration. The
+transport tests cover RubyLLM 2.0.0 OpenAI/Azure Chat Completions and Responses,
+Anthropic, Gemini and Ollama's OpenAI-compatible endpoint. Constraints are compared
+with the actual HTTP payload. SDK removal of root schema/title annotations does not
+change validation. These are offline protocol tests, not certifications of every
+remote model. Known model capability failures and native schema rejection raise
+`LLMAdapter::StructuredOutputUnsupportedError` (`llm.structured_output_unsupported`).
+Unregistered OpenAI-compatible local models may attempt native schema delivery.
+Other providers are rejected explicitly for structured requests until their native
+transport has been verified. There is no downgrade to JSON mode or prompt-only
+instructions. Tool capability is checked too when the model catalog is available;
+remote schema/Tool combination rejection remains a provider failure.
+
+LM Studio's HTTP 400 string error `Cannot combine structured output constraints
+with lazy grammar` is a known native schema/Tool rejection. It is classified as
+`StructuredOutputUnsupportedError` with its original cause, for both complete and
+stream operations. Unrelated string errors and requests without a schema retain
+their ordinary transport-error behavior. The adapter neither downgrades schemas
+nor replays requests. RubyLLM's configured transport retry policy is independent.
+The minimum Faraday streaming callback omits the HTTP status, so RubyLLM may
+surface this same exact rejection as `ServerError`; its cause is preserved too.
+That synthetic server status can trigger SDK retries before the adapter receives
+the error. Adapter replay tests disable SDK retries to verify their own boundary.
+
+`Response` records finish_reason (stop, tool_calls, length, content_filter, refusal,
+unknown), refusal and raw_finish_reason metadata. Only normal final completion can
+be a structured success. Tool requests are intermediate; they retain existing
+approval, denial, cancellation and recovery behavior. RubyLLM 2.0 loses streamed
+refusal fields in Chunk values; operation-local Protocol subclasses capture these
+raw facts. No SDK global class or shared protocol registry is patched. The SDK's
+raw finish information is retained through saved-response recovery.
+
+JSON 2.21.2 is the verified minimum for the strict decoding flags and deterministic
+schema serialization; the minimum dependency CI pins JSON 2.21.2 and RubyLLM 2.0.0
+alongside the existing minimum HTTP dependencies. Unknown SDK or parser faults
+remain failures, not poor-quality Generation results.
+
+## Failure and persistence
+
+`Agent::OutputError < Phronomy::Error` exposes execution_id, schema_digest, reason,
+violations and raw_output. Violations contain pointers/keywords without embedding
+model text. Raw text is explicitly available for controlled diagnostics; generic
+error messages do not interpolate it.
+
+| Code | Reasons |
+| --- | --- |
+| agent.output_invalid | invalid_json, schema_mismatch, missing_output |
+| agent.output_refused | model_refusal |
+| agent.output_incomplete | length, content_filter, unknown_finish_reason |
+
+Agent owns error translation. Parser invalid_json/schema_mismatch become OutputError
+with the original cause. A saved error is restored by its explicit owner codec;
+no arbitrary class name is constantized. Other transport, cancellation, Tool and
+internal failures keep their existing behavior. Output failure never triggers an
+automatic regeneration or replay of a completed Tool operation.
+
+Execution metadata stores `output_contract` version 1, schema_ref and schema_digest
+at admission. Digest is SHA-256 of UTF-8 JSON generated with recursively sorted keys
+(JSON 2.21.2 `sort_keys: true`); the exact same representation is saved in ContentStore.
+This format preserves arbitrary JSON integers and finite floats, including -0.0,
+without applying the narrower Common canonical-domain number rules. Each Context
+Manifest retains response_schema_ref, including budget projection and recovery.
+New executions may choose another schema; existing executions cannot replace their
+schema on resume/approval or by reusing a reserved ID with a different digest.
+Generic config/provider schema overrides are rejected.
+
+Structured success stores JSON result plus raw_output_ref and result_format=json.
+Old records without output_contract remain facts from a free-text execution; no
+schema is added retroactively. The execution codec stays at 0.2: its extensible
+metadata contains the explicitly versioned output contract. Unknown output-contract
+versions or digest mismatch fail closed. Saved LLM responses include finish_reason,
+refusal and metadata; missing finish evidence is unknown, never assumed normal.
+Fresh-runtime and new SQL connection-pool tests verify success, failure and approval
+continuation without replay of confirmed LLM/Tool work. This is a durable-facts
+claim, not an external side-effect exactly-once guarantee.
+
+## Generation evaluation
+
+C03 specifies the fixed protocol: draft answer/string, confidence/number in 0..1,
+citations/array; review approved/boolean, score/number in 0..1, feedback/string.
+All outer fields are required and additional properties are forbidden. Default
+citation objects require source and excerpt strings. `citation_schema:` customizes
+the citation object only; local references are rebased when embedded, without
+rewriting const/enum data. Generic validation remains with Agent/C17.
+
+The old draft_parser/review_parser arguments, DefaultParser, ParseError fallback,
+score clamping and Generation parser composition wiring are removed. C03 receives
+validated String-key values and performs domain evaluation only. Invalid output
+returns `Result` with termination_reason=output_failed, interrupted_phase, failure,
+confidence=nil and review_approved=nil. Failed draft clears any previous answer;
+failed review retains the current valid draft. iterations counts successful drafts.
+A valid score of zero can still satisfy a zero threshold; invalid data cannot.
+Normal low-quality output follows the configured evaluation loop as before.
+
+`Result#failure` is nil except for output_failed, where it carries the owned error
+diagnostic (without raw_output). Hash/JSON round trips, equality, hashing and freeze
+include it. `Result.from_h` requires every new field; migrate old saved Result JSON
+explicitly with `scripts/migrate_generator_verifier_result.rb OLD.json NEW.json`.
+The script adds failure=nil, validates the result and creates a new file. It does
+not overwrite the source or silently alter invalid data. `raise_if_unaccepted`
+retains the Result and the original OutputError cause in the same process.
+
+## Symmetric lifetime rules
+
+`Agent.open_scope` and `GeneratorVerifier.open` wait exactly once when the direct
+block return is a TaskResult. They then attempt all releases. Other values, arrays
+and nested Tasks are not recursively awaited. Failure/cancellation is re-raised
+with the same identity if cleanup succeeds. Double failure retains primary_error,
+all cleanup failures, the scope/pipeline recovery handle and the primary cause.
+`result` contains only a resolved successful value, never a failed Task.
+
+`Scope#release!` and GeneratorVerifier release retain failed owners for retry and
+remove successful ones. Return true on complete release, false after release.
+Partial release rejects new work/acquisition. Concurrent Scope release raises
+agent.scope_busy; interruption of a releasing call leaves a retryable failed state.
+Materialization receipts are drained to physical completion before release.
+Neither API implicitly cancels work, answers approval, deletes saved data or
+closes the application Store. The application decides how unfinished work becomes
+safe before retrying through the cleanup error's scope/pipeline handle.
+
+## Dependencies and implementation units
+
+- Remove C03 Generation → C17 OutputParser; C03 continues to use public C04 Agent,
+  C02 Workflow and C13 Execution contracts.
+- Add C04 Agent → C17 OutputParser as a default implementation composed at boot.
+  C04 owns the output promise and error; C17 owns syntax/schema interpretation.
+- C09 transports schema/final-response facts and remains independent of C17/C03.
+- No new Storage, Engine or Runtime-private dependency from Generation is added.
+
+The Contract concept/foundation SVGs reflect these two edges. Generation → Agent
+must retain its existing route above OutputParser. Repository source diagrams are
+regenerated by the Architecture tool; conceptual target diagrams remain distinct
+from the complete source graph.

data/docs/architecture/tracing.md

@@ -162,9 +162,9 @@ This guarantee is specific to Framework automatic instrumentation. It does not
 redefine the behavior of Application code that directly calls the public
 `Tracing::Base#trace` template method.
 
-## 10. TokenUsage
+## 10. Observed token counts
 
-`Phronomy::LLMAdapter::TokenUsage` has four fields:
+Tracing receives a plain `Hash[Symbol, Integer?]` in `usage:`. Supported keys are:
 
 ```text
 input
@@ -173,8 +173,26 @@ cached
 cache_creation
 ```
 
-A backend may export the subset its telemetry schema supports. The TokenUsage
-value object and each backend's wire representation are separate contracts.
+A backend may export the subset its telemetry schema supports. Missing/unknown
+counts remain nil and zero remains a measurement. Tracing does not accept or
+interpret a domain-specific usage object. The LLM domain retains ownership of
+its immutable usage value and aggregation rules; its caller projects the value
+with `to_h` before sending it to Tracing. Agent owns that projection for both
+`llm.call` and `agent.execution`. Arbitrary Workflow/Tool results are not inspected
+for a `usage` field by Tracing.
+
+For manual tracing, change `[result, usage]` to `[result, usage&.to_h]` when the
+second value is a domain object. Custom exporters read `usage[:input]` and
+`usage[:output]` instead of calling methods on the domain object. No compatibility
+conversion inside Tracing is retained: it would preserve the dependency being
+removed. The `usage:` keyword, span lifecycle and external telemetry field names
+are unchanged.
+
+The internal automatic task observer accepts an owner-supplied projection. A
+failed projection is diagnostic-only: it records no usage and does not change
+the operation result or prevent the span from finishing. Tracing has no static
+dependency on LLMAdapter. This does not assign LLM retry policy to Tracing or to
+the common LLM contract.
 
 ## 11. Backend notes
 

data/docs/architecture/transport-error-boundaries.md

@@ -0,0 +1,103 @@
+# RubyLLM transport error boundaries
+
+## Purpose and ownership
+
+Applications need to handle a failed provider communication through Phronomy's
+public API without knowing the HTTP client hidden behind the selected backend.
+LLM generation and embedding are separate contracts, so each retains its own
+existing `TransportError`. The concrete RubyLLM backends translate identifiable
+communication failures; Agent, Generation and Execution propagate that result.
+
+This change adds no public class, parameter, failure code, cross-contract edge,
+shared error translator or retry mechanism. Faraday references remain in the two
+concrete backends. The public RBS shape is unchanged.
+
+## Mapping and exclusions
+
+| Failure at the RubyLLM boundary | LLM complete/stream | Embeddings |
+| --- | --- | --- |
+| `Faraday::TimeoutError` | `LLMAdapter::TransportError` | `Embeddings::TransportError` |
+| `Faraday::ConnectionFailed` | `LLMAdapter::TransportError` | `Embeddings::TransportError` |
+| Existing RubyLLM errors | Existing authentication/rate-limit/context/transport classifications | Existing authentication/rate-limit/transport classifications |
+| Application streaming callback, including either Faraday class above | Original exception identity | Not applicable |
+| Cancellation, execution deadline, arbitrary I/O, programming failure or unrecognized Faraday error | Original exception identity | Original exception identity |
+
+The top-level mapped exception preserves the original message and its SDK/HTTP
+exception as `cause`. That exception's network cause is retained, for example:
+`LLMAdapter::TransportError -> Faraday::TimeoutError -> Net::ReadTimeout`.
+No classification is inferred from an exception's message or nested cause.
+The explicitly selected LM Studio backend additionally decodes the HTTP response
+body at the SDK boundary using a narrow provider-response mapping; see
+[LM Studio output failures](lm-studio-output-failures.md). This is not a generic
+exception-message or cause-chain heuristic, and the default RubyLLM mapping below
+is unchanged.
+Generic `Faraday::Error`, `Faraday::SSLError`, raw `IOError` and system errors are
+not added to this mapping. Future additions require evidence and an explicit
+category decision rather than a blanket rescue.
+
+The LLM backend's callback identity check runs before provider classification.
+An application callback throwing `Faraday::TimeoutError` therefore remains the
+same object. A provider timeout after a delivered chunk is a transport failure;
+the already delivered chunk is not withdrawn, replayed or turned into success.
+
+## Application code before and after
+
+Before, handling a provider timeout required knowledge of the backend's client:
+
+```ruby
+begin
+  response = adapter.complete(request)
+rescue Phronomy::LLMAdapter::TransportError,
+       Faraday::TimeoutError, Faraday::ConnectionFailed => error
+  warn "Provider communication failed: #{error.message}"
+end
+```
+
+After, the same communication categories are handled through the public owner:
+
+```ruby
+begin
+  response = adapter.complete(request)
+rescue Phronomy::LLMAdapter::TransportError => error
+  warn "Provider communication failed: #{error.message}"
+end
+```
+
+Embeddings applications use `Phronomy::Embeddings::TransportError` in the same
+way. Applications may inspect `cause` for diagnostics, but ordinary transport
+handling does not need a Faraday dependency. Existing specialized errors remain
+available for applications that distinguish authentication or rate limiting.
+
+## Retry, interruption and lifetime
+
+The accepted [transport-policy ADR](../decisions/011-delegate-transport-policy-to-adapters.md)
+continues to apply. RubyLLM owns its configured HTTP retries. Phronomy translates
+the failure reaching its boundary and does not replay the LLM operation, Agent
+invocation or Tool work. A transport classification does not assert that no
+output or external effect occurred, and does not authorize a retry.
+
+An execution deadline and an HTTP timeout remain different failures. This change
+does not force worker threads to stop, alter cancellation, or make an active
+Agent safe to unload. Once an ordinary provider failure has settled and its
+physical work has finished, the existing lifetime APIs can release its owners.
+
+The old Faraday 2.1.0 / faraday-net_http 2.1.0 streaming path lost HTTP status and
+caused RubyLLM to retry a schema/Tool rejection as a synthetic ServerError.
+The supported floors are now Faraday 2.14.4 / faraday-net_http 3.4.4. Real HTTP
+tests verify the original status and request count with SDK retries enabled.
+The obsolete ServerError-to-schema-rejection fallback is removed: an actual 500
+remains a server failure even when its text resembles a known 400 rejection.
+Configured SDK retries for 429/500 remain intact; no global retry switch or
+SDK monkey patch is introduced.
+
+## Verification
+
+Unit contracts cover both mapped types across complete, stream and embed,
+identity exclusions, same-class callback failures and failure after partial
+output. Loopback HTTP tests exercise the real RubyLLM/Faraday stack for timeout,
+connection loss, partial streaming with SDK retries enabled, callback identity,
+and GeneratorVerifier propagation/release. The minimum HTTP CI job runs these
+contracts too. Test-only shortened timeouts do not change production settings.
+
+These tests do not certify live model answer quality, schema/Tool combination
+support, or the root cause of the earlier unreproduced LM Studio wait.

data/docs/architecture/trust-acceptance-followup.md

@@ -0,0 +1,87 @@
+# Trust pipeline acceptance follow-up
+
+## Purpose and responsibility
+
+Communication integrity, schema validity and business truth are different
+promises. Successful HTTP and valid JSON cannot establish faithful extraction.
+
+| Concern | Owner | Change |
+| --- | --- | --- |
+| HTTP status and configured retries | HTTP stack / concrete RubyLLM backend | Require a verified stack that preserves streaming status |
+| Schema-valid terminal values | Agent, using OutputParser | Existing guarantee retained |
+| Evaluation criteria and result meaning | GeneratorVerifier | Existing protocol retained |
+| Exact invoice extraction | Application / acceptance oracle | Reject incorrect values explicitly |
+| Approval decision and Tool effects | Application decision, Agent execution, Generation routing | Observe notification, decision, effects and release |
+| Unexplained wait | Diagnostic runner plus server logs | Record payload, settings, attempts and periodic thread stacks |
+
+Contract owners, their dependencies, Engine and Execution are unchanged.
+No SDK monkey patch, extra retry loop, output repair or schema downgrade is added.
+
+## HTTP dependency correction
+
+Faraday 2.1.0 with faraday-net_http 2.1.0 did not pass the response environment to
+streaming callbacks. RubyLLM 2.0.0 could interpret a JSON 400 as a synthetic 500.
+401 and 429 could also lose their identity. The ServerError fallback additionally
+misclassified an actual 500 whose text matched the known schema rejection.
+
+Supported floors are now Faraday 2.14.4 and faraday-net_http 3.4.4, the pair
+already verified on the normal path. Both are explicit in the gemspec: raising
+Faraday alone does not exclude older Net::HTTP adapters. CI pins and checks both,
+with the existing minimum RubyLLM, MCP and JSON versions. These are verified
+support floors, not claims about the earliest upstream fix. Custom Faraday
+adapters need their own streaming/status compatibility assessment.
+
+The obsolete ServerError fallback is removed. Only a real BadRequestError with
+the known body becomes StructuredOutputUnsupportedError. Actual 500 responses
+retain the SDK server-error cause. Configured SDK retries for 429/500 remain;
+a 400 rejection is one HTTP attempt even with three retries configured.
+Partial-stream replay and callback identity regressions remain in place.
+
+Before and after, application handling uses the same public API:
+
+```ruby
+rescue Phronomy::LLMAdapter::StructuredOutputUnsupportedError => error
+  warn error.cause.class
+```
+
+Before, the old stack could issue four requests and expose a synthetic ServerError
+for HTTP 400. After, the cause is BadRequestError and that rejection is not
+retried as a transient server failure.
+
+## Content fidelity and acceptance
+
+The invoice demo keeps its general string/number schema and asks the model to
+preserve identifier characters. After Agent release, an independent oracle checks
+the fixed fixture. Incorrect values exit 1; they are never replaced or retried.
+This is fixture acceptance, not a general invoice validator or Agent responsibility.
+
+Before, INV-2026-01 could print and exit successfully for source INV-2026-001.
+After, it is a fidelity failure, while schema validation remains correctly
+successful. One correct response does not establish general model accuracy.
+
+The examples runner checks invoice, accepted, iteration_limit and approval
+yes/no/cancel independently. Approval requires a notification and the expected
+Tool effects. A schema/Tool rejection is blocked, not successful approval.
+Yes checks approval and valid completion; accepted is a separate test because
+Tool approval does not guarantee that evaluation criteria will be satisfied.
+
+## Wait diagnosis and limits
+
+The opt-in runner observes the pinned SDK without replacing the provider or
+changing timeout/retry settings. It records UTC times, request payloads/hashes,
+settings, physical HTTP attempts, results, exception causes, releases and periodic
+Ruby thread stacks. Observer failures invalidate the report and do not replace
+the application exception. Signals wrapped by cleanup errors remain interrupted.
+
+Observation uses diagnostic-only SDK method bindings and must be reviewed when
+the SDK changes. Reports contain prompts/responses. Sampling and file writes add
+overhead; this runner is not a performance benchmark.
+
+Historical LM Studio logs cannot be reconstructed. Match the saved review payload
+and UTC times with server logs; use future wait stacks to identify pending
+HTTP/SDK/framework operations before assigning a cause. A later fast response
+does not resolve the earlier wait.
+
+Controlled HTTP fixtures prove framework and observation behavior, not live
+model accuracy or server support for schema plus Tools. Live acceptance still
+requires a suitable model/server environment and recorded server version.

data/docs/decisions/029-semantic-completion-and-application-effect-boundary.md

@@ -153,7 +153,7 @@ request deduplication or unambiguous correlation. Existing retention applies.
 
 Reuse existing APIs where they meet this contract; map missing capabilities only
 after baseline inspection. Do not invent a framework outbox or request registry.
-See [RC-01](RECOVERY_CONTRACT_CLARIFICATIONS.md#1-rc-01--確定結果の参照と実行の発見).
+See [RC-01](../design/durable-semantic-coordination/RECOVERY_CONTRACT_CLARIFICATIONS.md#1-rc-01-accessing-final-results-and-discovering-executions).
 
 ### 9. Unknown commit outcome and cancellation
 

data/docs/design/durable-semantic-coordination/CHANGELOG_V2_REVISION_2.md

@@ -1,33 +1,33 @@
-# V2 revision 2 — 改訂内容
+# V2 revision 2 - Changes
 
-更新日: 2026-09-06 / 状態: Accepted
+Updated: 2026-09-06 / Status: Accepted
 
-## 合意反映
+## Accepted decisions reflected in this revision
 
-| 項目 | 今回の修正 |
+| Item | Change in this revision |
 |---|---|
-| RC-01 結果参照 | exact実行IDで状態・結果を読み取る契約と、ID受領前の停止に備えたownerからの候補発見を追加 |
-| RC-02 保存成否不明 | 正常な不存在、read障害、CAS競合、commit成否不明を区別。同じ予約済みidentityで照合 |
-| RC-03 wiring互換性 | 定義id/version・slot・graph・Persistence境界の最低照合と、確定済みfactの優先を明記 |
-| RC-04 cancellation | 観測終了/shutdownとsemantic cancelを区別。子の状態別処理、競合、restart後の再発見を明記 |
-| RC-05 保証表現 | 確定outcome再利用・同一identity復旧・外部成否不明は既存Recovery、に統一 |
+| RC-01 Result access | Add contracts for reading status/results by exact execution ID and discovering candidates from the owner if execution is interrupted before the caller receives the ID |
+| RC-02 Unknown persistence outcomes | Distinguish confirmed absence, read failure, CAS conflict, and unknown commit outcome; reconcile using the same reserved identity |
+| RC-03 Wiring compatibility | Specify minimum checks for definition id/version, slot, graph, and Persistence boundary, and give precedence to committed facts |
+| RC-04 Cancellation | Distinguish ending observation/shutdown from semantic cancellation; specify handling by child state, races, and rediscovery after restart |
+| RC-05 Guarantee wording | Use consistent wording: reuse committed outcomes, recover with the same identity, and resolve uncertain external outcomes through existing Recovery |
 
-ADR-029/030/031、実装設計、責務境界レビュー、READMEへ対応する規範的記述を反映した。
-詳細契約と検証条件はRECOVERY_CONTRACT_CLARIFICATIONS.mdにまとめ、資料間で参照する。
-承認前のProposed表記をAcceptedへ更新した。新機能の再承認を要求しない。
+The corresponding normative statements have been incorporated into ADR-029/030/031, the implementation design, the responsibility boundary review, and the README.
+Detailed contracts and validation conditions are collected in RECOVERY_CONTRACT_CLARIFICATIONS.md and referenced across the documents.
+The pre-approval Proposed status has been changed to Accepted. This does not request renewed approval of the new functionality.
 
-## 実装状態の訂正
+## Correction of implementation status
 
-引き継ぎ文書の旧実装件数・静的検証成功は、前セッションの報告として残す。
-この分岐先で実装を再検証した事実にはしない。現在取得できたのは設計資料と引き継ぎ文書であり、
-旧overlay/apply.py/APPLY.sh/VERIFY.shは未取得。再開手順も実ファイルの回収から始める形に更新した。
+Earlier implementation counts and successful static checks in the handoff document remain reports from the previous session.
+They are not evidence that implementation was revalidated in this continuation. Only the design documents and handoff document are currently available;
+the old overlay/apply.py/APPLY.sh/VERIFY.sh have not been recovered. The resumption procedure has also been updated to begin by recovering the actual files.
 
-## 今回実施した確認
+## Checks performed for this revision
 
-- 対象資料の承認状態、baseline、相互参照の整合確認。
-- 旧い「未承認のため実装停止」表現と、外部効果のexactly-onceに読める保証表現の修正。
-- RC-01〜05のADR・実装設計・検証条件への対応確認。
-- ZIP構成、全文書のSHA256SUMS、ZIP/引き継ぎ文書の外部SHA256の検証。
+- Check consistency of approval status, baseline, and cross-references in the affected documents.
+- Correct obsolete statements that implementation was stopped pending approval and guarantee wording that could imply exactly-once external effects.
+- Check the mapping of RC-01 through RC-05 to ADRs, implementation design, and validation conditions.
+- Verify the ZIP layout, SHA256SUMS for all documents, and external SHA256 values for the ZIP and handoff document.
 
-対象repositoryのコード変更・RSpec実行は行っていない。
-API名や例外名は未確認のものを作らず、baselineへの対応付けを実装前の必須作業とした。
+No code changes or RSpec runs were performed in the target repository.
+Unverified API or exception names were not invented; mapping the requirements to the baseline was made mandatory before implementation.