[AI-1391] Daemon sequenced-command settlement (B2-b, daemon half)

[realtonyyoung]

What & why

Part of AI-1391 B2-b — the bilateral sequenced daemon-command settlement protocol (parent AI-1313 §5.5/§6/§7/§8). This is the daemon (producer) half; the paired kcap-server PR consumes the wire. Rollout is daemon-first: everything here is advertised-but-inert — the SupportsSequencedCommands capability is true on DaemonConnect, but no behaviour changes until the server PR lands and starts sending sequenced commands. All wire changes are additive (an old server ignores unknown fields/methods), so either merge order is safe.

Spec: docs/superpowers/specs/2026-07-17-ai1391-sequenced-settlement-design.md. Plan (in this PR): docs/superpowers/plans/2026-07-22-ai1391-b2b-daemon-sequenced-settlement.md.

Scope (daemon producer side)

• Additive wire DTOs (Cli.Core/Models.cs) — StopAgentV2 / CommandAck / CommandRejected / AckProcessedPrefix / AckResolvedCandidates / RequestStatusReport; ResolvedStartupCandidate / UnresolvedStartupCandidate / StartupDiscovery; and additive fields on LaunchAgentCommand (Epoch/Seq/CommandId) + DaemonConnect/DaemonStatusReport (watermark + startup-completeness + SupportsSequencedCommands). Enums pinned with [JsonStringEnumMemberName] and zero = safe default.
• SequencedCommandProcessor — two sequenced lanes (Seq'd LaunchAgentCommand + StopAgentV2) executed strictly serially per epoch; exact-next acceptance is one atomic op under lock; LastProcessedSeq is the contiguous terminal-processed prefix; duplicates answered with CommandAck (never re-executed); wrong_next / duplicate_collision / backpressure / stale_epoch / internal_error rejections; AckProcessedPrefix retires identity-cache entries (never evicts an unacked entry). Un-Seq'd commands stay on the legacy unsequenced lane (old-server compat) and never advance the watermark.
• ResolvedCandidatesLedger — durable positive-death-evidence outbox in the daemon state dir (atomic temp+rename, monotonic Generation, append-before-source-delete, (AgentId, OldEpoch) reconcile key). Four hooks feed it: OrphanReaper record-pass, quarantine drain, StopAgent PID-record fallback, and the env-marker recordless resolution matrix. Pruned by a validated AckResolvedCandidates.
• Coverage boot-chain attestation — CoverageJournal (single-atomic-write genesis, cumulative_covered fold) + DaemonLock.PriorInstanceId chain-check → the fail-closed, sticky-false RecordlessSurvivorsImpossible flag advertised on connect.
• Per-platform startup discovery — StartupReapComplete + StartupDiscovery (marker-scan state) + UnresolvedStartupCandidates; the daemon heal-barrier serves RequestStatusReport and emits CommandRejected per reason.

Deferred (noted seams, not in this PR)

• Wait-at-capacity DaemonLaunchQueue (FIFO ticket state machine) — the spec frames it as a separate layer; an OnLaunchRequeue seam is provided.

Marker-path safety (review follow-up)

OrphanReaper.EmitAndClear now corroborates the reaped pid AND prior epoch (r.Pid == c.Pid && r.DaemonEpoch == c.OldEpoch) before trusting/deleting a durable record on the marker path — the env agentId is untrusted for role authority, so a prior-epoch descendant that inherited a still-live leader's env can no longer emit a false trusted-flow death proof for (or delete the record of) the live leader. Non-corroborating matches fall back to the recordless null-flow path with no record delete.

Testing

Capacitor.Cli.Tests.Unit full suite green — total 3663, failed 0, 2 skipped (a gated live-ACP E2E). New coverage across the processor, ledger + 4 hooks, coverage journal, DaemonLock prior-instance chain, heal-barrier report, marker-candidate resolution matrix, startup completeness, and the wire DTOs. Tests use isolated dummy processes only — no real daemon, no live flows. The Linux-only marker-scan matrix is exercised under Linux CI.

Compatibility

Fully additive; SupportsSequencedCommands is the single gate. An old server ignores the new fields/methods and the daemon behaves exactly as before. No projection or read-model changes.

🤖 Generated with Claude Code

[linear-code]

AI-1391

[qodo-code-review]

PR Summary by Qodo

AI-1391 B2-b: daemon-side sequenced-command settlement (producer half)

✨ Enhancement 🧪 Tests 🕐 40+ Minutes

AI Description

• Adds the daemon (producer) half of sequenced-command settlement, gated by
 SupportsSequencedCommands.
• Introduces additive wire DTOs and report/connect fields; old servers safely ignore them.
• Implements serial per-epoch sequenced processing and durable death-evidence reporting with crash
 safety.

Diagram

graph TD
  Server["kcap-server (peer)"] -->|"StopAgentV2 / AckProcessedPrefix"| Conn["ServerConnection"] --> Orch["AgentOrchestrator"]
  Orch --> Proc["SequencedCommandProcessor"] --> Conn
  Orch --> Reaper["OrphanReaper"] --> Ledger[("ResolvedCandidatesLedger")]
  Orch --> Quarantine["AgentKillQuarantine"] --> Ledger
  Orch --> Journal[("CoverageJournal")]
  Ledger --> Conn -->|"DaemonConnect / StatusReport"| Server

  subgraph Legend
    direction LR
    _svc(["Service"]) ~~~ _db[("Durable store")] ~~~ _ext["External peer"]
  end

Loading

High-Level Assessment

The additive, capability-gated rollout (SupportsSequencedCommands advertised but behavior inert) is the safest approach for a bilateral protocol change and avoids lockstep deployment. The implementation reuses proven patterns in this repo (atomic temp+rename durable stores; delegate-injected, unit-testable services) and matches the spec’s constraints (exact-next acceptance, deduped replays, contiguous watermark, append-before-delete crash consistency).

Files changed (23) +5000 / -50

Enhancement (11) +1210 / -44

Models.csAdd additive sequenced-settlement wire DTOs and fields +205/-3

Add additive sequenced-settlement wire DTOs and fields

• Adds new additive DTOs/enums for sequenced settlement (StopAgentV2, CommandAck/Rejected, AckProcessedPrefix, AckResolvedCandidates, startup discovery/candidates, RequestStatusReport) and appends optional sequencing/heal-barrier fields to LaunchAgentCommand, DaemonConnect, and DaemonStatusReport. Enums pin wire tokens with safe zero defaults.

src/Capacitor.Cli.Core/Models.cs

DaemonConfig.csAdd RecordlessSurvivorsImpossible config flag +13/-1

Add RecordlessSurvivorsImpossible config flag

• Adds a config flag carrying the durable coverage boot-chain verdict so it can be advertised on DaemonConnect and used in startup completeness decisions.

src/Capacitor.Cli.Daemon/DaemonConfig.cs

DaemonLock.csExpose PriorInstanceId from lockfile content +33/-5

Expose PriorInstanceId from lockfile content

• Changes lock acquisition to read the previous holder’s InstanceId from the lock file before overwriting it, exposing PriorInstanceId for boot-chain attestation.

src/Capacitor.Cli.Daemon/DaemonLock.cs

DaemonRunner.csPin daemon epoch and record coverage journal before services +15/-0

Pin daemon epoch and record coverage journal before services

• Pins DaemonEpoch before building services and records the CoverageJournal fold (using InstanceId + PriorInstanceId) before any Connect/spawn, fail-closed to false.

src/Capacitor.Cli.Daemon/DaemonRunner.cs

AgentOrchestrator.csIntegrate sequenced processor, ledger hooks, and completeness reporting +272/-16

Integrate sequenced processor, ledger hooks, and completeness reporting

• Instantiates SequencedCommandProcessor, ResolvedCandidatesLedger, and MarkerCandidateStore; wires new server events; routes fully-sequenced LaunchAgentCommand and StopAgentV2 through the serial lane while keeping legacy commands unsequenced. Adds startup completeness rollup, discovery reporting, liveness read for duplicate acks, ledger hook emission (append-before-delete), and multiple test seams.

src/Capacitor.Cli.Daemon/Services/AgentOrchestrator.cs

CoverageJournal.csAdd durable boot-chain attestation journal +82/-0

Add durable boot-chain attestation journal

• Introduces CoverageJournal with a single atomic JSON write that folds 'cumulative_covered' via chain-checking lock InstanceIds. Implements fail-closed and sticky-false semantics to prevent laundering through unaware boots.

src/Capacitor.Cli.Daemon/Services/CoverageJournal.cs

MarkerCandidateStore.csAdd durable marker-candidate source persistence +53/-0

Add durable marker-candidate source persistence

• Adds MarkerCandidateStore for recordless survivor candidates with hashed filenames and atomic temp+rename writes, supporting crash-consistent marker-based resolution.

src/Capacitor.Cli.Daemon/Services/MarkerCandidateStore.cs

OrphanReaper.csAdd marker-candidate reconciliation + startup discovery surfaces +169/-18

Add marker-candidate reconciliation + startup discovery surfaces

• Adds marker-candidate reconciliation prior to the record pass, an asymmetric resolution matrix (dead/kill-confirmed/spare), CurrentDiscovery status updates, and BlockedCandidates reporting for startup completeness. Emits resolved evidence via injected sinks before deleting sources.

src/Capacitor.Cli.Daemon/Services/OrphanReaper.cs

ResolvedCandidatesLedger.csAdd durable resolved-candidates outbox ledger +82/-0

Add durable resolved-candidates outbox ledger

• Adds a durable, atomic persisted ledger keyed by (AgentId, OldEpoch) with monotonic Generation, ordered snapshots for reporting, and sparse per-entry pruning via AckResolvedCandidates.

src/Capacitor.Cli.Daemon/Services/ResolvedCandidatesLedger.cs

SequencedCommandProcessor.csAdd per-epoch serial sequenced command processor +187/-0

Add per-epoch serial sequenced command processor

• Implements exact-next acceptance, dedupe-by-(Seq,CommandId), contiguous terminal watermark advancement, and backpressure via bounded identity cache. Supports retirement via validated AckProcessedPrefix and emits CommandAck/CommandRejected one-way to the server.

src/Capacitor.Cli.Daemon/Services/SequencedCommandProcessor.cs

ServerConnection.csAdd sequenced settlement hub events and enriched connect payload +99/-1

Add sequenced settlement hub events and enriched connect payload

• Adds server→daemon receive seams (StopAgentV2, AckProcessedPrefix, RequestStatusReport, AckResolvedCandidates) and daemon→server one-way sends (CommandAck/CommandRejected). Enriches DaemonConnect with epoch/watermark/startup-completeness/ledger/capability fields while remaining wire-compatible.

src/Capacitor.Cli.Daemon/Services/ServerConnection.cs

Refactor (1) +8 / -6

AgentKillQuarantine.csReturn drained quarantine entries with flow identity +8/-6

Return drained quarantine entries with flow identity

• Adjusts RetryAllAsync to return drained Entry objects rather than agent ids so callers can ledger-append trusted flow identity before PID-record deletion.

src/Capacitor.Cli.Daemon/Services/AgentKillQuarantine.cs

Tests (10) +1007 / -0

CoverageJournalTests.csAdd CoverageJournal boot-chain coverage tests +89/-0

Add CoverageJournal boot-chain coverage tests

• Tests genesis seeding, chain continuity, downgrade-sandwich detection, sticky-false propagation, corrupt state handling, and crash-before-rename behavior.

test/Capacitor.Cli.Tests.Unit/Daemon/CoverageJournalTests.cs

DaemonLockPriorInstanceIdTests.csAdd tests for PriorInstanceId behavior +37/-0

Add tests for PriorInstanceId behavior

• Verifies PriorInstanceId is null for a fresh slot and equals the previous boot’s InstanceId on re-acquire.

test/Capacitor.Cli.Tests.Unit/Daemon/DaemonLockPriorInstanceIdTests.cs

HealBarrierReportTests.csAdd sequencing/heal-barrier report and liveness-race tests +158/-0

Add sequencing/heal-barrier report and liveness-race tests

• Validates report advertises epoch/watermark counters, ReadLiveness ordering prevents transient false-dead, sequenced capacity rejection emits daemon_capacity and advances watermark, StopAgentV2 advances watermark and removes confirmed-dead ids, and legacy unsequenced launches do not advance the watermark.

test/Capacitor.Cli.Tests.Unit/Daemon/HealBarrierReportTests.cs

LedgerHookOrchestratorTests.csAdd orchestrator-level ledger hook coverage +39/-0

Add orchestrator-level ledger hook coverage

• Adds unit tests exercising resolved-candidates ledger behavior as wired through AgentOrchestrator and ServerConnection seams.

test/Capacitor.Cli.Tests.Unit/Daemon/LedgerHookOrchestratorTests.cs

LedgerHookTests.csAdd crash-consistency tests for ledger feed hooks +178/-0

Add crash-consistency tests for ledger feed hooks

• Covers record-pass, quarantine-drain, and StopAgent fallback hooks including crash-before-append and crash-between-append-and-delete reconciliation ensuring idempotent single-emission.

test/Capacitor.Cli.Tests.Unit/Daemon/LedgerHookTests.cs

MarkerCandidateResolutionTests.csAdd tests for marker-candidate resolution matrix +179/-0

Add tests for marker-candidate resolution matrix

• Adds tests validating the marker-candidate spare/kill/resolve matrix and corroboration rules that prevent trusting mutable env data for flow identity.

test/Capacitor.Cli.Tests.Unit/Daemon/MarkerCandidateResolutionTests.cs

ResolvedCandidatesLedgerTests.csAdd resolved ledger persistence and pruning tests +46/-0

Add resolved ledger persistence and pruning tests

• Tests upsert idempotency, snapshot ordering, ack pruning, and persistence semantics for ResolvedCandidatesLedger.

test/Capacitor.Cli.Tests.Unit/Daemon/ResolvedCandidatesLedgerTests.cs

SequencedCommandProcessorTests.csAdd SequencedCommandProcessor correctness tests +133/-0

Add SequencedCommandProcessor correctness tests

• Tests serial execution, out-of-order rejection, fault→internal_error, synthesized terminal monotonicity under shutdown races, duplicate ack behavior, backpressure reopening via AckProcessedPrefix, and stale/regressing ack handling.

test/Capacitor.Cli.Tests.Unit/Daemon/SequencedCommandProcessorTests.cs

SequencedSettlementWireTests.csAdd wire token pinning and DTO round-trip tests +81/-0

Add wire token pinning and DTO round-trip tests

• Pins enum wire tokens and asserts snake_case JSON round-trips for new DTOs and additive fields, including conservative zero defaults (e.g., MarkerScanState.Pending).

test/Capacitor.Cli.Tests.Unit/Daemon/SequencedSettlementWireTests.cs

StartupCompletenessTests.csAdd startup-completeness signal tests +67/-0

Add startup-completeness signal tests

• Tests RecordlessSurvivorsImpossible surfacing, per-platform StartupDiscovery behavior, pending marker candidates blocking completion, and resolved-candidate ack pruning via report/connect surfaces.

test/Capacitor.Cli.Tests.Unit/Daemon/StartupCompletenessTests.cs

Documentation (1) +2775 / -0

2026-07-22-ai1391-b2b-daemon-sequenced-settlement.mdAdd B2-b daemon implementation plan (17 TDD tasks) +2775/-0

Add B2-b daemon implementation plan (17 TDD tasks)

• Adds the detailed daemon-side implementation plan for B2-b, including adversarial-review revisions around atomicity, crash injection, and monotonicity hazards.

docs/superpowers/plans/2026-07-22-ai1391-b2b-daemon-sequenced-settlement.md

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Coverage genesis misclassified on error ✓ Resolved 🐞 Bug ≡ Correctness

Description

CoverageJournal treats priorLockInstanceId == null as proof of a fresh genesis slot, but
DaemonLock sets PriorInstanceId to null on any read failure, conflating “empty file” with
“unreadable file”. This can incorrectly compute RecordlessSurvivorsImpossible=true in cases that
should fail-closed to false.

Code

src/Capacitor.Cli.Daemon/Services/CoverageJournal.cs[R47-54]

+            if (!journalExists) {
+                // Genesis is the ONLY seed-true base case: the journal file is absent (we are about to
+                // atomically initialize it) AND the captured prior lock shows no pre-existing InstanceId
+                // (a genuine first-ever boot for this name). A previously-used dir whose journal is gone
+                // but whose prior lock DOES carry an InstanceId is un-journaled history that re-pointing/
+                // deleting the dir cannot launder ⇒ false.
+                var genesis = priorLockInstanceId is null;
+                covered = genesis && thisEpochContained;

Evidence

CoverageJournal’s genesis logic is priorLockInstanceId is null, but DaemonLock’s read path
explicitly sets priorInstanceId = null in its catch-all error handler. That means read/parsing
failures can be misinterpreted as a clean genesis slot.

src/Capacitor.Cli.Daemon/Services/CoverageJournal.cs[41-60]
src/Capacitor.Cli.Daemon/DaemonLock.cs[114-127]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`CoverageJournal.RecordBoot` uses `priorLockInstanceId is null` as the genesis predicate. However, `DaemonLock.TryAcquire` assigns `PriorInstanceId = null` both when the lock file is truly empty and when reading/parsing fails. That breaks the journal’s “fail-closed” guarantee by potentially treating an unreadable prior instance id as a clean genesis.

### Issue Context
This affects the computed `DaemonConfig.RecordlessSurvivorsImpossible` advertised on connect/status. The design intent (per comments) is fail-closed: any missing/corrupt/unwritable state should evaluate to false.

### Fix Focus Areas
- src/Capacitor.Cli.Daemon/DaemonLock.cs[114-127]
- src/Capacitor.Cli.Daemon/Services/CoverageJournal.cs[41-60]

### Suggested fix
- Represent the prior-lock read as a 3-state value: {Empty, ReadOk(value), ReadFailed}.
 - Option A: add a `bool PriorInstanceIdReadOk` (or `PriorInstanceIdState`) to `DaemonLock`.
 - Option B: change `PriorInstanceId` type to something like `string?` plus a separate `bool priorKnown`.
- In `CoverageJournal.RecordBoot`, require an explicit “empty lock content” signal for genesis; if the read failed/unknown, force `covered = false` (fail-closed).
- Keep the chain-check (`priorLockInstanceId == tail.InstanceId`) unchanged when the read succeeded.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Lock InstanceId read breaks build ✓ Resolved 🐞 Bug ≡ Correctness

Description

DaemonLock.TryAcquire allocates new byte[stream.Length] where stream.Length is a long, which
does not compile and also enables unbounded allocation if the lock file is corrupted/oversized. This
blocks the build and makes startup vulnerable to memory pressure when reading the lock file.

Code

src/Capacitor.Cli.Daemon/DaemonLock.cs[R119-123]

+            if (stream.Length > 0) {
+                stream.Position = 0;
+                var buf = new byte[stream.Length];
+                var n = stream.Read(buf, 0, buf.Length);
+                priorInstanceId = System.Text.Encoding.UTF8.GetString(buf, 0, n)

Evidence

The new code reads the lock file by allocating a byte[] sized by FileStream.Length, which is a long
and cannot be used as an array length in C#. It also reads the whole file into memory even though
the file is expected to be a single short line.

src/Capacitor.Cli.Daemon/DaemonLock.cs[114-127]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`DaemonLock.TryAcquire` currently reads the previous lock-holder instance id by allocating a byte buffer sized to `stream.Length` (a `long`). This is a compile-time error in C# (array length must be `int`-compatible), and even after fixing the type it would still be risky to allocate based on an untrusted on-disk length.

### Issue Context
The lock file is expected to contain a single short line (`InstanceId + "\n"`). The implementation should read only the first line (bounded) and avoid large allocations. This prior instance id is also used downstream by `CoverageJournal.RecordBoot`, so this read should be robust.

### Fix Focus Areas
- src/Capacitor.Cli.Daemon/DaemonLock.cs[114-127]

### Suggested fix
- Replace the buffer allocation with a bounded first-line read (e.g., `StreamReader.ReadLine()` with `leaveOpen:true`, or manual small-buffer scanning until `\n` with a max length).
- Ensure you handle partial reads correctly (don’t assume a single `Read` fills the buffer).
- Keep `PriorInstanceId` as `null` only for a genuinely empty file; treat read errors distinctly (see related CoverageJournal finding).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Ledger persistence exceptions unhandled ✓ Resolved 🐞 Bug ☼ Reliability

Description

ResolvedCandidatesLedger mutates in-memory state and then calls Persist() with no exception
handling, so disk I/O failures can throw into orchestrator control flow and potentially leave
memory/disk out of sync. Additionally, the SignalR AckResolvedCandidates receive handler is
registered without SafeInvoke/try-catch, so exceptions during ack processing are not contained at
the hub boundary.

Code

src/Capacitor.Cli.Daemon/Services/ResolvedCandidatesLedger.cs[R76-81]

+    void Persist() {
+        var tmp = _path + ".tmp-" + Guid.NewGuid().ToString("N")[..8];
+        File.WriteAllText(tmp, JsonSerializer.Serialize(
+            new Persisted(_nextGeneration, [.. _entries.Values]), LedgerJsonCtx.Default.Persisted));
+        File.Move(tmp, _path, overwrite: true); // atomic same-directory rename
+    }

Evidence

The ledger’s Upsert/Ack mutate state then call Persist(), which performs WriteAllText/Move without
handling exceptions. The orchestrator directly calls ledger.Ack from its ack handler, and the hub
registration invokes that handler inline without SafeInvoke, so any thrown exception can propagate
out of the invocation callback.

src/Capacitor.Cli.Daemon/Services/ResolvedCandidatesLedger.cs[31-40]
src/Capacitor.Cli.Daemon/Services/ResolvedCandidatesLedger.cs[76-81]
src/Capacitor.Cli.Daemon/Services/AgentOrchestrator.cs[614-617]
src/Capacitor.Cli.Daemon/Services/ServerConnection.cs[206-217]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ResolvedCandidatesLedger.Upsert` and `Ack` both modify `_entries` / `_nextGeneration` and then call `Persist()` which performs file writes/move without try/catch. If any filesystem operation fails (disk full, permission, transient IO), the exception will propagate to callers, and the ledger can become inconsistent (memory already changed, disk not updated).

Also, `ServerConnection` registers the `AckResolvedCandidates` hub method without `SafeInvoke`, so exceptions from the orchestrator ack path aren’t contained/logged consistently at the hub boundary.

### Issue Context
The ledger is used in multiple “confirmed gone” hooks and is also pruned via a server→daemon Ack. These paths should not be able to destabilize the daemon when persistence fails; they should either fail closed (keep entries and retry) or degrade gracefully while logging.

### Fix Focus Areas
- src/Capacitor.Cli.Daemon/Services/ResolvedCandidatesLedger.cs[31-55]
- src/Capacitor.Cli.Daemon/Services/ResolvedCandidatesLedger.cs[76-81]
- src/Capacitor.Cli.Daemon/Services/ServerConnection.cs[206-217]
- src/Capacitor.Cli.Daemon/Services/AgentOrchestrator.cs[614-617]

### Suggested fix
- Make persistence failure-safe:
 - Compute the new state first, persist it successfully, then swap/commit it in-memory; or
 - Wrap `Persist()` in try/catch and, on failure, revert in-memory mutations (or don’t apply them until persist succeeds).
- Ensure `AckResolvedCandidates` handling cannot throw out of the SignalR dispatcher:
 - Wrap `OnAckResolvedCandidates?.Invoke(ack)` in `SafeInvoke(...)` or a local try/catch that logs and returns `Task.CompletedTask`.
- Consider logging at warning level with enough context (count of entries, ack generations) for diagnosis.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Verbose B2-b comment blocks ✗ Dismissed 📘 Rule violation ⚙ Maintainability

Description

New/modified comment blocks are lengthy and include extensive design-rationale that makes the code
harder to scan and maintain. This conflicts with the guideline to keep comments minimal and prefer
self-explanatory code.

Code

src/Capacitor.Cli.Daemon/Services/SequencedCommandProcessor.cs[R15-21]

+/// <summary>
+/// Phase B2-b (sequenced-settlement design §4.2.2; parent §5.5): the daemon's two-lane sequenced
+/// command handler. Exactly two command types are sequenced (Seq'd LaunchAgentCommand + StopAgentV2),
+/// executed strictly serially per epoch. Acceptance (bump HighestAcceptedSeq + cache entry + enqueue)
+/// is one atomic operation under <c>_lock</c>; LastProcessedSeq is the contiguous terminal prefix
+/// (advances only on a terminal outcome). Self-contained + delegate-injected so it is unit-testable
+/// with no live orchestrator (mirrors OrphanReaper/AgentKillQuarantine).

Evidence

PR Compliance ID 6 requires concise, necessary comments. The added XML/doc comments in
SequencedCommandProcessor and DaemonConfig are long, design-heavy explanations that could be
shortened and/or moved to the referenced design docs.

CLAUDE.md: Keep Comments Minimal; Prefer Self-Explanatory Code
src/Capacitor.Cli.Daemon/Services/SequencedCommandProcessor.cs[15-21]
src/Capacitor.Cli.Daemon/DaemonConfig.cs[37-44]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Several new/modified comments are overly verbose (multi-line design rationales and protocol narration). This reduces readability; prefer shorter summaries and rely on the spec/plan docs for detailed rationale.

## Issue Context
Compliance rule requires keeping comments minimal and favoring self-explanatory code.

## Fix Focus Areas
- src/Capacitor.Cli.Daemon/Services/SequencedCommandProcessor.cs[15-21]
- src/Capacitor.Cli.Daemon/DaemonConfig.cs[37-44]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---