codecartographer-pi 0.16.0 → 0.17.1

package/.codecarto/findings/protocols/SKILL.md

@@ -77,6 +77,7 @@ Produce four outputs:
 Mark every finding with one of these evidence levels:
 - `observed fact`: direct statement from docs, tests, schemas, types, or code.
 - `strong inference`: protocol conclusion drawn from multiple facts.
+- `external-behavior claim`: a claim about what the peer or a system outside this source tree does with a message (how it parses, what it ignores, version-dependent behavior); unverifiable by reading this code, so it stays unsettled until a runtime capture or that system's own source confirms it.
 - `portability hazard`: assumption tied to the source language, runtime, terminal, OS, or third-party SDKs.
 - `open question`: missing or conflicting behavior that still needs evidence.
 

package/.codecarto/findings/reimplementation-spec/SKILL.md

@@ -69,7 +69,7 @@ End with a spike list:
 - risky performance assumptions
 - platform-sensitive areas that need targeted tests
 
-For every defect in the bundle, preserve its disposition (`fix before porting`, `port differently`, or `leave behind`) and convert it into an explicit design consequence or acceptance check.
+For every defect in the bundle, preserve its disposition (`fix before porting`, `port differently`, `leave behind`, or `verify at runtime`) and convert it into an explicit design consequence or acceptance check — except `verify at runtime`, which becomes a Spike List entry and a `post_pipeline` entry of `kind: spike` in your handoff, never a design consequence: the diagnosis has not been confirmed, and designing around it would build the unverified claim into the new system.
 
 Use the output template at `templates/reimplementation-spec.md`.
 

package/.codecarto/skills/spec-delta-application/SKILL.md

@@ -26,11 +26,13 @@ Triage every delta into one of four buckets:
 |---|---|---|
 | **APPLY** | Delta is a real correction or required addition; the spec is wrong without it. | Edit the spec body. Add a `[revised per <source> §<delta-id>]` marker at the changed section. Record in DELTAS-APPLIED.md. |
 | **CLARIFY** | Delta proposes wording change; the spec's *meaning* is correct but the language is ambiguous. | Edit the spec wording (not the rule). Record in DELTAS-APPLIED.md as a clarification. |
-| **DEFER** | Delta is a real improvement but not load-bearing for the next implementation step. | Add to BACKLOG.md with rationale and a back-reference. Do NOT edit the spec. |
+| **DEFER** | Delta is a real improvement but not load-bearing for the next implementation step. | Add to `BACKLOG.md` with rationale and a back-reference (`templates/backlog-project.md` gives the entry shape). Do NOT edit the spec. |
 | **REJECT** | Delta is wrong on close reading (premise was incorrect, scope was misread, the rule it proposes already exists, etc.). | Document in DELTAS-APPLIED.md with a one-line rationale. Do NOT edit the spec. |
 
 The previous wisdom: any delta you can't decisively bucket should default to DEFER. The cost of a missed correction is one re-application pass; the cost of a bad correction is shipped.
 
+**DEFER goes to `BACKLOG.md`, not `DECISIONS.md`, and gets no `D` number.** `DECISIONS.md` is for what the project decided to *do*; `BACKLOG.md` is for what it decided to *defer*. A refinement you make while applying a delta — the applied text going beyond the literal proposal — is a decision: record it in the audit file's Decisions Beyond Triage section, and lift it into `DECISIONS.md` only if it is cross-cutting. An existing `D` entry for a proposed delta has its disposition updated in place (`APPLIED 2026-05-03 round-3`); it is never superseded by a new entry when applied.
+
 ## Citation convention
 
 Every applied or clarified delta leaves a citation marker in the spec body so a future reader can trace the change back to its source.

package/.codecarto/templates/architecture-map.md

@@ -3,7 +3,7 @@
 <!--
   Output template for the architecture phase.
   Fill in each section. Remove placeholder text. Keep the section headers.
