docs(reborn): agent loop skeleton framework spec + 9 workstream briefs

[henrypark133]

Summary

Architecture spec for the Reborn agent-loop framework — a new ironclaw_agent_loop crate that adds a reusable loop body and a strategy-composition planner above the existing TurnCoordinator → TurnRunner → AgentLoopDriver → AgentLoopHost chain.

• Master doc (docs/reborn/agent-loop-skeleton.md): 15 sections covering architecture, four mutability layers, nine strategies, immutable execution state, canonical executor tick, three production-safe escape nets, follow-up workstreams (WS-9..WS-14) for end-to-end wiring.
• Eight implementation briefs under docs/reborn/agent-loop-briefs/: WS-0 state + checkpoints; WS-1/2/3 nine strategy traits split into three groups; WS-4 planner facade; WS-5 nine Default* impls; WS-6 canonical executor; WS-7 PlannedDriver adapter; WS-8 cross-crate integration suite with feature-gated test_support module.
• Zero code in this PR. Trait scaffolding lands in WS-0's PR; per-workstream PRs follow in dependency order.

The default behavior is modeled on pi-mono agent-loop mechanics (single async function, Reply | CapabilityCalls parent protocol, steering/follow-up queues). The framework absorbs pi's hooks into typed host ports and adds production-grade safety nets (no-progress detection via call-signature ring + failure run-length, retry budgets, gate suspension, evidence-validated LoopExit).

Reviews completed

• Codex review (/codex:review) — 5 issues (stop-after-batch, cancellation-as-LoopExit, real retry mechanic, iteration cap off-by-one, repetition iteration semantics). All applied.
• 3 Explore-subagent passes: architecture soundness + missing wiring, complexity decomposition audit, crate boundaries + CLAUDE.md coverage. All P0/P1 feedback applied (see master doc §12 for the resulting follow-up workstreams).

Test plan

This is a docs-only PR. Verification is light:

• grep -nE '/(Users|home)/[a-zA-Z0-9_-]+/|/tmp/' docs/reborn/agent-loop-skeleton.md docs/reborn/agent-loop-briefs/*.md returns no matches (per .claude/rules/doc-hygiene.md)
• git diff origin/reborn-integration --stat -- ':!Cargo.lock' shows only docs/reborn/... paths
• Manual review: every brief references the master doc; cross-workstream type references resolve (TurnSummary, StopOutcome, RecoveryOutcome, CapabilityErrorSummary, ModelErrorSummary all defined in the appropriate brief)
• All section cross-references (§3, §8, etc.) resolve to current section numbering

End-to-end agent-loop execution is verifiable only after WS-0..WS-8 land. Each brief carries its own per-workstream verification section.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces the core framework for the Reborn agent loop, including the AgentLoopExecutor trait, its canonical implementation, the AgentLoopPlanner facade, and the necessary strategy traits and state management structures. The review identified several critical issues in the canonical executor's logic, including flawed batch result summary calculation, incorrect iteration limit check placement, missing per-iteration signature deduplication, and incorrect failure kind tracking during retries. Additionally, there were concerns regarding the use of mutable references in helper functions and the lack of assistant reply content in the turn summary. I have filtered out comments that did not provide actionable feedback or were purely validation-oriented.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a79b48fdc2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[serrrfirat]

Overall I like this design direction. The runner/driver/executor/planner split, host-owned side effects, fail-closed capability posture, and value-immutable loop state all feel like the right shape for Reborn.

Before implementation starts, I think the spec should tighten a few correctness/security seams:

1. Identity trust attenuation — Installed identity content is described as summary-only, but the current shape still forwards a message_ref that could resolve to verbatim content. I’d prefer an enforceable type boundary here, e.g. TrustedRef(...) vs SummaryOnly(...).
2. Identity caching vs prompt mode — caching final Vec<LoopContextMessage> once per run can lock the wrong identity set if PromptMode changes across iterations. Cache raw stable candidates and filter per build, or key by (run_id, prompt_mode).
3. Checkpoint/resume API — the executor pseudocode writes a serialized state payload, but the current host port shape is checkpoint(kind, state_ref). The write-side payload/state-ref flow should be explicit before agents implement from this.
4. Model recovery semantics — the design says RecoveryStrategy handles model errors, but the executor currently maps stream_model failure straight to driver Unavailable. Either route recoverable model errors through RecoveryStrategy or remove that hook from the skeleton.
5. Capability denials — default denial behavior looks inconsistent between abort vs skip-and-continue. Also, profile-surface denials should emit durable redacted telemetry/security evidence even if they don’t become full action-log entries.
6. Cancellation — locked invariant says observe cancellation between every strategy call, but the pseudocode mostly checks at top-of-iteration. Please make the actual awaited boundaries explicit.
7. Parallel batch policy — if default policy can parallelize read-only calls, the visible capability descriptor needs an explicit concurrency hint; otherwise unknown should stay conservative/exclusive.

After those fixes, I’d be comfortable with the overall architecture.

One thing I’d like to open for discussion: simplicity. Nine strategies are very extensible, but also a lot of surface area. Maybe that is right for the framework crate, but we may want stronger presets or grouped policies (PromptPolicy, EffectPolicy, ControlPolicy) so future loop families usually override 1–2 composed objects instead of many small knobs. Curious what others think.

[zmanian]

Review

Read the master doc top-to-bottom. Substantive design with good bones — the strategy/executor/planner split, value-immutable state model, executor-owned checkpoint discipline, and three-layer safety net (iteration cap + retry budget + no-progress detection) are all the right shape. serrrfirat already covered the local correctness items (identity trust attenuation, identity caching key, checkpoint payload flow, model recovery routing, capability denial telemetry, cancellation boundaries, parallel batch policy hints) — won't repeat those.

What I want to add — the structural gaps that aren't yet on the list:

1. Strategy ↔ Hook coordination is unspecified

This is the biggest structural seam. The strategy framework in this PR and the hooks framework in #3524 / the design comment at #3524 (comment) have substantial overlap:

Concern	Strategy in this PR	Hook in #3524
Deny / pause a capability invocation	GateHandlingStrategy returning GateOutcome	before_capability Gate hook returning Deny/PauseApproval
Mutate prompt context	ContextStrategy.plan_context_request (picks mode + inline_messages)	before_prompt / before_context Mutator hook with HookPatch::AddSnippet
Stop the loop	StopConditionStrategy	Observer hooks at after_model see the same signal
Retry/skip on capability error	RecoveryStrategy.on_capability_error	before_capability Gate hook can deny-then-let-recovery-classify

Two parallel decision frameworks with overlapping concerns is exactly the "loop crate as junk drawer" hazard serrrfirat called out. The doc needs to say explicitly where hooks fire relative to strategies — three plausible orderings, only one is right:

• Hook around port (middleware on LoopCapabilityPort): hook fires before strategy sees the outcome. GateHandlingStrategy sees only post-hook outcomes; an Installed hook can override a strategy's intent.
• Hook inside strategy (strategy calls hook dispatcher): strategy stays in control; hook is a delegation point. But every strategy author must remember to call hooks.
• Strategy-as-Builtin-hook (strategies are the Builtin tier of the hook primitive, with Trusted/Installed hooks composed on top): unified mental model; strategies become the highest-trust tier of one machinery.

My take: the third. The strategy machinery and the hooks machinery should be one machinery with trust tiers. Otherwise the spec ships two systems that solve the same problems with different vocabularies, and every future loop family has to learn both. Worth a section in the master doc — or an explicit pointer to #3524 — saying what the relationship is.

2. Trust class for strategies themselves

The doc never says what trust class a strategy belongs to. "Loop families ship as factory functions in ironclaw_agent_loop/src/families/" implies Builtin-only. But the architecture allows arbitrary Arc<dyn ContextStrategy> to be wired into DefaultPlanner — nothing structural prevents a Trusted or Installed extension from shipping its own strategy.

This intersects with the prompt-injection envelope work in #3471 / #3540 directly: a ContextStrategy returning a LoopPromptBundleRequest with inline_messages populated from extension-author code is a clean prompt-injection channel that bypasses the envelope helper. Same hazard as the original #3540 concern but at a different layer.

Either:

• Lock strategies to Builtin trust at the type level (sealed trait, only ironclaw_agent_loop::families::* constructors), or
• Apply the trust-tier taxonomy from the hooks design and define what Trusted/Installed strategies can and cannot do.

The doc doesn't pick. It should.

3. The skeleton ships an identity_messages-empty path

§11 acknowledges WS-15 (identity-file surface) is deferred. That means the skeleton ships with the LoopContextBundle.identity_messages = Vec::new() state — the same dangling-contract concern from PR #3476 and follow-up issue #3547. Skills appear in the prompt before identity until WS-15 lands.

The spec should be explicit that PlannedDriver must not be registered in production-resolvable run profiles until WS-15 ships. Otherwise WS-14 (driver registration) + WS-9 (capability wiring) becomes "production turns running through the new framework with identity inverted to skill" — which is exactly the #3547 hazard.

Suggested edit to §12 minimum-E2E set: WS-9 + WS-13 + WS-14 + WS-15 (not just the first three).

4. Versioning primitive — reuse one shape across the system

The doc has PlannerId newtype in checkpoint payload metadata for replay. The hooks design has (hook_id, hook_version). The skill-snapshot work in #3470 uses SHA-256 length-prefixed snapshot version. The model-route work in #3462 has auth_version. Four places, four conventions.

The Reborn replay story needs one primitive — something like ComponentIdentity { id: Blake3Digest, version: u64 } — with consistent semantics about what "version" means (content-addressed digest vs monotonic counter — pick one). The skeleton spec is the right place to establish this, since the checkpoint payload is the data plane all of them flow through.

5. Cross-cutting baseline alignment (#3492)

The spec implicitly assumes several #3492 baseline patterns but doesn't surface them:

• Sealed state slots. LoopExecutionState fields are shown as pub — readable by strategies, which is fine, but RecoveryStrategyState, ControlStrategyState, etc. need to be constructable only by their owning strategy. Otherwise a misbehaving (or compromised) ContextStrategy can mint a ControlStrategyState claiming a terminate hint was seen and trick StopConditionStrategy into stopping. Same #3460 sealing pattern.
• Error classification on LoopFailureKind. The variants in the spec (IterationLimit, NoProgressDetected, original-class for retry-budget exhaustion) don't carry the Transient/Permanent/Misconfigured/PolicyDenied taxonomy. Should align with the work done in #3454, #3462, #3541. Otherwise the same retry-classification gap surfaces.
• BoundedRing<T, 8> is hardcoded. N=8 is fine for the text-only default, but long-running missions with telemetry/heartbeat capabilities will saturate the ring with noise. Worth surfacing as a config on DefaultStopConditionStrategy so families can tune it.

6. CapabilityCallSignature JSON canonicalization

ArgsHash is over "canonicalized JSON args" but the canonicalization scheme is unspecified. JCS RFC 8785 is the only formal spec and has limited Rust implementation quality. Worth nailing down: which canonicalizer, what about float NaN/Inf, what about map key ordering for non-string keys. Two implementations diverging on canonicalization means the same logical call from two driver versions hash differently and the no-progress detector misfires across upgrades.

---

Verdict

Approve in principle, with one structural ask before WS-0 lands: resolve the strategy ↔ hook relationship explicitly in the master doc. Everything else above can land as iterative refinements during the workstreams. But shipping two overlapping decision frameworks with undefined coordination is the kind of thing that's much cheaper to nail down in the spec than to retrofit across six implementation PRs.

[zmanian]

Follow-up: going deeper after sitting with the spec

The prior review (#3544 (review) — strategy↔hook coordination, trust class, identity messages, versioning primitive, baseline alignment, JSON canonicalization) covered the surface. A few structural things I want to add after more time with the doc.

1. The spec's scope claim may be too broad

The framing positions this as "the framework for all future loop families" — routines, missions, general assistant, coding, planning. Look at those families more carefully:

• Routines are scheduled polls of a fixed capability set; they want repetition (the no-progress detector is the wrong default); they want indefinite runtime, not iteration caps.
• Missions are multi-day plans with first-class checkpoint→approval→resume; that's not a GateHandlingStrategy::Block exit followed by a fresh claim, it's a fundamentally different control flow.
• Coding wants edit-then-test loops with language-specific tools; not a strategy choice.
• Planning wants multi-turn search with backtracking and state revival; not a linear iteration++ model.

The factoring axis the spec picks ("nine swappable strategies, same executor") is right for the text-tool-use family. It's the wrong axis for routines/missions/planning, which need different executors, not different strategy compositions. The spec acknowledges this implicitly ("a family graduates to its own crate only when it pulls heavyweight external deps") but I think the right factoring axis isn't "heavyweight deps" — it's "control flow shape."

Recommendation: narrow the scope claim in §1 to "framework for text-tool-use loop families" and note that routines/missions/planning likely need sibling frameworks (or distinct AgentLoopDriver impls that share helpers but not the executor). Otherwise WS-1–WS-8 produces a generic-looking framework that won't actually generalize, and we end up with three forks.

2. The missing top layer — profile → family → strategy resolution

The four mutability layers in §5 (run context, execution state, run state, durable backends) miss the profile layer above them. ResolvedRunProfile.capability_surface_profile_id is mentioned in §6 but the doc never says how the profile selects a loop family.

This is the layer where trust lives, and pinning it answers the trust-class question I raised in the prior review:

RunProfile  (user-grantable, audited, channel-to-user ratified)
   │
   ▼
LoopFamily  (Builtin, factory function, type-sealed)
   │
   ▼
nine Strategy slots  (implementation detail of the family)

If resolution is forced through this chain, strategies don't need their own trust class because they're never directly user-configurable. Trust is enforced at the profile layer; strategy composition is private to family factories.

Concrete asks:

• LoopFamily becomes an explicit type (pub struct LoopFamily { id: LoopFamilyId, planner: Box<dyn AgentLoopPlanner>, ... }) with pub(crate) constructors.
• Profile selects family by LoopFamilyId; cannot enumerate strategies directly.
• Strategy traits become pub(crate) in ironclaw_agent_loop; only the families module can compose them.

This collapses several open questions: the trust-class problem (prior review §2), the combinatorial-explosion problem (a profile gets a LoopFamily, not 9 independent knobs), and the version-drift problem (LoopFamilyId + content-addressed version pins replayable state).

3. The state model is mid-iteration mutable, with checkpoint implications

The banner property is "value-immutable, rebound per tick." But the retry loop in §8 does in-place mutation:

Retry { recovery, alter }:
  state.recovery_state = recovery;
  honor_alteration(alter)
  retry_outcome = host.invoke_capability(call)

The value-immutable invariant only holds at iteration boundaries, not within a tick. Concrete consequence for checkpoint correctness: the four checkpoint kinds (BeforeModel, BeforeSideEffect, BeforeBlock, Final) are placed at iteration-significant moments, but retry attempts happen between checkpoints. If the process crashes between attempt 1 and attempt 2, the retry counter is lost — on resume, the recovery strategy sees recovery_state.attempts = 0 and the bounded-retry guarantee is silently violated.

Two fixes, spec should pick one explicitly:

• Re-derive on resume from the recent_failure_kinds ring (which is checkpointed). Cheap if the ring carries enough info.
• Checkpoint at every recovery-state transition. Expensive but durable.

Today the spec is silent — which means the framework will work in tests and have subtle retry-budget violations in production.

4. LoopExit should be a witness type at the framework→reborn boundary

PR #3460 sealed LoopExitValidationPolicy so only LoopExitApplier can mint trusted policies. The same pattern should apply to LoopExit itself when it crosses the framework boundary:

ironclaw_agent_loop   →  UnvalidatedLoopExit
ironclaw_reborn       →  LoopExitApplier::validate(UnvalidatedLoopExit) → ValidatedLoopExit
ironclaw_turns        →  TurnRunner accepts only ValidatedLoopExit

Right now the spec relies on convention ("LoopExit from PlannedDriver::run goes through the applier"). A typed boundary makes this unbypassable and compile-time enforceable. Invariants by types, not by convention.

5. Only the iteration cap is structurally unbypassable

§10 names three safety nets but two of them are enforced by strategies (retry budget by RecoveryStrategy, no-progress by StopConditionStrategy). Only the iteration cap is enforced by the executor itself. If strategies are Builtin-only this is fine — they're trusted code. If strategies are ever Trusted/Installed, a malicious one defeats two of the three nets and only iteration cap saves you.

This couples to point 2: if LoopFamily is the type-sealed Builtin-only composition layer, the safety story is fine. If the spec ever wants to allow extension-supplied strategies, the executor itself must enforce no-progress detection independently.

The spec should state this trade-off explicitly. Either "strategies are Builtin-only and that's the trust story" or "extension-supplied strategies need executor-level safety nets" — pick one.

6. Cancellation is cooperative, coupled to trust class

The spec observes cancellation "between every strategy call" — cooperative, not preemptive. A strategy that hangs in an await is uncancelable. Same coupling as point 5: Builtin-only strategies make cooperative fine; Trusted/Installed strategies would require tokio::select! against the cancellation token at every strategy call site.

7. Strategy combinatorial explosion: serrrfirat's grouped-policy hint is right

Nine strategies × ~3 sensible variants = ~20K compositions, most nonsense or unsafe. Concrete coupling examples:

• ContextStrategy::TextOnly + CapabilityStrategy::AllVisible = contradiction.
• BatchPolicyStrategy::Parallel + RecoveryStrategy::SequentialBackoff = contradiction.
• StopConditionStrategy::IgnoreNoProgress + BudgetStrategy::HighIterationCap = infinite-loop attractor.
• GateHandlingStrategy::SkipAndContinue + RecoveryStrategy::Abort = inconsistent recovery model.

Grouped policies (PromptPolicy = Context+Model+Drain, EffectPolicy = Capability+Batch+Recovery+Gate, ControlPolicy = Stop+Budget) capture the coupling and collapse the configuration space to ~27 sensible combinations. Worth doing before WS-1/2/3 ship nine separate traits — retrofitting groups across separately-released trait crates is expensive.

This also resolves part of point 1's scope question: with grouped policies, a "loop family" is three policy choices, and the framework can statically reject nonsense compositions.

8. Three things to borrow from NousResearch's Hermes / Forge

After looking at how the open-source agent line solves analogous problems:

a. The Reply | CapabilityCalls parent protocol is too binary. Hermes' ChatML format, like Claude Sonnet 4.x and GPT-5 in practice, supports interleaved output: text → tool call → text → tool call in a single response. The spec's binary ParentLoopOutput is the right target shape but doesn't match what providers actually emit. The framework needs a normalization step at the model boundary that flattens interleaved responses, with explicit semantics for "text emitted before tool calls" (transcript-only? shown to user? part of the next assistant_refs?). Currently underspecified.

b. Wire-format ownership is implicit and matters most for open-weights providers. Hermes 2 Pro/3 use <tool_call> and <tool_response> ChatML tags — the de facto standard for Llama 3.1+/Qwen/DeepSeek/Mistral tool calling. The spec leaves wire format to LoopModelPort impls per provider. That's fine for Anthropic/OpenAI native tool-calling APIs but produces N divergent shapes for Ollama + open-weights backends (which IronClaw already supports via the LLM backend list). Spec should either pin a canonical WireToolCall and require providers to translate, or be explicit that wire format is per-provider.

c. JSON canonicalization has a free answer. Hermes' published function-call format uses sorted-keys JSON with deterministic number formatting. If CapabilityCallSignature::ArgsHash adopts the same convention, the no-progress detector is cross-model consistent — same tool call from Claude and Hermes 3 hash identically, replay across model swaps works. Pick this from Hermes rather than inventing one.

Beyond these: Hermes/Forge proves you can ship a working tool-using loop with ~3 abstractions and 500 LoC. The framework weight IronClaw is paying (4251 spec lines, 9 strategies, 4 layers, 8 workstreams) is only justified by the trust-model work — multi-tenancy, durable audit, profile-driven family selection, envelope-wrapped untrusted content. The framework weight isn't free; it's earned by trust requirements Hermes/Forge doesn't carry. The spec should say this explicitly in §2 ("why this exists"), because absent the trust framing the nine-strategy abstraction is hard to justify against a Forge-shaped alternative.

The clean separation: borrow Hermes' interface shapes (wire format, interleaved-output handling, JSON canonicalization, possibly self-evaluation framing) but not their trust shapes.

Updated verdict

Still approve in principle. The structural ask before WS-0 lands is sharper now: define LoopFamily as the top-layer abstraction, with profile-driven selection, Builtin-only sealed strategy composition, content-addressed family version baked into the checkpoint payload, and grouped policies (not nine independent traits) as the composition shape.

That single change resolves: the trust-class question, the combinatorial-explosion question, the version-drift question on resume, the safety-net-bypass question, and the cooperative-vs-preemptive cancellation question. All of them collapse into "Builtin family is the only thing that composes strategies; extensions don't enter at this layer."

Everything else above can land as iterative refinements during WS-1–WS-8. The strategy↔hook coordination from the prior review is the only other thing I'd nail down before WS-0; the rest can iterate.

[henrypark133]

LoopFamily-cluster review: applied in 49d1506

Thanks to @serrrfirat and @zmanian for the substantive reviews. The amendments below land docs only before WS-0 seals trait shapes — locking the load-bearing decisions in spec is the cheap window; the same fixes after WS-1/2/3 ship would mean reshaping pub traits across multiple PRs.

This commit addresses one cluster (the LoopFamily / strategy↔hook / trust cluster). Three remaining comment clusters are noted at the bottom and will land as separate amendments.

Four high-level decisions captured

#	Decision	Reviewer points addressed
1	LoopFamily as first-class abstraction. Profiles refer to families by LoopFamilyId; one Guice-style LoopFamilyRegistry is built once at startup by ironclaw_reborn::app_loop_family::build_loop_family_registry() and plumbed as Arc<LoopFamilyRegistry> into TurnRunner. New WS-3.5 brief: loop-family-registry.md. Master doc gains new §4.5.	zmanian #2.2 (missing top layer profile → family → strategy)
2	Strategies sealed Builtin-only. Strategy traits are pub(crate) in ironclaw_agent_loop; AgentLoopPlanner is pub but uses sealed-trait pattern; strategy access lives on pub(crate) AgentLoopPlannerInternal extension trait. Extensions never compose strategies — they plug in via hooks (see #3).	zmanian #1.2 (trust class for strategies), #2.5 (only iteration cap structurally unbypassable), #2.6 (cooperative cancellation); serrrfirat #1 (identity trust attenuation — type-level enforcement direction)
3	Hooks as middleware around host port impls in ironclaw_loop_support, composed outside the executor. Adopt the four-scenario design recorded in #3523 (comment) verbatim. Two concrete follow-ups landed in spec: (a) composition-seam architecture test in WS-9's brief; (b) LoopFailureKind::PolicyDenied variant in WS-0.	zmanian #1.1 (strategy ↔ hook coordination unspecified)
4	Broad scope retained with stress-test discipline. New master doc §12.5 enumerates anticipated families (default + hypothetical routine / mission / coding / planning) and the strategies each would swap, with explicit pointer to where durable family-specific state lives (workspace via HostXxxContextSource, not strategy slots). Result: trait shapes accommodate every row; routine/mission/coding/planning need only strategy variation, not different executors.	zmanian #2.1 (scope too broad), #2.7 (combinatorial explosion); serrrfirat #8 (grouped policies — deferred until 2+ real families exist)

Per-reviewer point-by-point

serrrfirat:

• 1 (identity trust attenuation) — partially addressed via type-level seal (extensions cannot author ContextStrategy impls and therefore cannot author inline_messages). The TrustedRef vs SummaryOnly enforceable distinction remains in scope for the identity / context-shape cluster (deferred — see below).
• 2 (identity caching key vs PromptMode), 3 (checkpoint payload-vs-state-ref API), 4 (model recovery semantics) — deferred to the checkpoint-durability + serrrfirat-7-correctness-seams clusters.
• 5 (capability denials inconsistency + durable redacted telemetry) — partially addressed: CapabilityOutcome::Denied now routes through RecoveryStrategy (with explicit "Retry on Denied → Abort" semantics in WS-6) and accumulates as LoopFailureKind::PolicyDenied so repeated denials trip the no-progress detector cleanly. Durable redacted telemetry pathway remains scoped to the future hooks PR (Reborn: first-class loop hooks roadmap #3524).
• 6 (cancellation boundaries) — addressed: §10 now states that cooperative cancellation between strategy calls is sufficient because strategies are Builtin (sealed). Pseudocode boundaries remain the canonical reference.
• 7 (parallel batch policy concurrency hint) — already addressed in ca648b3 (the summary_of(call, surface) projection consults VisibleCapabilitySurface.descriptor_for(name).concurrency_hint(); unknowns default to Exclusive). Visible in WS-6 §3.3.
• 8 (simplicity / grouped policies) — addressed by §12.5's stress-test outcome: 9-trait surface accommodates anticipated family diversity; grouped policies (PromptPolicy / EffectPolicy / ControlPolicy) deferred until a second real family materializes, per YAGNI.

zmanian first review:

• 1, 2 — addressed (see decisions feat: adding Web UI #2, Onboarding: show Telegram in channel selection and auto-install bundled channel #3 above).
• 3 (skeleton ships identity_messages = Vec::new()) — flagged but not changed: master doc §12's minimum-E2E set discussion stays as-is; the WS-15 ordering question goes into the next cluster (or stands as its own).
• 4 (one versioning primitive) — partially addressed: ComponentIdentity { id, digest: ComponentDigest } defined in WS-3.5 and used for LoopFamily.version + checkpoint payload metadata. Propagation to hooks (Reborn: first-class loop hooks roadmap #3524), skill snapshots (GitHub issue #3432: [Reborn] Add deterministic trust-aware SkillContextService #3470), model routes ([Reborn] Add user-selectable model routes and provider pool #3462) is deferred to the versioning + JSON canonicalization cluster.
• 5 ([Reborn] Establish trust-boundary hardening baseline #3492 baseline) — partially addressed: split ControlStrategyState → StopStrategyState + GateStrategyState (sealed per-strategy state slots); LoopFailureKind::PolicyDenied adds one item toward the taxonomy alignment but the full mapping to Transient/Permanent/Misconfigured/PolicyDenied across Add Reborn loop capability host-runtime adapter slice #3454/[Reborn] Add user-selectable model routes and provider pool #3462/Architectural improvements: preserve typed dispatch failure kinds #3541 stays in the versioning cluster. BoundedRing<T, 8> tunability — not addressed; can land in WS-5 if DefaultStopConditionStrategy exposes it as config.
• 6 (CapabilityCallSignature JSON canonicalization) — deferred to the versioning + JSON canonicalization cluster.

zmanian follow-up:

• 1 (scope claim too broad) — addressed via §12.5 stress-test (broad scope retained, but every claimed family has documented strategy overrides that the trait shapes accommodate).
• 2 (missing top layer) — addressed (decision Move whatsapp channel source to channels-src/ for consistency #1).
• 3 (mid-tick state mutation breaks checkpoint durability for retries) — deferred to the checkpoint-durability + LoopExit witness cluster.
• 4 (typed Unvalidated → Validated LoopExit boundary mirroring feat(reborn): add trusted LoopExitApplier #3460) — deferred to the same cluster.
• 5, 6 (safety-net + cancellation trust coupling) — addressed: §10 now states all three safety nets are Builtin-enforced and cancellation can stay cooperative because strategies are sealed.
• 7 (combinatorial explosion / grouped policies) — addressed by §12.5 (sealed strategies + stress-test); grouped policies deferred until 2+ families.
• 8 (Hermes/Forge interface shapes) — (a) interleaved Reply | CapabilityCalls and (b) canonical WireToolCall are out of scope here (executor- and provider-level concerns); (c) sorted-keys JSON for ArgsHash is part of the versioning cluster.

Deferred clusters (will land as separate amendments)

1. Checkpoint durability + LoopExit witness type — zmanian feat: adding Web UI #2.3 (retry counter lost across mid-tick crash) + feat: adding Web UI #2.4 (typed Unvalidated → Validated LoopExit boundary mirroring feat(reborn): add trusted LoopExitApplier #3460's LoopExitValidationPolicy seal).
2. Versioning + JSON canonicalization — zmanian Move whatsapp channel source to channels-src/ for consistency #1.4 (propagate one ComponentIdentity primitive across hooks/skill snapshots/model routes), Move whatsapp channel source to channels-src/ for consistency #1.6 / feat: adding Web UI #2.8c (pin sorted-keys JSON for ArgsHash, Hermes-compatible).
3. serrrfirat's remaining 7 correctness seams — identity trust attenuation (TrustedRef vs SummaryOnly), identity caching key vs PromptMode, checkpoint API payload-vs-state-ref shape, model recovery routing (does RecoveryStrategy see model errors via on_model_error?), denial telemetry pathway, cancellation boundary precision in pseudocode, parallel-concurrency hint per-capability descriptor.

The LoopFamily cluster was load-bearing — several of the seams above collapse or simplify once the sealed-Builtin shape is in place. The remaining clusters are independent and can iterate.

[henrypark133]

Checkpoint durability + LoopExit witness type: applied in 2b20998

Two short amendments addressing @zmanian's #2.3 and #2.4 from the follow-up review:

#2.3 — retry-budget durability (master doc §10)

The concern was that state.recovery_state.attempts is mutated in place inside execute_capability_batch's retry loop, between checkpoints. A crash mid-retry would resume from BeforeSideEffect with attempts = 0 and silently violate the bounded-retry guarantee.

Three options considered: (A) re-derive from recent_failure_kinds on resume; (B) add an AfterRetryAttempt checkpoint kind; (C) be explicit that the retry budget is bounded within an iteration, not across resumes.

Picked (C). Adding a fifth checkpoint kind would produce checkpoint storms under retry pressure; re-deriving from recent_failure_kinds would require de-bucketing the ring (which today is keyed by LoopFailureKind, not call signature). The honest answer is that retry budgets reset across resumes but the iteration cap (the only structural safety net) still bounds total retries — each resume costs one iteration toward BudgetStrategy::iteration_limit, so a pathological "infinite retries across infinite resumes" loop terminates with LoopExit::Failed { IterationLimit } after iteration_limit iterations regardless.

§10 now carries the explicit note. WS-6's brief gains the matching durability comment next to the retry loop pseudocode so implementers see the rationale at the call site.

#2.4 — LoopExit as witness type (master doc §9)

This one is already structurally enforced — I added a §9 bullet to make it explicit so reviewers don't have to grep code to confirm. The shape:

AgentLoopDriver::run/resume  →  LoopExit                            (raw, in ironclaw_turns)
LoopExitApplier::validate    →  LoopExitValidationDecision          (sealed via
                                                                     LoopExitValidationPolicy
                                                                     seal from PR #3460)
TurnRunTransitionPort::      →  ApplyValidatedLoopExitRequest       (carries LoopExitMapping,
  apply_validated_loop_exit                                          not raw LoopExit)

The runner's transition port at crates/ironclaw_turns/src/runner.rs:149 accepts only ApplyValidatedLoopExitRequest. There is no path for a raw LoopExit to reach TurnRunner without going through LoopExitApplier. The naming differs from "UnvalidatedLoopExit / ValidatedLoopExit" but the type-system enforcement is equivalent and already in production.

§9 now carries the explicit codification of the invariant.

Remaining clusters (still deferred)

1. Versioning + JSON canonicalization — propagate ComponentIdentity across hooks (Reborn: first-class loop hooks roadmap #3524) / skill snapshots (GitHub issue #3432: [Reborn] Add deterministic trust-aware SkillContextService #3470) / model routes ([Reborn] Add user-selectable model routes and provider pool #3462); pin sorted-keys JSON for ArgsHash.
2. serrrfirat's 7 correctness seams — identity trust attenuation, identity caching key vs PromptMode, checkpoint API payload-vs-state-ref shape, model recovery routing, denial telemetry pathway, cancellation boundary precision, parallel-concurrency hint.

Will land as separate amendments.

[henrypark133]

Versioning + JSON canonicalization: applied in 4c12192

Two short amendments addressing @zmanian's #1.4 (one identity primitive) and #1.6 / #2.8c (JCS canonicalization).

#1.4 — one ComponentIdentity shape system-wide

Four components today carry their own version-identity shape: loop families (ComponentIdentity just landed in WS-3.5), hooks (proposed (HookId, u32) tuple per #3523), skill snapshots (SHA-256 of length-prefixed bytes per #3470), and model routes (auth_version: String + config_version: String on LoopModelRouteSnapshot at crates/ironclaw_turns/src/run_profile/host.rs:362). Master doc §9 now commits the system to a single primitive — ComponentIdentity { id: &'static str, digest: ComponentDigest } — across all four. Content-addressed only. Monotonic counters false-drift (bumped without changes) and false-agree (changes without bump), both silent replay-correctness bugs.

This PR does not migrate the existing fields. WS-3.5's brief gains a Migration / propagation table enumerating the four components and per-component cost; the actual migrations land in #3470 (re-wrap existing SHA-256 in the canonical struct, no recomputation), #3524 (content-hash the hook impl at registration), and #3462 (compute digests at version-mint time, emit alongside the strings for one release before dropping the strings — the most involved migration, since auth_version / config_version are String identities today, not content hashes).

#1.6, #2.8c — JCS RFC 8785 for ArgsHash

Master doc §9 + WS-0's new §3.4a pin JCS RFC 8785 as the canonicalization scheme for CapabilityCallSignature::ArgsHash. Implementation reference: the jcs crate. Rules spelled out explicitly so implementers don't have to read the RFC:

• Object keys sorted by UTF-16 code-unit order (not byte order, not ASCII)
• NaN / ±Infinity rejected (not valid JSON; from_call returns an error rather than fabricating a hash that no other impl could reproduce)
• Number representation preserved (no 1.0 → 1 normalization)
• Minimal whitespace

Cross-model compatibility note: for typical tool-call args (strings, integers, nested objects without floats), JCS output is byte-identical to the Hermes / Forge sorted-keys-minimal-whitespace convention used in the open-weights tool-calling ecosystem (Llama 3.1+, Qwen, DeepSeek, Mistral via <tool_call> ChatML). Replay across model swaps (Claude ↔ Hermes 3 ↔ Llama-tool-call format) hashes identically for typical args. The only divergence is float-representation (rule 3), which production tool args essentially never hit. We get the formal IETF spec correctness and practical de-facto compatibility from the same choice.

WS-0's acceptance criteria gain explicit JCS-stability tests (multi-depth key reordering, pretty-printed vs minified, NaN-input returns Err); WS-8's integration suite gains a matching args_hash_jcs_stable test locking the contract.

Remaining cluster (will land as one more amendment)

serrrfirat's 7 correctness seams — identity trust attenuation (TrustedRef vs SummaryOnly enforceable type boundary), identity caching key vs PromptMode, checkpoint API payload-vs-state-ref shape, model recovery routing (does RecoveryStrategy::on_model_error see model errors before they map to Unavailable?), denial telemetry pathway, cancellation boundary precision in pseudocode, parallel-concurrency hint per-capability descriptor.

This is the final cluster. Once it lands the PR is ready for re-review.

[henrypark133]

serrrfirat's 7 correctness seams: applied in 1f808fa

Final cluster. All seven seams from @serrrfirat's review now have spec coverage. Three subagent investigations (read-only) on Sonnet confirmed each was a real gap (not hypothetical), grounded the fixes in actual code locations, and surfaced one cross-seam contradiction worth flagging.

1. Identity trust attenuation as enforceable types

The skill subsystem already enforces trust attenuation by structural absence — SkillTrustLevel::Installed carries prompt_content: None, not just a label. Identity didn't. Fixed by mirroring the skill pattern:

• HostIdentityContextCandidate.message_ref becomes Option<LoopMessageRef>
• new_trusted(...) and new_installed_summary_only(...) constructors couple trust level to ref presence
• LoopContextMessage.message_ref becomes Option<LoopMessageRef> (additive contract change in ironclaw_turns)
• Downstream bugs in build_identity_messages cannot leak content for Installed entries — the ref doesn't exist

2. Identity cache key vs PromptMode

WS-15's caching design was keyed on run_id alone. A PlannedDriver that switches PromptMode mid-run would lock in the first iteration's filter result. Fixed: cache the raw Vec<HostIdentityContextCandidate> (mode-independent) and re-apply applies_when filtering per call. No cache-key change needed; the cache stores upstream of filtering.

3. Checkpoint payload-vs-state-ref

WS-6 pseudocode said save_checkpoint(payload) but the real port takes state_ref (validated token). Fixed: pseudocode now shows the explicit two-step:

1. Executor serializes state → bytes (JCS-canonicalized per §9)
2. host.stage_checkpoint_payload(...) → LoopCheckpointStateRef
3. LoopCheckpointPort::checkpoint(LoopCheckpointRequest { kind, state_ref }) writes metadata only

stage_checkpoint_payload is a new additive method on AgentLoopDriverHost (separate from LoopCheckpointPort to keep byte-storage and metadata responsibilities cleanly split). WS-10's load_checkpoint_payload is its read-side dual.

4. Model recovery routing

RecoveryStrategy::on_model_error was dead code — declared on the trait, never called from WS-6's executor. Fixed: WS-6 wraps stream_model in a recovery loop that consults on_model_error on host failure. Retry { Backoff } works today; AdvanceFallback is rejected as PlannerContract until ModelRouteChain lands (master doc §9); SkipResult is rejected (nothing to skip on a model call). Master doc §8 pseudocode mirrors WS-6.

5a. Denied-tool default: Abort → SkipResult

DefaultRecoveryStrategy on PolicyDenied was Abort; the WS-9 integration test name (*_denied_then_recover) implied skip. The test was right. Changed default to SkipResult — the model gets back "tool unavailable" and can try something else. The no-progress safety net (master doc §10) still catches a model stuck repeatedly issuing denied calls. Families wanting strict abort-on-first-denial override the default.

5b. Denial telemetry pathway

Master doc §9 now explicitly cross-references WS-12's CapabilityBatchCompleted { denied_count: u32 } field as the durable redacted telemetry path. Until WS-12 lands, denials accumulate only in state.recent_failure_kinds as LoopFailureKind::PolicyDenied. Per-call denial evidence (beyond counts) is out of skeleton scope; a ProfileDenialObserved variant lands in a follow-up only when a real consumer demands it.

6. Cancellation boundary precision

WS-6 §3.5 now lists eight explicit awaited boundaries where cancellation is observed:

#	Site
1	Top of iteration
2	Pre-drain().drain_steering
3	Pre-context().plan_context_request
4	Pre-capability().filter
5	Pre-model().preference
6	Pre-stop().should_stop_after_turn (Reply path)
7	Pre-stop().should_stop_after_turn (CapabilityCalls path)
8	Inside capability-batch loop before each gate().handle / recovery().on_capability_error

Pseudocode in WS-6 §3.2 and master doc §8 carries // CANCEL_BOUNDARY markers at each site. Adding a new strategy call to the executor MUST add a matching boundary check. WS-8's integration suite gets a cancellation-fires-at-each-boundary test covering all eight sites.

7. Concurrency hint on CapabilityDescriptorView

The WS-6 spec called descriptor.concurrency_hint() — but the field didn't exist on the type. Fixed: WS-0 adds concurrency_hint: ConcurrencyHint to CapabilityDescriptorView (additive contract change in ironclaw_turns). The hint is derived at the adapter boundary in WS-9: HostRuntimeLoopCapabilityPort::visible_capabilities maps CapabilityDescriptor.effects → hint (write/spawn/exclusive → Exclusive; otherwise → SafeForParallel). Lower-layer CapabilityDescriptor unchanged. Tool authors keep declaring effects (which they already do); the system infers conservatively.

---

PR #3544 is ready for re-review. Four amendment commits on top of the original spec:

• 49d150691 — LoopFamily cluster
• 2b20998ae — checkpoint durability + LoopExit witness
• 4c1219255 — versioning + JCS canonicalization
• 1f808fae6 — this commit (serrrfirat's 7 seams)

All review threads have been responded to. Happy to iterate further if any of these need different shapes.

[henrypark133]

Opus final-review pass: fixes applied in e48a584

Three Opus subagents did a final-pass review of the four amendment commits — cross-doc consistency, implementation feasibility, and architectural coherence. They surfaced 5 critical blockers, 5 consistency drifts, and 5 architectural gaps. This commit closes the blockers, the drifts, and three of the quick architectural wins. Two strategic items are deferred for follow-up.

Critical blockers (B1-B5) — all fixed

#	Issue	Fix
B1	ConcurrencyHint had circular crate dep (defined in ironclaw_agent_loop, used as a field in ironclaw_turns)	Moved the type to ironclaw_turns; WS-2 imports it
B2	stage_checkpoint_payload was specified on AgentLoopDriverHost (a method-less marker trait — impossible)	Moved to LoopCheckpointPort alongside load_checkpoint_payload; callers still use host.stage_checkpoint_payload(...) via deref-through-supertrait
B3	WS-7 family.id().to_string().as_str() snippet was E0716 + gratuitous	Fixed to family.id().0 (LoopFamilyId is already &'static str)
B4	CapabilityDescriptorView field-add framed as "additive" — actually breaking (public struct, struct-literal constructors)	WS-0 brief now lists the consumers that need updating in the same PR
B5	WS-5 acceptance criterion still said "aborts on PolicyDenied" — straggler from seam-5a SkipResult amendment	Fixed criterion text

Consistency drifts (D1-D5) — all fixed

#	Issue	Fix
D1	load_checkpoint_payload signature drift across WS-0, WS-7, WS-10 (three different shapes)	WS-10 is source of truth; WS-0 drops the inline stub, WS-7 uses WS-10's request/response shape
D2	from_checkpoint_payload signature drift (Value vs bytes)	Bytes-based two-arg shape canonicalized in WS-0; matches reality (checkpoint storage stores bytes)
D3	Cancellation boundary count: prose said "Eight," table had 9 rows	Combined rows #6/#7 (Reply path + CapabilityCalls path are mutually exclusive at the same model-response match) → 8 rows everywhere
D4	Cancellation helper name mismatch (observe_cancellation_then_checkpoint_and_exit_if_set vs checkpoint_and_exit_if_cancelled)	Standardized on checkpoint_and_exit_if_cancelled across master doc, WS-6, WS-13
D5	WS-8 had no test for the new Denied → SkipResult default	Added two rows to strategy_interactions.rs: denied_call_skips_and_continues and repeated_denied_calls_trip_no_progress (the safety-net rationale for choosing skip over abort)

Quick architectural wins (G1, G3, G4) — fixed

• G1. WS-9 §3.2a enumerates EffectKind → ConcurrencyHint per variant. Conservative defaults: Network → Exclusive (POSTs are causal); UseSecret → SafeForParallel (read-only); DispatchCapability → Exclusive (recursive depth unsafe); empty effects → SafeForParallel (pure function); all write/spawn/modify variants → Exclusive.
• G3. WS-6 §3.5a documents skeleton-stage strategy-decision observability via tracing::debug! at every strategy call site. Durable typed StrategyDecisionEvent telemetry deferred to a future workstream pending real production debugging need.
• G4. Master doc §10 documents in-flight Blocked run behavior when ComponentIdentity.digest changes: LoopExit::Failed { CheckpointUnavailable }. Framework never silently resumes against a changed digest; operators expected to plan deploys accordingly.

Deferred for separate discussion (G2, G5)

• G2 — future-fork story. §4 says families "graduate to their own crate when they pull heavyweight deps," but strategy traits are pub(crate) in ironclaw_agent_loop — an external family crate can't see them. The spec needs to either acknowledge that families effectively never graduate (they grow inside ironclaw_agent_loop), or introduce a pub(in family-factory) escape hatch. Strategic decision worth a separate thread.
• G5 — §9 editorial cleanup. §9 has 17 bullets with cross-references to "PR Reborn: add first-class loop hook framework #3523-comment-X" and "PR docs(reborn): agent loop skeleton framework spec + 9 workstream briefs #3544 serrrfirat #Y." Those are institutional memory, not documentation — a new engineer 6 months from now can't navigate them. Worked decisions need to be inline rather than pointing at PR comments.

Final state

PR #3544 now carries five amendment commits on top of the original spec:

• 49d150691 — LoopFamily / strategy↔hook / trust cluster
• 2b20998ae — checkpoint durability + LoopExit witness type
• 4c1219255 — versioning + JCS canonicalization
• 1f808fae6 — serrrfirat's 7 correctness seams
• e48a584b1 — this commit (Opus review fixes)

The spec is ready for re-review. Happy to discuss G2 and G5 separately when you're ready.

[henrypark133]

Final editorial pass: G2 + G5 in 93f0865

The last two open items from the Opus architectural-coherence review are now closed.

G2 — families live in ironclaw_agent_loop permanently

§4 now states explicitly: the strategy-composition seal has no escape hatch. No pub(in family-factory) visibility, no feature-gated re-exports, no plugin loaders. If a family needs heavyweight external deps (tree-sitter, ripgrep, ML bindings), they land as feature-gated optional deps inside ironclaw_agent_loop itself — not in a sibling crate. The cost (one crate accumulates external deps) is borne so the sealed-strategy invariant remains structurally unbreakable. Extensions plug into the loop via hooks (§9.1), never via families.

This was the last unresolved structural question. It locks the "strategies are Builtin-only" claim at the build-system level: even with a pub(in family-factory) visibility hack, the seal would be guarded by review discipline; with no escape hatch at all, it's guarded by the compiler.

G5 — §9 editorial cleanup

The §9 was a 17-bullet list with several pointers to PR comments ("PR #3523-comment-4435808547", "PR #3544 serrrfirat #N", etc.). A new engineer reading the spec in six months can't navigate those — they're institutional memory, not documentation.

Two changes:

(a) New §9.1 "Strategies vs hooks: the extension contract." The full hooks-as-middleware design previously linked only by URL is now inline. Includes: responsibility table (where strategies live vs where hooks live), layer-cake diagram, two-boundary invariants, and four worked scenarios (hook deny / hook mutate / hook pause / event-triggered hook). This section is the standalone reference for the strategy-hook split — the future ironclaw_hooks PR (#3524) implements against this contract.

(b) Stripped PR-comment URL attributions. 14 "PR #3544 serrrfirat #N" trailing attributions removed; two "Addresses PR #3544 Opus review §c gap" footers removed; six "PR #3523-comment-4435808547" references replaced with §9.1 cross-references. The content they pointed at is already inline. A single consolidated "Review history" note in §15 Credits preserves the attribution: "[…] this spec is meant to be read standalone without consulting PR threads."

Legitimate PR references that remain (not institutional memory):

• PR #3460 in the LoopExit witness-type bullet — the sealed LoopExitValidationPolicy lives in that PR
• PR #3523 / PR #3524 in WS-9 migration context — the future hooks PRs

Final state

PR #3544 carries six amendment commits on top of the original spec:

Commit	Cluster
49d150691	LoopFamily / strategy↔hook / trust
2b20998ae	checkpoint durability + LoopExit witness
4c1219255	versioning + JCS canonicalization
1f808fae6	serrrfirat's 7 correctness seams
e48a584b1	Opus-review fixes (blockers + drifts + G1/G3/G4)
93f08654d	this commit (G2 + G5 editorial cleanup)

All review threads have been responded to; no open items remain. The spec reads standalone — a new engineer can follow it without consulting PR threads. Ready for re-review or merge.

[serrrfirat]

Reviewed current head 5289cf68494b49291ffe459c91b07cda7cc35cb4 with maximum skepticism. I am not 100% factually confident in this strategy yet. Several contract/implementation gaps remain before this is safe to hand to implementers.

Severity	Finding	Evidence	Concrete failure	Suggested fix
High	Input consumption contract still cannot safely support “filter control inputs, ack only consumed user-facing messages.”	docs/reborn/agent-loop-briefs/canonical-executor.md:543-570, docs/reborn/agent-loop-briefs/loop-input-port.md:96-130, docs/reborn/agent-loop-briefs/loop-input-port.md:239-255	Queue returns [Cancel, UserMessage] or [CapabilitySurfaceChanged, UserMessage]. With one batch cursor / ack_through(cursor), advancing past the user message also consumes the control event; not acking redelivers the user message forever.	Add per-input cursors/ack tokens, split control/user streams, or define a transactional consume API that can advance independent cursors safely.
High	Steering/followup inputs are acked before durable checkpoint captures state.input_cursor.	docs/reborn/agent-loop-briefs/canonical-executor.md:560-570, docs/reborn/agent-loop-briefs/canonical-executor.md:590-600	Worker polls and acks a steering/followup message, then crashes before the next checkpoint. Resume loads old cursor, but queue may have evicted the input, so the message is lost.	Make cursor advancement durable before ack, or atomically commit checkpoint + input cursor + ack in one host transaction. Add crash-between-ack-and-checkpoint regression.
High	Capability wiring still invokes CapabilityDispatcher directly instead of the contract-level CapabilityHost boundary.	docs/reborn/agent-loop-briefs/capability-host-wiring.md:158-200; contract says loop effects route through CapabilityHost in docs/reborn/contracts/turns-agent-loop.md:22-29	Implemented literally, model-triggered tool calls can bypass grant/approval/lease/audit/obligation enforcement that belongs above dispatcher.	Re-spec HostRuntimeLoopCapabilityPort around CapabilityHost or a trusted host-owned facade above dispatcher. Add caller-level tests proving denied/unapproved calls never reach dispatcher while denial/approval telemetry still records.
High	Stable identity-file cache is per-process only, so resume/restart can drift prompt identity.	docs/reborn/agent-loop-briefs/prompt-context-assembly.md:421-442	Run blocks on approval, operator edits AGENTS.md / TOOLS.md, process restarts, resume rebuilds host and uses different identity prefix than pre-block attempt.	Persist stable identity snapshot/digest in checkpoint/run metadata and reject or migrate resume on drift. If not in scope, narrow claim to “stable only within one execution attempt.”
Medium	ComponentDigest([0; 32]) placeholder contradicts content-addressed replay/resume safety.	docs/reborn/agent-loop-briefs/loop-family-registry.md:223-231	Strategy composition changes but digest stays zero / maintainer forgets bump. Old checkpoint resumes under new planner semantics with no mismatch.	Make deterministic content digest mandatory before resume compatibility claims. Define canonical bytes + versioned hash algorithm.
Medium	SpawnedProcess path still invents protocol not present in current contracts.	docs/reborn/agent-loop-briefs/canonical-executor.md:442-451; current LoopBlockedKind only has approval/auth/resource; ProcessHandleSummary has no gate_ref; LoopInput has no process-completed variant.	First spawned-process outcome cannot produce a valid LoopExit::Blocked or a real resume trigger.	Remove SpawnedProcess handling from skeleton until a process-wait contract exists, or land explicit ProcessWaiting evidence/input protocol first.
Medium	Driver identity still drifts across briefs/tests.	docs/reborn/agent-loop-briefs/planned-driver-adapter.md:78-97, docs/reborn/agent-loop-briefs/planned-driver-registration.md:129-145, docs/reborn/agent-loop-briefs/e2e-integration-tests.md:239	WS-7 derives descriptor from family id, WS-14 defines reborn:planned-default, WS-8 expects reborn:default-loop; profile/registry/test cannot all resolve same driver.	Pick one LoopDriverId and assert registry descriptor == profile driver == e2e expected id.
Medium	CapabilityStrategy::filter still lacks a wire path to the host surface request.	docs/reborn/agent-loop-briefs/strategy-traits-alpha.md:77-101; current VisibleCapabilityRequest is empty.	Future family thinks it narrowed visible tools, but executor cannot send the filter to host; model can still see full profile surface.	Extend VisibleCapabilityRequest with the filter, or move all family-specific filtering into a host decorator keyed by family/profile. Add non-default filter integration test.
Medium	Cancellation handle creation does not require seeding/rechecking already-durable cancel state.	docs/reborn/agent-loop-briefs/host-cancellation-accessor.md:386-409	Resume starts after run already entered CancelRequested; fresh handle is clear and executor may continue side effects despite durable cancellation.	handle_for_run must initialize from durable state, subscribe/register handle, then recheck durable state to close race. Add pre-fired/late-subscriber test.
Medium	Fresh state constructor shape is still inconsistent with state contents.	docs/reborn/agent-loop-briefs/state-and-checkpoints.md:102-104	LoopExecutionState contains run-scoped LoopInputCursor, but initial() has no LoopRunContext, so it cannot mint the origin cursor correctly.	Standardize on LoopExecutionState::initial(&LoopRunContext) across WS-0/WS-7/tests/master doc.
Medium	Followup drain uses steering partition helper.	docs/reborn/agent-loop-briefs/canonical-executor.md:590-595	Followup queue path may filter the wrong variants; FollowUp can be ignored or Steering consumed as followup depending helper semantics.	Define separate partition_followup_kinds and tests with mixed FollowUp + Steering + control inputs.

Remaining uncertainty: after the above changes, factual confidence still depends on code-level verification, especially atomic input/checkpoint semantics and capability-host denial/approval paths.

Minimum verification I would want before implementation confidence:

• crash-between-poll/ack/checkpoint regression
• control event before user/followup regression
• denied/unapproved capability never reaches dispatcher
• identity snapshot/digest drift blocks or migrates resume
• cancellation handle pre-fired + race test
• descriptor/profile/registry driver-id equality test
• non-default capability filter narrows visible surface

[henrypark133]

Addressed the review in 56d67ad.

Summary of changes:

• Reworked WS-11 input consumption around exact per-input ack tokens, control-first partitioning, and durable cursor-before-ack semantics, with crash/control regression tests called out.
• Re-specified WS-9 around the contract-level CapabilityHost boundary instead of direct dispatcher invocation, added the strategy filter wire path on VisibleCapabilityRequest, and required denial/approval telemetry tests.
• Pinned stable identity context to durable snapshot/digest metadata for resume, made family digests deterministic/non-placeholder, and closed the cancellation late-subscriber race.
• Removed invented spawned-process blocking semantics, aligned the planned driver id on reborn:planned-default, standardized LoopExecutionState::initial(&LoopRunContext), and fixed the followup partition helper drift.

Validation run locally in the isolated worktree:

• git diff --check
• cargo fmt --check

[serrrfirat]

LGTM lets ship