broadside

Broad-Side

Broad-Side is CodeCartographer's batch reconnaissance pass. It fires six analysis lenses — architecture, API surface, security, mechanical defect scan, convention extraction, and porting — at the repository as single-turn prompts over the OpenRouter Batch API (~50% of sync pricing, asynchronous, unattended), then synthesizes one cross-lens report. Results live under .codecarto/broadside/<run>/ alongside this file.

What Broad-Side findings are — and are not

Broad-Side findings are unverified scouting signals, not validated claims. Every lens is one shot: no cross-file traversal, no runtime verification, no builds, no tests, no follow-up questions. The batch model is cheap, not strong. Treat every finding as a lead with a file:line pointer that the interactive pipeline — or you — must confirm before it is a fact.

This is the division of labor: Broad-Side is cheap enough to run on any repo to decide where the expensive interactive run should spend its attention. It does not replace any phase; it tells phases where to look.

Reading a Broad-Side run

1. If verified.md exists, read it first. A verification pass (codecarto_broadside {action: "verify"}, /codecarto-broadside verify) has read the top defect and security findings against the real source with read-only tools and given each a verdict: confirmed (a reachable failure, with the input or call site that triggers it), not-a-defect (the claim is literally true of the code but nothing can reach the failure it describes), discarded (the claim is wrong about the code, with the guard or line that shows it), or unclear. Start from the confirmed ones; treat a discarded one as answered unless the reasoning is thin. Then make sure the work order was built from it: status shows triage: completed (built from N verdicts); if it says (no verdicts), run collect --regenerate (regenerate_post_passes: true) before reading triage.md. Measured on this repository, the top twelve findings by severity were two real defects and ten that a look at the guard, the caller, or the tsconfig dismissed — the pass agreed with a reviewer on all twelve for about a cent a finding. A confirmed verdict is still a model's reading: a strong lead for a human's next look, not a validated claim.
2. Read synthesis.md. It carries the executive summary, severity counts, the top cross-lens findings, and per-module risk levels.
3. Read triage.md for the work order: each lead scored by impact × difficulty with a P0–P3 priority and an effort estimate. It is a starting point for re-verification, not a commitment — every item still needs confirmation against the source before work begins.
4. Read the per-lens files behind anything that matters to your current phase:
   • architecture-*.json → the architecture phase's seed of prior knowledge
   • api-*.json → endpoints and data types (contracts/protocols phases)
   • security-*.json → auth, trust boundaries (defect-scan-semantic pass 5)
   • defect-*.json → mechanical defect leads (defect-scan-mechanical). The scan is asked to name the input, call site, or sequence that reaches each failure, and to file a cast, assertion, or style observation that every caller satisfies at severity low under the pattern type-hygiene — read those as notes, not defects.
   • conventions-*.json → naming/idiom candidates for CONVENTIONS.md
   • porting-*.json → platform coupling (porting phase)
5. run-meta.json records scope: which lenses ran, at what cost, with what coverage caps.