-  Mark every conclusion as: fact / strong inference / open question.
+  Mark every conclusion as: fact / strong inference / external-behavior claim / open question.
 -->
 
 ## System Intent

package/.codecarto/templates/backlog-project.md

@@ -0,0 +1,51 @@
+# Backlog
+
+Project-level deferrals: work this project decided **not** to do yet, with the reasoning
+that made deferring the right call. One entry per deferral.
+
+This is the project's backlog, not CodeCartographer's. Items about the framework itself —
+a phase prompt that misled you, a validation criterion that does not fit — belong in
+feedback to the framework, not here.
+
+**BACKLOG vs DECISIONS.** `DECISIONS.md` records what the project decided to **do**;
+this file records what it decided to **defer**. Deferrals get no `D` number. If a deferred
+item is later picked up, remove its entry here and record the decision in `DECISIONS.md`.
+
+## Format
+
+```
+## <ID>. <Short title>
+
+**Raised by:** <closeout file, phase, or DECISIONS.md entry that produced this deferral>
+
+**Why deferred:** <the reasoning — what made this not worth doing now, not just "later">
+
+**Preconditions:** <what has to land before this can be revisited: a module, an artifact,
+a decision, an answer to an open question. "None" is a valid answer, but say so.>
+
+**Smallest viable form:** <the least you could build that would settle the item, so whoever
+picks it up does not have to redesign it from scratch>
+```
+
+## Entries
+
+<!--
+  Append entries below this marker. Number them however the project prefers (B1, B2, … is
+  the convention the framework's own backlog uses).
+
+  Example:
+
+  ## B1. Retry policy for the upload path
+
+  **Raised by:** closeouts/2026-03-14-contracts.md
+
+  **Why deferred:** The contracts phase found no documented retry behavior, but nothing
+  downstream depends on knowing it — the porting phase can treat uploads as at-most-once
+  and flag the gap.
+
+  **Preconditions:** A protocols-phase answer on whether the server deduplicates by
+  request id. Without that, any retry policy written here is a guess.
+
+  **Smallest viable form:** One paragraph in the contracts report stating the observed
+  behavior and the assumption downstream phases should hold.
+-->

package/.codecarto/templates/broadside-scout-brief.md

@@ -0,0 +1,97 @@
+# Broad-Side Scout Brief — [project_name]
+
+<!--
+  Output template for the `broadside-scout` phase.
+  Distills a Broad-Side batch reconnaissance run into leads routed to later
+  phases. See findings/broadside-scout/SKILL.md for instructions.
+
+  Every entry here is an UNVERIFIED lead from a cheap batch model, not a
+  finding. No later phase may cite this file as a source.
+-->
+
+## Scout Context
+
+- **Run:** `broadside/[run-id]/` (or: no completed run — see Scout Coverage)
+- **Model:** [batch model id]
+- **Lenses that ran:** [list]
+- **Recorded cost:** [from run-meta.json]
+- **Pipeline:** [pipeline variant name]
+- **Date:** [date]
+
+> These are unverified scouting leads. Each one is a place to look, not a
+> fact. The receiving phase confirms it against the source and cites the
+> source — never this brief.
+
+---
+
+## Leads by Phase
+
+<!--
+  One row per lead. Target must be a phase in the active pipeline.
+  Source pointer is the file:line (or module) the receiving phase starts from.
+  Confidence is the scout's, not yours: high / medium / low.
+  Drop anything the target phase would find in its own first pass.
+-->
+
+| # | Target phase | Lead | Source pointer | Lens | Scout confidence |
+|---|--------------|------|----------------|------|------------------|
+| 1 | | | | | |
+
+---
+
+## Convention Candidates
+
+<!--
+  From the conventions lens. These route to the orchestrator's CONVENTIONS.md
+  promotion review, not to a phase. Candidates only — promotion still requires
+  the orchestrator's review against the code.
+-->
+
+| # | Candidate convention | Where the scout saw it |
+|---|----------------------|------------------------|
+| 1 | | |
+
+---
+
+## Leads Dropped
+
+<!--
+  What you chose not to forward, and why. This is the record that keeps the
+  brief short without hiding the discard.
+-->
+
+| # | Lead | Why dropped |
+|---|------|-------------|
+| 1 | | |
+
+---
+
+## Coverage and limits
+
+<!--
+  What the scout scanned, what it did not, and what came back unusable. A
+  later phase must be able to tell "the scout found nothing there" from "the
+  scout never looked there." Sourced from broadside/<run>/run-meta.json.
+-->
+
+- Inspected scope: [modules scanned, or "whole repository in one slice"]
+- Skipped scope: [modules the lens globs, slicing cap, or incremental diff excluded; lenses skipped, with reason]
+- Evidence basis: batch-model scouting signals only — no source inspection, no tests, no runtime verification
+- Known blind spots: [truncated slices and the modules they covered; everything under Skipped scope is unscouted, not clean]
+- Coverage disposition: COMPLETE | PARTIAL | NONE (no completed Broad-Side run)
+
+## Validation
+
+<!-- Fill in this table per workflow/VALIDATE.md. The rows below match the broadside-scout scope. -->
+
+| # | Criterion | Result | Evidence |
+|---|-----------|--------|----------|
+| 1 | Every forwarded lead names a target phase in this pipeline and a source pointer the target phase can start from. | PASS / PARTIAL / FAIL | |
+| 2 | Every lead is marked as an unverified scouting signal; none is stated as a fact or cited as evidence. | PASS / PARTIAL / FAIL | |
+| 3 | Leads dropped rather than forwarded are recorded with a reason. | PASS / PARTIAL / FAIL | |
+| 4 | Convention candidates are routed to the orchestrator's CONVENTIONS.md review, not to a phase. | PASS / PARTIAL / FAIL | |
+| 5 | When no completed Broad-Side run exists, the brief says so explicitly and forwards no leads. | PASS / PARTIAL / FAIL | |
+| 6 | Coverage and limits name inspected scope, skipped scope, evidence basis, and blind spots. | PASS / PARTIAL / FAIL | |
+
+**Validated by:** [session identifier or date]
+**Overall:** PASS / PASS WITH GAPS / FAIL

package/.codecarto/templates/defect-report.md

@@ -16,6 +16,12 @@
 <!-- For each finding: location, defect, evidence, severity, evidence level, action. -->
 <!-- Sort by severity: critical → high → medium → low. -->
 <!-- If no findings, write "No defects found in this category." -->
+<!-- Evidence Level: observed fact / strong inference / external-behavior claim / open question.
+     Action — pre-porting pipelines: fix before porting / port differently / leave behind / verify at runtime;
+     maintenance pipelines: fix now / track / accept / investigate.
+     Pairing rule (validated mechanically): open question or external-behavior claim ⇒ verify at
+     runtime or port differently (pre-porting) / investigate (maintenance), never fix before porting
+     or fix now; and list the finding in ## Open Questions below. -->
 
 | # | Location | Defect | Severity | Evidence Level | Action |
 |---|----------|--------|----------|----------------|--------|
@@ -99,6 +105,21 @@
 
 ---
 
+## Open Questions
+
+<!-- Every finding whose Evidence Level is open question or external-behavior claim gets a row
+     here, so the hedge travels with the finding into this document — not only into the handoff.
+     Mirror each row into your phase handoff's open_questions (kind: needs-runtime-test unless a
+     maintainer decision or spec ruling is what is missing). Derived findings lists the finding
+     numbers (e.g. "5.2, 4.1") that depend on this question; none of them may carry a settled
+     action while the question stands. -->
+
+| ID | Kind | Question | Why source cannot settle it | Derived findings |
+|----|------|----------|-----------------------------|------------------|
+| | | | | |
+
+---
+
 ## Coverage and limits
 
 - Inspected scope:
@@ -120,6 +141,8 @@
 | 4 | Summary tables are complete and counts match the detailed findings. | PASS / PARTIAL / FAIL | |
 | 5 | Findings are marked with evidence levels. | PASS / PARTIAL / FAIL | |
 | 6 | Coverage and limits name inspected scope, skipped scope, evidence basis, and blind spots. | PASS / PARTIAL / FAIL | |
+| 7 | Unsettled findings (evidence level open question or external-behavior claim) carry an unsettled action (verify at runtime or port differently on pre-porting pipelines; investigate on maintenance pipelines), never a settled one, and each appears in the Open Questions table. | PASS / PARTIAL / FAIL | |
+| 8 | Every quantitative specific in a finding (size, count, default, version, timeout) cites the file and line or command output it was read from, or is marked as an estimate. | PASS / PARTIAL / FAIL | |
 
 **Validated by:** [session identifier or date]
 **Overall:** PASS / PASS WITH GAPS / FAIL

package/.codecarto/templates/mechanical-defects.md

@@ -22,6 +22,11 @@
 <!-- For each finding: location, defect, evidence, severity, evidence level, action. -->
 <!-- Sort by severity: critical → high → medium → low. -->
 <!-- If no findings, write "No defects found in this category." -->
+<!-- Evidence Level: observed fact / strong inference / external-behavior claim / open question.
+     Action: fix before porting / port differently / leave behind / verify at runtime.
+     Pairing rule (validated mechanically): open question or external-behavior claim ⇒
+     verify at runtime or port differently, never fix before porting; and list the finding
+     in ## Open Questions below. -->
 
 | # | Location | Defect | Severity | Evidence Level | Action |
 |---|----------|--------|----------|----------------|--------|
