@prestyj/cli 5.16.2 → 5.19.0

package/README.md

@@ -206,7 +206,7 @@ Reusable behaviors across projects. Drop `.md` files in:
 
 They get loaded into the system prompt automatically. The agent knows what it can do without you explaining it each session. <kbd>Ctrl+S</kbd> opens a pane to browse and toggle them.
 
-Ten ship built in, and route themselves when the work matches:
+Eleven ship built in, and route themselves when the work matches:
 
 | Skill              | Fires on                                                                                                                                                                                                                            |
 | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -217,6 +217,7 @@ Ten ship built in, and route themselves when the work matches:
 | `durable`          | User data must not be lost — first database/table, migrations, backfills/imports, destructive operations, backups and recovery; any store (Postgres, MySQL, SQLite, Mongo, serverless).                                              |
 | `evidence-led-ui`  | Broad or design-sensitive UI work — new screens, redesigns, design systems, accessibility passes.                                                                                                                                   |
 | `lean`             | Speed and resource efficiency — slow loading/startup, jank, high CPU, memory leaks and hogging, zombie/orphan processes, bundle bloat, dead code/styles, Core Web Vitals; while building anything that should stay fast, or a perf pass on an existing project. Any stack: web, backend, Electron, Tauri, mobile, native, game, ML. |
+| `refactoring`      | Restructuring existing code without changing behavior — "refactor", "clean up", "reduce tech debt", "modernize" or migrate legacy code; test-guarded steps, revert-on-red, characterization tests for untested code.              |
 | `root-cause`       | A bug that resists the obvious fix, makes no sense, or keeps coming back — gated diagnosis from red repro to ranked hypotheses to regression test.                                                                                  |
 | `shared-language`  | Fuzzy or drifting domain vocabulary, recurring naming decisions, and hard-to-reverse decisions worth recording (glossary + decision records).                                                                                        |
 | `tdd`              | Test-driven development — red-green-refactor with pre-agreed seams, when the user asks for test-first work.                                                                                                                          |

