# Sub-slice B2 prompt — Sibyla.Deployment Slice 2, the executing invoker (RED oracles before code)

*Written 2026-09-03 after sub-slice A2 was delivered on `ops/sibyla-deployment-slice2-a2`
(`docs/apollo-deployment-slice2-a2-prompt-260903.md`; evidence `A2-red.txt` / `A2-green.txt`) and
the naming-shift Phase D renamed the databases and roles (`docs/apollo-naming-shift-phase-d-260903.md`).
Hand the fenced block to a fresh agent session; everything above it is context for the owner.*

Why B2 is its own session: it is the first code that can execute anything. It must be written
against the accepted spec and A2's evidence with a clean context, its oracles typed before code by
an author who has not read A2's implementation of the same rows, and its RED and GREEN evidence
recorded before the independent checkpoint review A2+B2.

---

## The prompt

```text
You are working in D:\fileStorage\repos\GOTT.Apollo (Windows Server 2025, .NET SDK 10, PowerShell 5.1
for the module probes). Read these first, in this order, and treat them as the authority:

  1. docs/apollo-deployment-slice2-spec.md            — Slice 2 specification, revision 10, ACCEPTED
  2. docs/apollo-deployment-slice2-spec-review.md     — nine review rounds; every adjudication
  3. docs/apollo-deployment-slice2-a2-prompt-260903.md — what A2 delivered and how (scope, procedure)
  4. local/deploy/                                    — the module on branch ops/sibyla-deployment-slice2-a2:
                                                        src/Sibyla.Deployment.{Core,Execution,Cmdlets}, tests/ (oracles/, probes/, evidence/)
  5. local/deploy/tests/Sibyla.Deployment.Tests/evidence/A2-green.txt — the A2 state (fingerprint a4935d62…)
  6. docs/apollo-deployment-run-260903.md             — how production is deployed today (the hand path)
  7. docs/apollo-naming-shift-phase-d-260903.md       — the databases are gott_sibyla / gott_sibyla_preview,
                                                        the roles sibyla_*, the repository secrets file local\secrets\sibyla-db.json

GOAL
Deliver sub-slice B2 of Slice 2 exactly as the spec's section 9 defines it, RED oracles before code,
with the evidence files the Slice 1 discipline requires. B2 makes the V2 pipeline execute against
FAKE adapters in net10 xUnit only. No real adapter exists (C2); no -Execute run reaches a host.

SCOPE OF B2 (spec section 9, row B2; sections 3, 5.1, 5.2, 5.3, 5.6, 5.7, 6, 7, 8)
  a. The executing invoker and the read-only configuration SibylaReadOnlyCommandInvokerV2
     (CanExecuteMutations = false, used by -ChecksOnly), with the 5.3 semantics: one intent at a
     time in plan order, Started journaled and fsynced before the adapter call, typed refusals
     (Satisfied/Matches/Acquired = false) turned into Failed with the key's code, ADAPTER-FAILED,
     ADAPTER-TIMEOUT as a cancellation deadline (300 s, drain-time bounded, never a concurrent
     compensation), REDACTION, INVOKER-RESULT (receipt type = ExpectedResultType), Skipped
     NotReached/NotNeeded, DependsOn, the fixed entries and their GuardIntentId rule, CompensationFailed,
     RolledBack vs RollbackIncomplete, -NoRollbackOnHealth, the lowest-numbered HEALTH-n rule.
  b. DeploymentPlanCompilerV2 (per phase, release-agnostic, section 5.7): the 5.2 phase table for
     the three sites and the service, the derived compensation entries and the four fixed entries,
     the ChecksOnly plan, PlanLineageValidatorV2 over the plans of the contracts actually received,
     one plan digest per phase (section 6's digest definition).
  c. The adapter interfaces (one per adapter family of 5.1) that C2 implements, and the fake adapters
     of the test project that B2 exercises them with.
  d. The journal (Execution/Journal/, the only folder allowed System.IO; the hand-rolled JSON
     reader/writer under Execution/Json/) and -Resume per section 6: recompile phase by phase from
     the journaled receipts, digest match, the mutex bracket, the adapter-rule comparison, the
     trailer cases, the completed-deployment predicate, RollbackIncomplete retries.
  e. Redaction.Render (section 8): the allowed set, the per-leaf 512 cap, lossless \uXXXX receipt
     rendering with the decoder, the secret-value patterns; the B2 literal test over every section 2
     literal plus a 50-release host-folder snapshot and a 14-ACE set (decode(render(x)) == x).
  f. The V2 phases, provider, DeploymentOrchestratorV2 and DeploymentRuntimeV2 that replace A2's
     placeholders (DeploymentOrchestratorV2.Run and DeploymentRuntimeV2.CreateProduction refuse
     everything today): -Execute -WhatIf previews through SibylaPlanOnlyCommandInvokerV2 with every
     release-derived argument rendered as its ref; -Execute and -Execute -Resume run the executing
     invoker; -Execute -ChecksOnly the read-only one. The twelve HealthCheckV2 of section 7 with
     the Http-before-pool-readback order. The A2 truth-table rows marked a2Refused in
     oracles/entrypoints.json get their final outcomes (the executing paths still cannot reach a
     host without C2's adapters: the production runtime wires NO real adapter, so an -Execute
     outside the test project fails closed at the first adapter call with ADAPTER-FAILED — state
     that in the evidence and in the oracle rows).
  g. Oracles typed BEFORE any of the above (the RED step): the B2 part of registry.v2.json (only if a
     row of A2's part proves wrong against 5.1: record, never silently edit), execution-order.json
     (the 5.2 forward and compensation sequences per phase incl. ChecksOnly, the four fixed entries
     and their guards), execution-semantics.json (the 5.3 rules as cases with expected dispositions,
     codes, outcomes and journal lines), health.v2.json (the twelve checks, their feeding intents,
     expectations and codes). An independent author types execution-order.json from 5.2 alone.

PROCEDURE (Slice 1 section 9, unchanged)
  1. Branch ops/sibyla-deployment-slice2-b2 from ops/sibyla-deployment-slice2-a2; git worktree under
     D:\fileStorage\repos\GOTT.Apollo-worktrees\ with a junction to the main checkout's local\secrets
     (never a copy). The A2 branch stays as it is.
  2. Type the oracles (g) and the tests that read them. Run the suite: the new tests must FAIL and the
     A2+S1 suite (1036 tests) must stay green except where B2's oracle rows replace A2's a2Refused
     rows (enumerate them). Save evidence/B2-red.txt with the framed SHA-256. A behaviour test that
     passes on its first run is a HARD STOP.
  3. Implement (a)–(f) until green. Save evidence/B2-green.txt. Run the Api suite and local\test.ps1 once.
  4. Commit in small steps; push the branch. Do not merge: the independent checkpoint review A2+B2 follows.
  5. Record: a dated entry in docs/apollo-discovery-and-plan-260826.md, the B2 row of the spec's section 9
     with the evidence fingerprints, and memory.

HARD CONSTRAINTS
  - The spec is the authority. If code cannot be made to match it, stop and report the section; never
    fix the spec silently. Same for an A2 type that proves wrong: record the change in the evidence.
  - No real adapter, no Adapters.Windows project, nothing that touches IIS, SCM, ACLs, TLS, processes,
    the network or the production sites; System.IO only under Execution/Journal/ (forbidden.v2.json).
  - Never read local\secrets or C:\ProgramData\Sibyla\secrets contents. No -Execute run against a host.
  - Never add NoteProperty members; no records/init/required; no #if; the forbidden.v2.json member
    names stay absent (Held, Committed, Released, Verified, Active, Completed, Complete, …).
  - Evidence files are appended, never rewritten; the S1 and A2 evidence files are never edited.

REPORT
  The RED fingerprint and the failing tests it covered; the GREEN fingerprint and the counts (S1 585,
  A2, B2, Api); every A2 type or oracle row changed and why; anything in the spec that did not survive
  contact with the code; what C2 needs from the adapter interfaces.
```

---

## For the owner

- Start it as a new Claude Code session in `D:\fileStorage\repos\GOTT.Apollo` and paste the fenced
  block. Memory already carries `apollo-deployment-slice2-a2` and `apollo-naming-shift`.
- B2 changes nothing on the host. After B2 comes the independent checkpoint review A2+B2 with the
  two reviewers of the spec rounds, then the hand-path deploy of the A2 API (`/health/schema`),
  then C2/D2 and E2.