@@ -90,6 +95,21 @@
 
 ---
 
+## Open Questions
+
+<!-- Every finding whose Evidence Level is open question or external-behavior claim gets a row
+     here, so the hedge travels with the finding into this document — not only into the handoff.
+     Mirror each row into your phase handoff's open_questions (kind: needs-runtime-test unless a
+     maintainer decision or spec ruling is what is missing). Derived findings lists the finding
+     numbers (e.g. "1.3, 6.1") that depend on this question; none of them may carry a settled
+     action while the question stands. -->
+
+| ID | Kind | Question | Why source cannot settle it | Derived findings |
+|----|------|----------|-----------------------------|------------------|
+| | | | | |
+
+---
+
 ## Coverage and limits
 
 - Inspected scope:
@@ -110,6 +130,8 @@
 | 4 | Summary tables are complete and counts match the detailed findings. | PASS / PARTIAL / FAIL | |
 | 5 | Findings are marked with evidence levels. | PASS / PARTIAL / FAIL | |
 | 6 | Coverage and limits name inspected scope, skipped scope, evidence basis, and blind spots. | PASS / PARTIAL / FAIL | |
+| 7 | Unsettled findings (evidence level open question or external-behavior claim) carry an unsettled action (verify at runtime or port differently on pre-porting pipelines; investigate on maintenance pipelines), never a settled one, and each appears in the Open Questions table. | PASS / PARTIAL / FAIL | |
+| 8 | Every quantitative specific in a finding (size, count, default, version, timeout) cites the file and line or command output it was read from, or is marked as an estimate. | PASS / PARTIAL / FAIL | |
 
 **Validated by:** [session identifier or date]
 **Overall:** PASS / PASS WITH GAPS / FAIL

package/.codecarto/templates/reverse-engineering-bundle.md

@@ -86,7 +86,7 @@
 
 | Defect ID | Source Report | One-line Description | Severity | Disposition | Required design consequence |
 |-----------|---------------|----------------------|----------|-------------|-----------------------------|
-| | | | | fix before porting / port differently / leave behind | |
+| | | | | fix before porting / port differently / leave behind / verify at runtime | |
 
 ## Observed Facts vs. Inferred Structure
 