package/assets/skills/refactoring/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: refactoring
+description: Use when restructuring existing code without changing behavior — "refactor", "clean up this module", "reduce tech debt/duplication", "split this god class/function", "improve code quality", "modernize" or migrate legacy code (strangler fig, framework/dependency upgrades, callback→async), or when planning a refactor before touching code. Two hats, test-guarded steps, revert-on-red. Do NOT use for new feature work, bug fixes with known symptoms (root-cause), styling or copy changes, the refactor step inside a user-requested TDD flow (tdd), or when the user asks to rewrite from scratch.
+license: Behavior-preservation methodology synthesized from public sources (Fowler's Refactoring catalog, Tidy First?, and community agent skills by bienhoang, wondelai, mattpocock, jeffallan, vasilyu1983), audited 2026-09-12.
+---
+
+# Refactoring
+
+Change the structure of code without changing what it does. Every observable behavior that exists before the refactoring — including the bugs — must exist after it. This skill exists because agents drift: without hard gates, "refactoring" silently becomes rewriting, and rewriting untested code is how behavior is lost.
+
+**Without tests, you're not refactoring — you're editing.**
+
+## Governing rules
+
+1. **Two hats.** You are either adding function or restructuring, never both in the same change. Mixing them makes each unprovable. If new behavior is genuinely required, finish the structural change first, prove it, then change behavior in a separate step.
+2. **The baseline is a gate, not advice.** Before the first edit: the test suite runs green on unmodified code, or you build a safety net first (see mode 3). Record what you ran and its result. A suite that was already red tells you nothing — fix or quarantine the noise before counting on it.
+3. **One named transformation per step.** Each step applies exactly one refactoring (Extract Method, Move Function, Introduce Parameter…) and has a name you can state. If you cannot name it, it is not a refactoring — it is a rewrite wearing a costume.
+4. **Red means revert, not debug.** After each step, run the smallest relevant suite. Green ⇒ commit (when per-step commits were agreed — see the loop's checkpoint), message names the transformation. Red ⇒ revert the step immediately (`git restore`/`git checkout` the touched files). A red intermediate means the step was too big or wrong; debugging a broken step costs more than re-slicing it.
+5. **Never touch tests to get green.** In a pure refactor, modifying, loosening, or deleting an assertion is the cardinal sin — it destroys the only proof you have. If a test blocks legitimate structural change (asserts private internals), convert it to assert observable behavior *before* the transformation, as its own commit. Any unexplained test change in a refactor diff is a red flag.
+6. **Smallest suite per step, full suite per finish.** Iterate fast on the touched area, but before declaring done: full test suite + typecheck + lint, on the same commands CI runs.
+7. **Prove it, don't vibe it.** The closing question is not "is this good code" but "can I prove nothing observable changed?" Answer with evidence: suites run, before/after outputs, mutation spot-checks when the boundary is critical. Say plainly what you could not verify.
+8. **Make the change easy, then make the easy change** (Beck). Preparatory refactoring — small structural setup that makes the coming feature trivial — is the highest-ROI kind. Do it, then stop.
+9. **Public API surface is observable behavior.** Renaming or reshaping an exported symbol, endpoint, or file layout preserves runtime behavior but breaks consumers. Inside the module: refactor freely. Across a published boundary: deprecate-and-alias, never hard-break, unless the user chose the break.
+10. **Edit sources, not generated output.** `dist/`, vendored, or generated files are regenerated by their toolchain — hand-editing them is a change that the next build erases. Change the generator or the source, then regenerate.
+
+## Modes
+
+**1. In-the-small** — tidy a module, extract a function, kill duplication while working. The execute loop below, inline, without ceremony. Keep litter-pickup bounded to files you are already touching; a boy-scout sweep across the repo is scope creep.
+
+**2. Plan-first** — the user asks for a refactor plan, the change is architectural, or multiple approaches compete. Interview the problem, explore the repo to verify claims, fix scope as in/out lists, check test coverage (thin coverage is a question to the user, not an assumption), then break the work into a plan of tiny commits — each commit leaves the codebase working. File it where the user wants (issue, doc, or just the reply). Do NOT embed file paths or code snippets in the plan — they go stale before the work starts.
+
+**3. Legacy / untested** — no tests, unrunnable suite, or a migration too large for one session. Do not proceed with the normal loop. Go to `references/legacy.md`: characterization tests capturing *actual* current behavior (bugs included — log them, don't silently fix them), seams, branch-by-abstraction, parallel change (expand–migrate–contract), strangler fig.
+
+## Execute loop
+
+1. **Baseline.** Run the suite on unmodified code; record green. If red or absent → mode 3. If the project has no VCS or the working tree is dirty with unrelated changes, say so and stop for direction — a dirty baseline destroys the revert safety.
+2. **Commit checkpoint.** Refactoring is safest with per-step commits on a dedicated branch — ask the user once, up front: "I'll commit each verified step on a branch — good?" If they decline, keep steps small and separable and report the step list for review at the end. Never commit without authorization; without any VCS, or with unrelated uncommitted changes in the tree, say so and stop for direction — a dirty baseline destroys the revert safety.
+3. **Pick one target.** Ranked by risk-adjusted value, not by how interesting it is: security → correctness → structure → duplication → naming. Hotspots first — files where churn (recent edit frequency) meets complexity. Smell catalog and metrics thresholds: `references/smells.md`.
+4. **Apply one named transformation.** Full mechanics per transformation live in `references/smells.md`. Prefer language-aware tooling (IDE rename, AST codemods) over regex edits; at scale (>~10 files or >~500 lines), a codemod is the safe path and regex is the wrong one.
+5. **Verify.** Smallest relevant suite → green ⇒ commit (message = transformation name) → next target. Red ⇒ rule 4 of the governing rules: revert, take a smaller step.
+6. **Close.** Full suite + typecheck + lint, on the same commands CI runs — including every package that imports the code you touched, not just the one you edited (monorepos: respect build order). Report: transformations applied (named), before/after state, smells left and why, anything deferred. Agent-specific drift modes to check before closing: `references/agent-pitfalls.md`.
+
+## Risk levels set the safety net
+
+| Risk | Touching | Minimum net before editing |
+|---|---|---|
+| Low | Pure internals, no I/O | Unit tests + types |
+| Medium | Module boundary, parsing, state | + contract tests at the seam |
+| High | Money, auth, concurrency, migrations, data | + integration tests, a rollback plan, and small phases |
+
+When unsure whether behavior could change: **do not apply — ask.**
+
+## When NOT to refactor
+
+- No failing demand: nothing to add, nothing hurting. Refactoring without a driver is gold-plating.
+- The code is about to be deleted or replaced. Deleting is cheaper.
+- You cannot run or construct any safety net and the risk is medium+. Report and stop.
+- The rewrite instinct hits ("this is all wrong, let me start fresh"). That is a different conversation with the user, not a refactor — and big-bang rewrites lose the one thing refactoring keeps: working software at every step.
+
+## References
+
+- `references/smells.md` — smell catalog, metrics thresholds, prioritization, transformation mechanics
+- `references/legacy.md` — characterization tests, seams, branch-by-abstraction, parallel change, strangler fig, per-phase checkpoints
+- `references/agent-pitfalls.md` — how LLM agents specifically break "behavior-preserving", and the layered proof that catches it

package/assets/skills/refactoring/references/agent-pitfalls.md

@@ -0,0 +1,43 @@
+# Agent Pitfalls: How Refactors Drift
+
+LLM agents fail refactoring in specific, repeated ways. Human seniors watch for these; here is the checklist. Run it over your own diff before closing any refactor.
+
+## Drift modes (check each)
+
+- **Error-handling drift** — the old code swallowed or narrowly caught; the rewrite broadens to `catch (e)` "to be safe", or converts errors to exceptions/returns. Observable behavior changed.
+- **Boundary drift** — `>` becomes `>=`, `<` becomes `<=`, off-by-one in slices/loops, `length` vs `length-1`. Classic agent slip, invisible to typecheck.
+- **Rounding and numeric drift** — reordered arithmetic that changes floating-point results; integer division appearing where float was; new formatting on numbers.
+- **Ordering and concurrency drift** — Map/Set/object iteration order assumed where it wasn't guaranteed; sequential awaits parallelized with `Promise.all`; synchronous effects made async (or the reverse).
+- **Null/undefined semantics drift** — old code crashed on null; new code defaults it. Or falsy-checks (`x || y`) "simplified" from explicit `!== undefined` where `0`/`""` are valid values.
+- **Scope and visibility drift** — module-level state introduced where locals were; caching added for performance that changes identity or staleness semantics.
+- **Silent feature addition** — validation, logging, or "improvements" smuggled in because the old code "looked wrong". The old behavior was the spec.
+- **Flaky green** — a test fails, passes on rerun, and gets shrugged off. During a refactor, one flaky red invalidates the whole green: rerun it, and if it flakes, quarantine and fix the flakiness before trusting any suite result.
+
+## Test-healing anti-pattern
+
+The agent's tests go red; instead of reverting the code, it loosens the test. Any test-file change in a pure-refactor diff is a red flag requiring an explicit justification of the form: "this test asserted private internals; converted to assert observable behavior, in a separate prior commit." Loosened bounds, deleted assertions, added `.skip`, `any` casts in assertions — all count.
+
+## Chesterton's Fence
+
+Before deleting code that looks pointless: `git blame`, read the commit message, check issue/changelog references. Code that survives despite looking wrong often guards an incident. If history is unavailable and the reason is unknowable, flag it to the user instead of deleting.
+
+## Layered verification, cheapest first
+
+Escalate only as far as the risk level demands:
+
+1. **Typecheck** — catches signature/shape drift for freer.
+2. **Lint** — catches dead code, suspicious patterns, unintended scope.
+3. **Unit + characterization suites** — the core proof; smallest relevant suite per step, full suite at close.
+4. **Contract test at the changed boundary** — input/output fixtures frozen before the refactor, diffed after.
+5. **Mutation spot-check** (high-risk boundaries only) — hand-mutate the refactored code (flip a comparison, drop a condition); tests must fail. If they don't, the net has holes: strengthen tests before trusting green.
+
+## Closing self-review
+
+Re-read your own full diff and answer, in the report:
+
+- Which drift modes above did I check, and how do I know each is absent?
+- Did I modify any test file? If yes, justify per the anti-pattern rule.
+- What did the suites run, exactly (commands), and were they green on unmodified code first?
+- What could I not verify, and what residual risk does the user hold?
+
+"Can I prove nothing observable changed" — not "is the code nicer now".

package/assets/skills/refactoring/references/legacy.md

@@ -0,0 +1,49 @@
+# Legacy and Untested Code
+
+For codebases or areas where the baseline gate cannot be met: no tests, an unrunnable suite, or a migration too large to land as small commits. The prime directive still holds — observable behavior preserved, bugs included (log them; fixing them is separate work the user must choose).
+
+## Sequence
+
+**1. Make the system runnable and observable.** Get it to start locally with realistic data. If you cannot execute it, say so and stop — static-only refactoring of critical legacy paths is a coin flip.
+
+**2. Build characterization tests (golden master).** Tests that assert what the code *actually does*, not what it should do:
+
+- Call the boundary (public API, CLI, event handler, exported function) with real inputs.
+- Capture the full observable output — return values, written files, emitted events, HTTP responses, log lines.
+- Assert the captured behavior, including wrong-looking output. If output looks like a bug, record the bug and pin the bug.
+- Sufficient coverage: the paths your refactor will touch and their immediate callers. 80% project coverage is not the bar; coverage of the change surface is.
+
+Gate: the characterization suite is **green against the unmodified system** before any refactoring. A red baseline proves nothing later.
+
+**3. Create seams before structure.** A seam is a place where behavior can be intercepted without editing the logic:
+
+- Extract an interface over the dependency, implement it twice (old, new).
+- Dependency injection for clocks, RNGs, IDs, filesystem, network — anything that makes behavior nondeterministic.
+- Adapter wrapping the legacy module so new code consumes the adapter, not the legacy internals.
+
+**4. Migrate by one of the incremental strategies below** — never big-bang.
+
+**5. Delete last.** The legacy path is removed only after the new path has provably carried the full behavior (characterization suite green against the new path). Before deleting anything old, check why it exists — `git blame` / changelog; code that looks pointless sometimes guards an incident (Chesterton's Fence).
+
+## Incremental migration strategies
+
+### Branch by Abstraction
+For replacing an internal implementation that many callers use. Create an abstraction over the old implementation → migrate callers to it one by one (each a working commit) → implement the new behind the abstraction → flip the default → delete the old. Hybrid states are acceptable and working at every commit.
+
+### Parallel Change (expand–migrate–contract)
+For changing a live contract (API, storage schema, queue message) where old and new consumers coexist:
+
+1. **Expand** — support both old and new forms side by side; write the new form.
+2. **Migrate** — move every consumer to the new form, one by one.
+3. **Contract** — after all readers are migrated and nothing reads the old form, remove it.
+
+Never skip the migration phase because tests pass — external consumers may exist that tests don't model.
+
+### Strangler Fig
+For replacing a subsystem wholesale. Put a facade in front of the legacy system → route traffic through the facade → intercept one route/slice at a time, implementing it fresh behind the facade (guarded by a feature flag when the slice is risky) → when all slices are intercepted, the legacy core is unused; delete it. Each interception must keep the characterization suite green.
+
+## Per-phase discipline (all strategies)
+
+Every phase ends with a **validation checkpoint**: characterization + full suite green, and a stated **rollback trigger** — the condition under which this phase is reverted (a commit, a flag flip, never a re-merge). Keep commits bisectable: one phase-step per commit, `git bisect` must stay usable for finding which step changed behavior.
+
+Feature flags guard risky slices, but flags are debt: each one gets a removal issue at creation, and is retired as soon as the new path is proven.

package/assets/skills/refactoring/references/smells.md

@@ -0,0 +1,71 @@
+# Smells, Metrics, Prioritization
+
+Detection and targeting material for the refactoring skill. Thresholds are heuristics for *where to look*, never rules that a file crossing one must be refactored.
+
+## Metrics quick reference
+
+Estimate without tooling: cyclomatic complexity ≈ count of decision points (`if`, `while`, `for`, `&&`, `||`, `case`, `catch`, ternary) + 1. Cognitive complexity adds weighting for nesting.
+
+| Metric | Comfortable | Refactor signal |
+|---|---|---|
+| Cyclomatic complexity (function) | < 10 | 16+ |
+| Cognitive complexity (function) | < 10 | 15+ |
+| Function length | < 30 lines | 50+ (or one screen) |
+| Class/module length | < 300 lines | 500+ |
+| Parameters | ≤ 3 | 6+ (or booleans that change behavior) |
+| Duplication | — | Same logic 3+ places (Rule of Three) |
+
+## Smell catalog
+
+Work top of list first within a risk band. Each entry: signal → usual transformation.
+
+### Bloaters
+- **Long method / function** — exceeds a screen, needs comments to explain sections → Extract Method; conditional blocks each become guard clauses or extracted methods.
+- **God class / module** — knows everything, changes for every reason → Extract Class by responsibility; move features to the module that owns the data (Feature Envy fix).
+- **Long parameter list** — callers pass the same cluster → Introduce Parameter Object; or pass the object the params came from.
+- **Primitive obsession** — coordinates, money, IDs as bare strings/numbers everywhere → Introduce Value Object with validation at creation.
+
+### Change preventers
+- **Divergent change** — one module changed for many unrelated reasons → split by reason (Extract Class).
+- **Shotgun surgery** — one change scattered across many files → Move Function/Field until one module owns the concept.
+- **Parallel inheritance hierarchies** — two hierarchies that must move together → reference one from the other, or unify with a strategy.
+
+### Dispensables
+- **Duplicate code** — same logic 3+ places (Rule of Three: tolerate twice, extract on the third) → Extract Function, share it. Two occurrences with divergence is a bug factory.
+- **Dead code** — unreached branches, unused exports, commented-out blocks → delete. Git history has it.
+- **Speculative generality** — abstraction with one caller, flags always passed the same value, "we might need it" → inline and delete. Treat as aggressively as bloat; agents generate this smell by default.
+- **Magic numbers** — unexplained literals → named constant placed where its meaning lives.
+
+### Couplers
+- **Feature envy** — method mostly reads another module's data → Move Function to the data.
+- **Inappropriate intimacy** — modules poking each other's privates → Move Method/Field, or extract the shared concept.
+- **Message chains** — `a.b().c().d()` → hide the chain behind a method on the object you know.
+- **Middle man** — class that only forwards → remove it, let callers talk directly.
+
+### Conditionals
+- **Deep nesting** — 3+ levels → guard clauses, then Extract Method per branch; Replace Nested Conditional with Guard Clauses.
+- **Complex switch repeated** — same switch on type in multiple places → Replace Conditional with Polymorphism (or a lookup table for the simple data case — do not build a class hierarchy to avoid an object literal).
+- **Boolean-flag parameters** — `doThing(x, true)` → split into two named functions.
+
+## Transformation mechanics (the load-bearing ones)
+
+Each must be mechanically checkable — "does everything still compile/tests green" — before the next.
+
+- **Extract Method/Function**: create the new function, copy code, pass locals as params, replace body with a call. Pitfall: extraction that captures mutable local state — pass state explicitly or take smaller slices.
+- **Rename**: language-aware rename (LSP/IDE) only at any nontrivial scope; never textual find-replace on names shorter than the unique threshold. Renaming is the highest-value, lowest-risk transformation — do it early and often.
+- **Move Function**: move, fix references, adjust visibility. Best when the function's data lives in the destination (Feature Envy).
+- **Introduce Parameter Object**: group params into a record, migrate callers mechanically.
+- **Replace Conditional with Polymorphism**: only after the switch is duplicated in 2+ places; introduce subtype per branch, migrate case by case, delete the switch last.
+- **Replace Magic Number / Introduce Named Constant**: constant named by *meaning*, not value (`MAX_RETRIES`, not `THREE`).
+
+## Prioritization
+
+Order targets by **risk-adjusted value**:
+
+1. **Security** — smells near auth, input handling, crypto.
+2. **Correctness** — duplication with divergence, boundary-handling drift, shared mutable state.
+3. **Hotspots** — churn × complexity. `git log --format=%H <path>` / blame frequency identifies churn; complexity from the table above. A moderately messy file nobody touches is not worth your risk budget.
+4. **Structure** blocking the change the user actually wants (preparatory refactoring).
+5. **Duplication, naming** — cheapest, do opportunistically in touched files.
+
+Defer with a note when: no failing demand, near deletion, or the safety net cannot reach it this session.

package/dist/app-sidecar-sessions.d.ts

@@ -8,4 +8,3 @@ export type SidecarSession = RecentSession & {
  * `homeDir` lets tests point Claude Code / Codex lookup at a fixture home.
  */
 export declare function listSidecarSessions(cwd: string, requestedAgent: string | null, coderSessionsDir: string, homeDir?: string): Promise<SidecarSession[]>;
-//# sourceMappingURL=app-sidecar-sessions.d.ts.map

package/dist/app-sidecar.d.ts

@@ -1,2 +1 @@
 export {};
-//# sourceMappingURL=app-sidecar.d.ts.map

package/dist/app-sidecar.js

@@ -56,6 +56,7 @@ import { getModel, getDefaultThinkingLevel, getContextWindow, getAllModels, clea
 import { resolveStartOrFallback } from "./core/resolve-start.js";
 import { getGitBranch, getGitDirtyFileCount, isGitRepo } from "./utils/git.js";
 import { getGitHubOpenCounts, getGitHubRepoSlug } from "./utils/github.js";
+import { startGitHubCIPoll } from "./utils/github-ci.js";
 import { extractPlanSteps } from "./utils/plan-steps.js";
 import { getNextThinkingLevel, getSupportedThinkingLevels, isThinkingLevelSupported, } from "./core/thinking-level.js";
 import { PROMPT_COMMANDS } from "./core/prompt-commands.js";
@@ -1018,6 +1019,8 @@ function buildNolanContext(buildSession, cwd, gitBranch, question, workflowComma
         cwd,
         gitBranch,
         messages: buildSession.getMessages(),
+        verificationEvidence: buildSession.getVerificationEvidence(),
+        verificationProblem: buildSession.getVerificationProblem(),
         workflowCommands,
         injectedPrompts,
     });
@@ -1683,6 +1686,7 @@ async function createSession(deps, opts) {
     const gitHubSlug = initialGitHubSlug;
     let gitHubIssues = null;
     let gitHubPRs = null;
+    let gitHubCI = null;
     function currentContextWindow() {
         const st = session.getState();
         return getContextWindow(st.model, { provider: st.provider, accountId: st.accountId });
@@ -1697,6 +1701,7 @@ async function createSession(deps, opts) {
             gitDirtyFileCount,
             gitHubIssues,
             gitHubPRs,
+            gitHubCI,
             gitHubRepoUrl: gitHubSlug ? `https://github.com/${gitHubSlug}` : null,
             tasks: session.listBackgroundProcesses(),
             // Roots added with /add-dir — the header shows a badge when non-empty.
@@ -1885,6 +1890,7 @@ async function createSession(deps, opts) {
     });
     session.eventBus.on("model_change", (d) => broadcast("model_change", d));
     session.eventBus.on("hook", (d) => broadcast("hook", d));
+    session.eventBus.on("diagnostics", (d) => broadcast("diagnostics", d));
     // Fires BEFORE the candidate final answer streams. The webview holds assistant
     // text back while armed, so an Ideal review supersedes a draft that was never
     // painted instead of deleting one the user already started reading.
@@ -2201,7 +2207,14 @@ async function createSession(deps, opts) {
         }
         finally {
             const cancelled = runLifecycle.isCancellationRequested(generation);
+            const verificationProblem = cancelled ? null : session.getVerificationProblem();
+            if (runSucceeded && verificationProblem && ownsGeneration) {
+                // Expected control outcome: run_end and the journal already carry Unverified.
+                // Do not format it as a crash or persist a misleading error marker.
+                log("WARN", "app-sidecar", "verification incomplete", { message: verificationProblem });
+            }
             if (runSucceeded &&
+                !verificationProblem &&
                 !cancelled &&
                 cancelGeneration === cancelGenAtStart &&
                 countAssistantMessages(session.getMessages()) > assistantsBeforeRun) {
@@ -2218,12 +2231,14 @@ async function createSession(deps, opts) {
             // A run may have opened/closed issues or PRs — refresh fire-and-forget so
             // teardown isn't delayed by the network. Broadcasts itself on change.
             void refreshGitHubCounts();
+            void ciPoll.refresh();
             // Serialize behind any marker/tool-triggered refresh so the terminal
             // progress snapshot uses the live plan file. Once every canonical step
             // is complete, remove the approved plan from future system prompts and
             // clear the widget before run_end paints the idle activity bar.
             if (runSucceeded &&
                 !cancelled &&
+                !verificationProblem &&
                 approvedPlanPath !== null &&
                 (await queueApprovedPlanProgressSync())) {
                 try {
@@ -2240,7 +2255,7 @@ async function createSession(deps, opts) {
                 }
             }
             if (ownsGeneration) {
-                finishOwnedGeneration(generation, false, runSucceeded ? "completed" : "failed");
+                finishOwnedGeneration(generation, false, verificationProblem ? "unverified" : runSucceeded ? "completed" : "failed");
             }
             // A cancelled injected run is still owned by the surrounding autopilot
             // cycle; its outer finalizer emits the one terminal cancelled run_end.
@@ -2249,6 +2264,7 @@ async function createSession(deps, opts) {
                     cancelledRunEndGenerations.add(generation);
                 broadcast("run_end", {
                     ...(cancelled ? { cancelled: true } : {}),
+                    ...(verificationProblem ? { unverified: true } : {}),
                     runState: runLifecycle.state,
                 });
             }
@@ -2282,6 +2298,8 @@ async function createSession(deps, opts) {
                 cwd,
                 gitBranch,
                 messages: session.getMessages(),
+                verificationEvidence: session.getVerificationEvidence(),
+                verificationProblem: session.getVerificationProblem(),
                 originalRequest,
                 injectedPrompts: [...injectedAutopilotPrompts],
                 workflowCommands: await loadWorkflowCommandSpecs(),
@@ -2325,6 +2343,8 @@ async function createSession(deps, opts) {
                 cwd,
                 gitBranch,
                 messages: session.getMessages(),
+                verificationEvidence: session.getVerificationEvidence(),
+                verificationProblem: session.getVerificationProblem(),
                 originalRequest,
                 injectedPrompts: [...injectedAutopilotPrompts],
                 workflowCommands: await loadWorkflowCommandSpecs(),
@@ -2364,7 +2384,7 @@ async function createSession(deps, opts) {
     // control flow lives in driveAutopilotCycle (core/autopilot-cycle.ts) so
     // every exit path is unit-tested; this only wires the real dependencies.
     async function runAutopilotCycle(originalRequest) {
-        if (!autopilot || autopilotCancelled)
+        if (!autopilot || autopilotCancelled || session.getVerificationProblem())
             return;
         const generation = runLifecycle.begin(abortOwnedWork).generation;
         pendingCancelDrain = null;
@@ -2380,6 +2400,7 @@ async function createSession(deps, opts) {
                 // round available.
                 maxRounds: pendingPlanPath !== null ? MAX_AUTOPILOT_ROUNDS + 2 : MAX_AUTOPILOT_ROUNDS,
                 isCancelled: () => autopilotCancelled,
+                verificationProblem: () => session.getVerificationProblem(),
                 // An injected run entering plan mode WITHOUT submitting (enter_plan,
                 // no exit_plan) halts the cycle — Nolan never prompts into a read-only
                 // plan-mode session. A submitted plan takes the planPending branch.
@@ -2392,7 +2413,7 @@ async function createSession(deps, opts) {
                 // Auto-accept: the inlined POST /plan/accept body. Returns false when
                 // the plan generation moved since the review (user acted) — the cycle
                 // exits silently and the user's action stands.
-                acceptPlan: async () => {
+                acceptPlan: async (reason) => {
                     if (pendingPlanPath === null || planGeneration !== planGenAtReview)
                         return false;
                     const planPath = pendingPlanPath;
@@ -2409,11 +2430,11 @@ async function createSession(deps, opts) {
                     clearPendingPlan();
                     // Keep the approval marker ahead of the reset, then seed the reset
                     // with the sidecar's canonical count from the actual plan file.
-                    broadcast("autopilot_plan_accepted", {});
+                    broadcast("autopilot_plan_accepted", reason ? { reason } : {});
                     broadcast("session_reset", { planTotal });
                     broadcast("plan_progress", planProgressPayload());
                     // Persisted into the NEW session so a resume shows the marker.
-                    void session.persistAutopilotMarker("plan_approved");
+                    void session.persistAutopilotMarker("plan_approved", { reason });
                     return true;
                 },
                 runImplement: () => {
@@ -2467,9 +2488,10 @@ async function createSession(deps, opts) {
                             version: 1,
                             phase: "done",
                             afterMessageCount: session.getPersistedTranscriptCount(),
+                            ...event.data,
                         });
                         broadcast(event.type, { ...event.data, copySeed: seed });
-                        void session.persistAutopilotMarker("done");
+                        void session.persistAutopilotMarker("done", event.data);
                         return;
                     }
                     broadcast(event.type, event.data);
@@ -2486,7 +2508,7 @@ async function createSession(deps, opts) {
         finally {
             autopilotActive = false;
             session.setIdealReviewSuppressed(autopilot);
-            finishOwnedGeneration(generation, true);
+            finishOwnedGeneration(generation, true, session.getVerificationProblem() ? "unverified" : "completed");
             queueMicrotask(() => void runStrandedQueue());
         }
     }
@@ -2754,6 +2776,10 @@ async function createSession(deps, opts) {
         gitHubPoll.unref?.();
     };
     scheduleGitHubPoll(2000);
+    const ciPoll = startGitHubCIPoll(cwd, (next) => {
+        gitHubCI = next;
+        broadcast("extras", footerExtras());
+    });
     function readBody(req, res) {
         return readCappedBody(req, res);
     }
@@ -4162,10 +4188,14 @@ async function createSession(deps, opts) {
                 }
                 // `false` means it already drained into the run between render and
                 // click. That is a race, not an error, so report it as a normal result
-                // and let the client reconcile from the fresh list.
+                // and let the client reconcile through the ordered event stream.
                 const cancelled = session.cancelQueuedMessage(id);
                 const queued = session.listQueuedMessages();
-                broadcast("queued", { count: queued.length, messages: queued });
+                broadcast("queued", {
+                    count: queued.length,
+                    messages: queued,
+                    ...(cancelled ? { cancelledId: id } : {}),
+                });
                 json(res, 200, { cancelled, queued });
             });
             return;
@@ -5115,6 +5145,7 @@ async function createSession(deps, opts) {
         gitHubPollStopped = true;
         if (gitHubPoll)
             clearTimeout(gitHubPoll);
+        ciPoll.stop();
         // Stop the Telegram serve loop + dispose its per-chat sessions.
         if (serveController)
             await serveController.stop().catch(() => { });