# Sub-slice A2 prompt — Sibyla.Deployment Slice 2, RED oracles before code

*Written 2026-09-03 for a fresh agent session, after the Slice 2 specification was accepted by
both independent reviewers (revision 10, `docs/apollo-deployment-slice2-spec.md`; record
`docs/apollo-deployment-slice2-spec-review.md`). Hand the fenced block to the agent; everything
above it is context for the owner.*

Why A2 is its own session: the Slice 1 discipline (spec → RED oracles → RED evidence → code →
GREEN evidence → independent checkpoint review) is what caught the design errors of the spec
rounds. A2 is the first code of Slice 2 and the first change to the Slice 1 module since it was
merged; it must be done with a clean context, the accepted spec as the only authority, and the
evidence files written before and after.

---

## 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-slice1-v3-spec.md         — Slice 1 (the planning-only module on main)
  4. local/deploy/                                    — the Slice 1 module: src/, tests/ (oracles/, probes/, evidence/)
  5. docs/apollo-deployment-run-260903.md             — how production is deployed today (the hand path)

GOAL
Deliver sub-slice A2 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. Nothing executes against the host in A2;
no -Execute exists yet in a usable form (the switch is added and refused/deferred per D-S2-6).

SCOPE OF A2 (spec section 9, row A2; sections 0.2, 3, 4, 5.1, 5.5, 8)
  a. The single Core change: SafeScmName.MandatedWorkerServiceName = "Sibyla.Worker.Documents",
     with the enumerated side edits (the three .ps1 defaults, tests/Infrastructure/ValidRequests.cs)
     and the S1 oracle amendments listed in spec section 0.2: validators.json SCM rows,
     entrypoints.json (default, positive sentinel, the S2 parameter lists), forbidden.json
     (Cmdlets' allowedAssemblyReferences + sourceBans scope). parameters.json untouched.
  b. New assembly src/Sibyla.Deployment.Execution (net48;net10.0, LangVersion 13.0, S1 transferability
     rule): the V2 contracts and planning types of section 3, the value objects of section 4
     (ServiceNameV2, TransactionId, HostOverride, ExpectedStatus, mediatype, DocsPath rules, the
     site/pool name rules, EnvironmentAssignment internal), CapabilityPreflightV2 with the three modes,
     HandlerTableV2.CreateProduction() with the 38 descriptors of section 5.1 (descriptors and request
     types only — no adapter, no executing invoker; those are B2/C2), DeploymentFailureV2 /
     ErrorBoundaryV2 / FailureCodesV2 / KnownParameterNamesV2 / KnownOperationNamesV2 (section 8),
     the -Execute / -Force / -NoRollbackOnHealth / -ChecksOnly / -Resume / -JournalRoot switches and
     parameters on the six cmdlets and .ps1 entry points per section 4 and the D-S2-6 truth table
     (without -Execute everything stays byte-for-byte S1; with -Execute the one-shot goes down the
     V2 pipeline up to preflight and then, in A2, answers SIBYLA-S2-EXECUTION-REFUSED because no
     executing invoker exists yet — state that in the evidence).
  c. Sibyla.Api: GET /health/schema (anonymous; role + applied migration ids) with one contract test
     in tests/Sibyla.Tests.Api and a C-row in docs/apollo-channel-intake-api-spec.md (spec 5.5).
  d. Scripts: local/publish-release.ps1 writes requiredMigrations into release.json;
     local/deploy-release.ps1 copies it into MANIFEST.json (spec 2, 5.4). Do NOT run them against
     production; test them on a throwaway staging folder under the scratchpad.
  e. Oracles typed BEFORE any of the above (the RED step): validators.json and entrypoints.json
     amendments, forbidden.json amendment, forbidden.v2.json, sanitizer.v2.json, and the A2 part of
     registry.v2.json (the 38 descriptors' names, adapter/action, kind, result type, elevation and
     ordered argument names/families — an independent author types this from spec 5.1 alone, so
     write it from the spec text, never from code you have started).

PROCEDURE (Slice 1 section 9, unchanged)
  1. Branch ops/sibyla-deployment-slice2-a2 from main; use a git worktree under
     D:\fileStorage\repos\GOTT.Apollo-worktrees\ if you prefer (the DB suites need local\secrets — a
     junction to the main checkout's local\secrets, never a copy).
  2. Type the oracles (e) and the tests that read them. Run the suite: the new tests must FAIL and the
     S1 suite (585 tests, dotnet test local\deploy\tests\Sibyla.Deployment.Tests, ~70 s) must show
     exactly the failures the enumerated S1 amendments predict. Save
     local/deploy/tests/Sibyla.Deployment.Tests/evidence/A2-red.txt with the framed SHA-256 over the
     oracle files, the test files and local/deploy/src/** at that moment. A behaviour test that passes
     on its first run is a HARD STOP: stop and report.
  3. Implement (a)–(d) until green. Save evidence/A2-green.txt the same way. Run the Api suite
     (tests/Sibyla.Tests.Api, 45 + the new test) and the full local\test.ps1 once.
  4. Commit on the branch in small steps with the repo's commit conventions; push the branch. Do not
     merge: the next step is the independent checkpoint review after B2.
  5. Record: a dated entry in docs/apollo-discovery-and-plan-260826.md (newest at the end of the
     Phase 1 section, after the 2026-09-03 entries), the A2 row of the spec's section 9 marked with
     the evidence fingerprints, and memory.

HARD CONSTRAINTS
  - The spec is the authority. If code cannot be made to match the spec, stop and report the exact
    section; do not "fix" the spec silently (a spec change goes back to the reviewers).
  - Never touch the production sites, pools, service, secrets root, key ring, Hermes configuration,
    win-acme, the legacy sites or GottSibylaWorker. Never read local\secrets contents or
    C:\ProgramData\Sibyla\secrets contents. No -Execute run of any kind.
  - Never add NoteProperty members to contracts; no records/init/required; no #if; Core keeps its
    byte-level forbidden scan green apart from the enumerated amendments.
  - Evidence files are appended, never rewritten; the S1 evidence files are never edited.

REPORT
  A short written record: the RED fingerprint and the failing tests it covered, the GREEN
  fingerprint and the counts (S1 585, Execution new tests, Api), the S1 oracle rows you amended
  (file, row, before → after), anything in the spec that did not survive contact with the code,
  and what B2 needs from A2's types.
```

---

## 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 already carries the pointers (`apollo-deployment-slice1-effort`,
  `sibyla-production-deployment`).
- A2 changes nothing on the host. The API's new `/health/schema` endpoint reaches production only
  through the hand path (`local\publish-release.ps1` / `deploy-release.ps1 -Hosts api`) at a time
  you choose, before D2.
- After A2 comes B2 (the executing invoker against fake adapters, net10 xUnit), then the
  independent checkpoint review A2+B2 with the two reviewers of the spec rounds.