@@ -159,7 +159,7 @@
 | 1 | The system summary, layer map, contract table, protocol notes, and porting findings are synthesized. | PASS / PARTIAL / FAIL | |
 | 2 | Portability hazards and open questions are separated from facts. | PASS / PARTIAL / FAIL | |
 | 3 | Feature importance is sorted for porting. | PASS / PARTIAL / FAIL | |
-| 4 | Known defects are referenced in the Defect Synthesis with porting recommendations (fix before porting / port differently / leave behind), or the section explicitly notes that no defect scan ran. | PASS / PARTIAL / FAIL | |
+| 4 | Known defects are referenced in the Defect Synthesis with porting recommendations (fix before porting / port differently / leave behind / verify at runtime), or the section explicitly notes that no defect scan ran. | PASS / PARTIAL / FAIL | |
 | 5 | Findings are marked with evidence levels. | PASS / PARTIAL / FAIL | |
 | 6 | Coverage and limits name inspected scope, skipped scope, evidence basis, and blind spots. | PASS / PARTIAL / FAIL | |
 | 7 | The Source Index makes the bundle a self-contained compression boundary and identifies targeted deep-read triggers. | PASS / PARTIAL / FAIL | |

package/.codecarto/templates/semantic-defects.md

@@ -25,6 +25,12 @@
 <!-- For each finding: location, defect, evidence, severity, evidence level, action. -->
 <!-- Cite the protocol or state-machine entry that the finding violates, when relevant. -->
 <!-- If no findings, write "No defects found in this category." -->
+<!-- Evidence Level: observed fact / strong inference / external-behavior claim / open question.
+     Action: fix before porting / port differently / leave behind / verify at runtime.
+     Pairing rule (validated mechanically): open question or external-behavior claim ⇒
+     verify at runtime or port differently, never fix before porting; and list the finding
+     in ## Open Questions below. A finding that closes a routed carry-forward derived from a
+     still-open needs-runtime-test question inherits that uncertainty. -->
 
 | # | Location | Defect | Severity | Evidence Level | Action |
 |---|----------|--------|----------|----------------|--------|
@@ -45,6 +51,9 @@
 ## Pass 5: API Contract Violations
 
 <!-- Each finding should pair the source contract/protocol reference with the diverging code location. -->
+<!-- When the analyzed code is the CALLER of a contract another system implements, what that system
+     does with the payload is an external-behavior claim (action: verify at runtime) until a runtime
+     probe against the pinned version says otherwise — see passes/05 "Which side implements the contract". -->
 
 | # | Location | Defect | Severity | Evidence Level | Action | Spec Reference |
 |---|----------|--------|----------|----------------|--------|----------------|
@@ -95,6 +104,21 @@
 
 ---
 
+## Open Questions
+
+<!-- Every finding whose Evidence Level is open question or external-behavior claim gets a row
+     here, so the hedge travels with the finding into this document — not only into the handoff.
+     Include any still-open needs-runtime-test question a closed carry-forward derived from.
+     Mirror each row into your phase handoff's open_questions. Derived findings lists the finding
+     numbers (e.g. "5.2") that depend on this question; none of them may carry a settled action
+     while the question stands. -->
+
+| ID | Kind | Question | Why source cannot settle it | Derived findings |
+|----|------|----------|-----------------------------|------------------|
+| | | | | |
+
+---
+
 ## Coverage and limits
 
 - Inspected scope:
@@ -115,6 +139,8 @@
 | 4 | Findings are organized by pass and sorted by severity; summary tables match the detailed findings. | PASS / PARTIAL / FAIL | |
 | 5 | Findings are marked with evidence levels. | PASS / PARTIAL / FAIL | |
 | 6 | Coverage and limits name inspected scope, skipped scope, evidence basis, and blind spots. | PASS / PARTIAL / FAIL | |
