# Extraction slice prompt — Argus extraction contract v1, RED oracles before code *Written 2026-09-07 for a fresh agent session, after the extraction specification was accepted by both independent reviewers (revision 8, head `601edf8`, `docs/apollo-argus-extraction-v1-spec.md`; record `docs/apollo-argus-extraction-v1-spec-review.md`, eight rounds, sixteen reports verbatim) and the owner ruled the 26 open questions "Accept all 26 recommendations" (D-EX-4 in the spec, 01:25 UTC). Hand the fenced block to the agent; everything above it is context for the owner.* Why the RED phase is its own session: the Slice 1 and Slice 2 discipline (spec → RED oracles → RED evidence → code → GREEN evidence → independent checkpoint review) is what caught the design errors in the spec rounds — eight of them for this spec. The RED phase is the first code of Phase 2 Processing; it must start with a clean context, the accepted spec as the only authority, and the evidence files written before and after. Nothing in it touches production, the Claude CLI on a document, or the invoice-skill-build repository. --- ## The prompt ```text You are working in D:\fileStorage\repos\GOTT.Apollo (Windows Server 2025, .NET SDK 10, PowerShell 5.1). Read these first, in this order, and treat them as the authority: 1. docs/apollo-argus-extraction-v1-spec.md — the specification, revision 8, ACCEPTED by both reviewers at head 601edf8; §1.1 carries the owner's rulings D-EX-1..4 (D-EX-4 = all 26 recommendations of §1.2 accepted); §2 the contract sibyla.extract.v2 and the Split function; §4 the package, worker and seams; §5 the scoring; §7 the oracle list; §8 the checkpoints. 2. docs/apollo-argus-extraction-v1-spec-review.md — the review record: the closing verdict of round 8 lists eight residual findings (C-X-1, C-X-2..4, F-X-1..4) carried into this slice as a revision-9 amendment. 3. docs/apollo-deployment-run-260903.md §7o and §7p — how production is deployed now (the module, one release id for web+api+worker, the owner at the console). 4. docs/apollo-discovery-and-plan-260826.md — the plan; entries of 2026-09-05..07 for this slice. Inputs that already exist (read-only unless the spec says otherwise): - The 40 answer keys, INDEX.md and _sql/ at D:\fileStorage\tmp\apollo-extraction\answer-keys\ (§5.2): copy them unchanged into tests/Sibyla.Tests.Argus/golden/extract-v2/answer-keys/ (Q-EX-8). - The sample set D:\fileStorage\tmp\apollo-e2\sample\sample-set.csv (§5.1) and the sample PDFs at the pinned commit a558523f3f0ad97e6c3f60707d635b3d257d3392 of D:\fileStorage\repos\invoice-skill-build (§4.1; never modify that repository; `git -C D:\fileStorage\repos\invoice-skill-build status --porcelain` must stay empty — the bench copies files into its own sandbox, §4.3/§5.7). - The pinned CLI C:\Apps\Sibyla\tools\claude\claude.exe, 2.1.259 — `--version` and `--help` only in this phase; it is never run on a document here (R-EX-2 and R-EX-3 are the owner's sittings, §8). Branch: create ops/argus-extraction-v1-red from main; push it; every commit carries the trailers Co-Authored-By: Claude Fable 5.1 Claude-Session: Order of work — stop at each "STOP" line and report: R0. Revision-9 amendment of the spec (docs only): apply the eight carried residuals exactly as the closing verdict of round 8 states them (V-9's VAT clause for the branch-(2) shape and fixture (2)'s line VAT; the V-8 second-shape label; the reject case's null reconciliation_note; the reject file lives in the Platform rejection corpus; fixture (3) is Split-level; `const bool StreamJsonNeedsVerbose` on ClaudeCliProcess, false at RED; the sibling-release root is the parent of the release directory). Append "### Author's dispositions — revision 9 (build slice)" to the review record with one row per finding. Commit. No other spec change without a new review round. R1. Test data (no test code yet): the 40 keys copied; answer-key.meta.json (the sync run id, §5.2); answer-key.flags.json (dateDuePrinted, printsIssuer/RecipientTaxId, printsOpening/Closing/RunningBalance with the hand-keyed printedOpeningBalance/printedClosingBalance and page refs, printOrder, hasTransactionDateColumn, placeholders — the two document ids and two fiscal ids of N-7); answer-key.corrections.csv (the four header cells of §5.5, the 18 movement descriptions, #31's lines); reserve-set.csv (the ten of §5.6 with their doclog codes). Every value derived from the PDFs and the keys as the spec states, with the page reference in the file. Commit. R2. The RED oracles of §7, one commit per row, in this order: the six goldens and the rejection corpus (ExtractionContractV2Tests), SkillPackageTests, ProcessingEvidenceTests + WorkerStartupTests, ExtractionResultIdentityTests + QueueWorkerGateTests, DocumentsReviewV2Tests + IngestionServiceHoldTests, ClaudeCliTimeoutTests, ClaudeCliPermissionTests, ExtractionScoringTests (S-1..S-11 with the synthetic fixtures and the guard fixture), EvidenceSecretScanTests, CompanyMatcherTests, AccountPeriodTests. Each test names its expected value from the spec; each fails because the code it names does not exist. A behaviour test that passes on its first run is a HARD STOP: report it, do not "fix" the test. R3. RED evidence: run local\test.ps1; append the failing run (counts per project, the new tests' names and failure reasons) to tests/Sibyla.Tests.Argus/evidence/extract-v2/RED-red.txt, then the fingerprint of a clean export (`git archive` of the RED commit to a fresh timestamped folder under D:\fileStorage\tmp, then local\deploy\tests\Sibyla.Deployment.Tests\evidence\New-EvidenceFingerprint.ps1 -WorktreeRoot on it — CRLF on this machine, never on the working tree). Commit. STOP and report the RED head. G1. GREEN, contract side: ExtractionContractV2 (the validator, V-1..V-19), Split (§2.6) and the derived fields, the scorer (S-1..S-11), tools/skill-package (Build-SkillPackage.ps1 → the committed package under src/Sibyla.Worker.Documents/skill/ with manifest.json; EXTRACT.md per §4.2), the csproj lines of §4.6. Only the tests of R2 that these make GREEN may turn green; record which in RED-green.txt. STOP. G2. GREEN, worker side: ExtractionRunner, the §4.3 seams (BuildArguments, PermissionsFile.Build, JobCompletion.CompleteAsync, TimeoutLaneMonitor.Record, CompanyGate.ApplyAsync), WorkerOptions keys (CliVersion, Model, Effort, StartupCheckSeconds, package hash), the start-up checks, the attempt table, evidence//, ProcessingEvidence.JobId, the Hold outcome, the re-extract key. STOP. G3. GREEN, web and schema: the migration (docint.hold_reason; IntakeProcessingStatus.HeldForPerson = 9), the v2-aware review page, the hold transitions, ReleaseHeldProcessing, the re-extract action. local\test.ps1 fully green; RED-green.txt completed; a second clean-export fingerprint. STOP. Then the owner's sittings (R-EX-2 hostile run under the production flag set; R-EX-3 bench, three sittings) and the independent checkpoint review by two fresh reviewers over the whole record (§8) — merge only if both ACCEPT. Hard rules (unchanged from every earlier slice): - Never read local\secrets, any *secrets*.json, or D:\ApolloData\worker-claude; never query production databases; never start, stop or deploy anything; never touch Sibyla.Legacy.*, gott_sibyla_legacy, win-acme, the Hermes configuration or crons; never modify D:\fileStorage\repos\invoice-skill-build. - Temp files under D:\fileStorage\tmp or the session scratchpad; no -Force; no perl -pi; no `git worktree` merges from inside a worktree; evidence files are appended, never rewritten. - The accepted spec is the only authority: a rule you would change is a review finding, not an edit. ``` ## For the owner - Start it as a new Claude Code session in `D:\fileStorage\repos\GOTT.Apollo` and paste the fenced block. The session's memory carries the pointers (`argus-extraction-v1`, `sibyla-production-deployment`). - The RED and GREEN phases change nothing on the host. Two items need you before the slice can close: the purge of the existing CLI transcripts under `D:\ApolloData\worker-claude\projects` (Q-EX-22, your action on the host, any time from now) and the sittings of §8 (R-EX-2 under the production flag set, R-EX-3's three bench sittings under your own login and the pinned binary). - The v2 release itself goes out afterwards through the module as one release id for web, api and worker (§4.6), with `local\migrate.ps1` first — the same launcher line pattern as section 7p.