+| 7 | Unsettled findings (evidence level open question or external-behavior claim) carry an unsettled action (verify at runtime or port differently on pre-porting pipelines; investigate on maintenance pipelines), never a settled one, and each appears in the Open Questions table. | PASS / PARTIAL / FAIL | |
+| 8 | Every quantitative specific in a finding (size, count, default, version, timeout) cites the file and line or command output it was read from, or is marked as an estimate. | PASS / PARTIAL / FAIL | |
 
 **Validated by:** [session identifier or date]
 **Overall:** PASS / PASS WITH GAPS / FAIL

package/.codecarto/{THREAD_LOG.md → templates/thread-log.md}

@@ -19,8 +19,7 @@ heredoc-vs-edit sync risks that bite append-to-large-file workflows once the fil
 
 Before appending, scan the bottom 5 entries. If you see a line with the same date AND same
 phase-or-module AND same summary, do not append — the prior session already wrote it. The
-framework has no programmatic dedup gate; this is human-discipline. (See
-`Apply 20 spec deltas to Thaumaturge.txt` for the incident that established this rule.)
+framework has no programmatic dedup gate; this is human-discipline.
 
 A one-liner to surface duplicates from the shell:
 
@@ -33,7 +32,5 @@ grep -E '^- [0-9]{4}-[0-9]{2}-[0-9]{2}' .codecarto/THREAD_LOG.md | sort | uniq -
 <!--
   Append one line per session below this marker.
   Example:
-  - 2026-05-02 — framework-feedback-pass — applied 6 spec-blockers + 5 clarifications from FEEDBACK_INDEX.md — [closeout](closeouts/2026-05-02-framework-feedback-pass.md)
+  - 2026-03-14 — architecture — mapped 14 packages across 3 layers; wire formats deferred to protocols — [closeout](closeouts/2026-03-14-architecture.md)
 -->
-
-- 2026-05-02 — framework-feedback-pass — applied 6 spec-blockers + 5 clarifications from FEEDBACK_INDEX.md; 14 deferred to BACKLOG.md — [closeout](closeouts/2026-05-02-framework-feedback-pass.md)

package/.codecarto/workflow/VALIDATE.md

@@ -50,7 +50,7 @@ Below is what a real PASS WITH GAPS block looks like — useful when a phase fin
 | 2 | The layer map and dependency direction are documented. | PASS | §Layer Map; dependency direction in §Layer Map → "Dependency Direction." |
 | 3 | Public surfaces are identified. | PARTIAL | CLI commands and HTTP routes enumerated (§Public Surfaces). MCP server endpoints and the websocket subscription channel are listed by name only — schemas not extracted. Routed to `carry_forward` as `arch-CF2` with `target_phase: protocols`. |
 | 4 | Runtime lifecycle, concurrency model, and porting priorities are summarized. | PASS | §Runtime Lifecycle, §Concurrency Model, §Porting Priorities (table). |
-| 5 | Findings are marked with evidence levels. | PASS | All inferences marked `observed fact` / `strong inference` / `portability hazard` / `open question`. |
+| 5 | Findings are marked with evidence levels. | PASS | All inferences marked `observed fact` / `strong inference` / `portability hazard` / `external-behavior claim` / `open question`. |
 
 **Validated by:** 2026-05-02 (architecture phase, session 1)
 **Overall:** PASS WITH GAPS

package/.codecarto/workflow/pipeline-defect-scan.yaml

@@ -56,6 +56,8 @@ phases:
       - Findings are organized by pass and sorted by severity.
       - Summary tables are complete and counts match the detailed findings.
       - Findings are marked with evidence levels.
+      - Unsettled findings (evidence level open question or external-behavior claim) carry an unsettled action (verify at runtime or port differently on pre-porting pipelines; investigate on maintenance pipelines), never a settled one, and each appears in the Open Questions table.
+      - Every quantitative specific in a finding (size, count, default, version, timeout) cites the file and line or command output it was read from, or is marked as an estimate.
       - Coverage and limits name inspected scope, skipped scope, evidence basis, and blind spots.
     handoff_requirements:
       - Run validation per workflow/VALIDATE.md. Append validation block to primary output.

package/.codecarto/workflow/pipeline-full-with-audit.yaml

@@ -60,6 +60,8 @@ phases:
       - Findings are organized by pass and sorted by severity.
       - Summary tables are complete and counts match the detailed findings.
       - Findings are marked with evidence levels.
+      - Unsettled findings (evidence level open question or external-behavior claim) carry an unsettled action (verify at runtime or port differently on pre-porting pipelines; investigate on maintenance pipelines), never a settled one, and each appears in the Open Questions table.
+      - Every quantitative specific in a finding (size, count, default, version, timeout) cites the file and line or command output it was read from, or is marked as an estimate.
       - Coverage and limits name inspected scope, skipped scope, evidence basis, and blind spots.
     handoff_requirements:
       - Run validation per workflow/VALIDATE.md. Append validation block to primary output.
@@ -159,7 +161,7 @@ phases:
       - The system summary, layer map, contract table, protocol notes, and porting findings are synthesized.
       - Portability hazards and open questions are separated from facts.
       - Feature importance is sorted for porting.
-      - Known defects are referenced with porting recommendations (fix before porting / port differently / leave behind).
+      - Known defects are referenced with porting recommendations (fix before porting / port differently / leave behind / verify at runtime).
       - Findings are marked with evidence levels.
       - Coverage and limits name inspected scope, skipped scope, evidence basis, and blind spots.
       - The Source Index makes the bundle a self-contained compression boundary and identifies targeted deep-read triggers.

package/.codecarto/workflow/pipeline-full-with-deep-audit.yaml

@@ -62,6 +62,8 @@ phases:
       - Summary tables are complete and counts match the detailed findings.
       - Items spotted that are actually semantic in nature are routed onward via a carry_forward entry in the phase handoff targeting defect-scan-semantic.
       - Findings are marked with evidence levels.
+      - Unsettled findings (evidence level open question or external-behavior claim) carry an unsettled action (verify at runtime or port differently on pre-porting pipelines; investigate on maintenance pipelines), never a settled one, and each appears in the Open Questions table.
+      - Every quantitative specific in a finding (size, count, default, version, timeout) cites the file and line or command output it was read from, or is marked as an estimate.
       - Coverage and limits name inspected scope, skipped scope, evidence basis, and blind spots.
     handoff_requirements:
       - Run validation per workflow/VALIDATE.md. Append validation block to primary output.
@@ -157,6 +159,8 @@ phases:
       - Findings are organized by pass and sorted by severity; summary tables match the detailed findings.
       - Any carry_forward entries that targeted defect-scan-semantic have been resolved or explicitly re-routed.
       - Findings are marked with evidence levels.
+      - Unsettled findings (evidence level open question or external-behavior claim) carry an unsettled action (verify at runtime or port differently on pre-porting pipelines; investigate on maintenance pipelines), never a settled one, and each appears in the Open Questions table.
+      - Every quantitative specific in a finding (size, count, default, version, timeout) cites the file and line or command output it was read from, or is marked as an estimate.
       - Coverage and limits name inspected scope, skipped scope, evidence basis, and blind spots.
     handoff_requirements:
       - Run validation per workflow/VALIDATE.md. Append validation block to primary output.
@@ -196,7 +200,7 @@ phases:
       - The system summary, layer map, contract table, protocol notes, and porting findings are synthesized.
       - Portability hazards and open questions are separated from facts.
       - Feature importance is sorted for porting.
-      - Defect Synthesis consolidates mechanical-defects.md and semantic-defects.md with porting recommendations (fix before porting / port differently / leave behind).
+      - Defect Synthesis consolidates mechanical-defects.md and semantic-defects.md with porting recommendations (fix before porting / port differently / leave behind / verify at runtime).
       - Findings are marked with evidence levels.
       - Coverage and limits name inspected scope, skipped scope, evidence basis, and blind spots.
       - The Source Index makes the bundle a self-contained compression boundary and identifies targeted deep-read triggers.