# Sibyla whole-project status map

**Current continuation (2026-09-09):** [legacy application retirement](legacy-retirement-260909.md)
completed with postchecks at 12:26 UTC under [reuse protection](legacy-reuse-protection-260909.md);
the legacy database and live shared components are retained. The [Stage 19 native matching checkpoint](stage19-native-matching-260909.md)
now implements receipt-date/FIFO and exact payment/receipt review proposals with priority and ambiguity guards. Other source
match shapes remain unimplemented; the checkpoint is not full matcher parity. See [post-rename verification and regression fixes](post-rename-check-260909.md),
the [persistence slice contract](argus-persistence-slice-260909.md), and the
[invoice skill Stage 19 gap review](invoice-skill-build-gap-review-260909.md). The September 4 snapshot
below remains historical; later decisions and deployment records supersede its open-item status.

**Evidence snapshot:** 2026-09-04 · `main` at `b239d7e` · E2 preparation branch at `09fc531`
· Sibyla is the operational application on the production host · the Claude AI Projects harness is
merged · the channel-intake cutover is complete and its legacy cron/worker have been retired ·
several external proofs, the FDR authority cutover, and formal acceptance gates remain open.

This page is a navigation aid, not a new plan. The linked specifications and decision records remain
the authority. A green implementation box means that code/evidence is present; it does not silently
turn an unrecorded owner acceptance criterion into an approved decision.

## Whole project at a glance

```mermaid
flowchart LR
    DISC["Discovery and architecture<br/><b>DELIVERED</b><br/>register needs consolidation"]
    CORE["Platform core<br/><b>DELIVERED</b><br/>identity · tenancy · licences · RLS"]
    INTAKE["Document intake<br/><b>LIVE / PARTIAL</b><br/>web + API + queues"]
    PROC["Processing<br/><b>DELIVERED</b><br/>worker · Claude · governed rules"]
    ARGUS["Argus workflows<br/><b>DELIVERED</b><br/>review · quality · audit · UI"]
    ERP["ERP integration<br/><b>PARTIAL</b><br/>engine proven; live pushes missing"]
    OPS["Production and operations<br/><b>IN PROGRESS</b><br/>live; hardening + FDR cutover remain"]

    DISC --> CORE --> INTAKE --> PROC --> ARGUS --> ERP --> OPS

    STORAGE["Storage<br/><b>PARTIAL</b><br/>Nextcloud path built<br/>other providers later"]
    HARNESS["AI Projects harness<br/><b>PARTIAL</b><br/>Codex + Claude merged<br/>Hermes unavailable"]
    SYNC["Legacy/FDR sync<br/><b>NEEDS ALIGNMENT</b><br/>master data remains<br/>document carry-over withdrawn"]
    CHANNEL["Channel-intake cutover<br/><b>DELIVERED / LIVE</b><br/>API · plugin · email watcher<br/>legacy intake retired"]

    STORAGE --> INTAKE
    HARNESS --> CORE
    SYNC --> ARGUS
    CHANNEL --> INTAKE

    classDef done fill:#d9f7e7,stroke:#147a4b,color:#123b2a;
    classDef partial fill:#fff3cd,stroke:#9a6700,color:#4d3600;
    classDef wait fill:#fde2e2,stroke:#b42318,color:#5a1712;
    class DISC,CORE,PROC,ARGUS,CHANNEL done;
    class INTAKE,ERP,OPS,STORAGE,HARNESS partial;
    class SYNC wait;
```

## Workstream status

| Workstream | Status | What exists now | Important missing or unresolved work |
|---|---|---|---|
| Discovery, architecture, decisions | Delivered / needs consolidation | 15-part dossier, risks, diagrams, global decisions, specialist decision registers | Merge later rulings into one current register; the original D-01…D-70 queue and some acceptance text are now historical or superseded |
| Platform foundation | Delivered | .NET 10 modular platform, IdentityServer sign-in, owner/company context, licences/modules, user grants, PostgreSQL forced RLS, fail-closed tests | Formal Phase 1 exit sign-off against the current—not original—scope |
| Argus data model and governed rules | Delivered | FDR-shaped schema, declaration tables, account-period ladder, precedence, hammered-line protection, master-data consistency, learning gate, flags and event ledgers | Reconfirm which legacy-derived tables remain relevant after the no-document-carry-over ruling |
| Legacy/FDR synchronization | Technically delivered, plan misaligned | Full historical sync engine, reconciliation gates, idempotency and workbook witness | D10 was amended: only master data should carry over. Document/bank/control sync waves and their cutover criteria still need retirement or an explicit new ruling |
| Web intake and processing | Mostly delivered | Upload, duplicate control, hostile-document gate, company triage, durable queues, worker, Claude extraction contract/evidence | Automatic hand-off from a successfully processed intake row into the Argus document tables is explicitly not built |
| Argus UI and administration | Delivered | UI-0…UI-5, documents, processing, review, quality, audit, integration, reconciliation, management and governed administration screens | Validate complete real-document journeys after the missing intake→Argus hand-off lands; accessibility/responsive Phase 3 regression remains |
| Channel-intake API and Apollo plugin | Live / cutover complete | Production API, least-privilege client, sender bindings, Apollo plugin and live email watcher; the plugin's trusted-envelope hook and gateway-owned LID→E.164 alias bridge made WhatsApp sender verification work; all four observation legs passed; duplicate-control correction released on all hosts; legacy API intake, plugin, IdP client/resource and email cron retired | D-CI-10 final review with the evidence record and the explicitly deferred test debt remain; these are assurance work, not an open traffic cutover |
| ERP integration | Logic delivered / external proof missing | iziBizi connection and fiscal-year session, `FindExisting`, ERPLDG state machine, preflight, retries and scripted-provider proof | Owner-authorized real iziBizi document commit; ROSE test subscription and flow; Primavera v10 installation; live exactly-once demonstrations |
| Storage | Partial | Provider abstraction, encrypted credentials, Nextcloud WebDAV transfer path, retry/parking semantics | Record a fresh real production transfer if not already evidenced; OneDrive and Google Drive remain disabled stretch providers |
| AI Projects / development harness | Partial companion initiative | Administrator project/session/chat UI, durable runs, Codex and Claude harnesses, worktrees, tests and preview gateway; Claude is merged on `main` with fixture-backed streaming/resume coverage and a live CLI probe | Hermes harness is unavailable; per-licence gateway/config seam, production run identity and retention/deletion hardening remain |
| Production, naming and deployment | Operational / not formally closed | Platform renamed to Sibyla, module to Argus, agent to Apollo; production web/API/docs/worker live; legacy web/API stopped; legacy intake plugin/client/cron retired; `GottSibylaWorker` uninstalled; deployment automation accepted through D2 | Legacy Docs, stopped site definitions, folders, `gott_sibyla_legacy` and the old service account remain; E2 production-write proof, final deployment review and wider operational hardening remain |
| Security, resilience and release gates | Strong foundation / Phase 3 open | RLS, cross-tenant suites, hostile-document controls, evidence/redaction and deployment safety reviews; database-backed suites now run only against `gott_sibyla_preview` through dedicated Preview app/API/AI-reader roles; parity gates compare their grants, policies and attributes with Main while cross-database access stays closed | Failure-mode drills, restore drill, remaining security gaps, full RB1…RB9 re-verification, CI milestone gate, monitoring/backup evidence |

## Where `D-E2-3` sits in the whole project

```mermaid
flowchart LR
    PROJECT["Sibyla project"] --> PRODUCT["Product delivery"]
    PROJECT --> DATA["Data and migration"]
    PROJECT --> CHANNELS["Channels and integrations"]
    PROJECT --> OPERATIONS["Production and operations"]
    OPERATIONS --> DEPLOY["Deployment automation"]
    DEPLOY --> S2["Slice 2: execution"]
    S2 --> DS27["D-S2-7<br/>typed schema observed value<br/>lands before E2"]
    DS27 --> E2["E2: first production write"]
    E2 --> DE23["D-E2-3<br/>choose the injected failure"]

    classDef context fill:#e6eefc,stroke:#3156a3,color:#172554;
    classDef focus fill:#fde2e2,stroke:#b42318,color:#5a1712;
    class PROJECT,OPERATIONS,DEPLOY,S2,DS27,E2 context;
    class DE23 focus;
```

So `D-E2-3` is **not a whole-project phase or percentage marker**. It is one owner decision several
levels down inside the deployment-automation workstream. It matters because it proves safe recovery,
but completing it does not complete Argus, integrations, channel cutover, or Phase 3 hardening.

## Deployment detail (one workstream)

```mermaid
flowchart LR
    P0["Phase 0<br/>Discovery and architecture<br/><b>DELIVERED</b>"]
    P1["Phase 1<br/>Walking skeleton<br/><b>DELIVERED</b>"]
    P2["Phase 2<br/>Gold logic and screens<br/><b>MOSTLY DELIVERED</b><br/>live ERP proofs remain"]
    P3["Phase 3<br/>Hardening and go-live<br/><b>IN PROGRESS</b><br/>production is live; formal gates remain"]
    P0 --> P1 --> P2 --> P3

    S1["Deployment Slice 1<br/>plan-only module<br/><b>DONE</b>"]
    A2["A2<br/>contracts<br/><b>DONE</b>"]
    B2["B2<br/>execution engine<br/><b>DONE</b>"]
    C2["C2<br/>Windows adapters<br/><b>DONE</b>"]
    D2["D2<br/>production read-only checks<br/><b>DONE + MERGED</b>"]
    DS27["D-S2-7<br/>schema observed-value amendment<br/><b>RULED + IMPLEMENTED</b><br/>lands before E2"]
    E2["E2<br/>first production write<br/><b>WAITING FOR OWNER WINDOW</b>"]
    S1 --> A2 --> B2 --> C2 --> D2 --> DS27 --> E2
    E2 -. "closes module-driven deployment" .-> P3

    classDef done fill:#d9f7e7,stroke:#147a4b,color:#123b2a;
    classDef partial fill:#fff3cd,stroke:#9a6700,color:#4d3600;
    classDef wait fill:#fde2e2,stroke:#b42318,color:#5a1712;
    class P0,P1,S1,A2,B2,C2,D2 done;
    class P2,P3,DS27 partial;
    class E2 wait;
```

### What the diagram says

| Area | Current reading | Strongest evidence | What is still missing |
|---|---|---|---|
| Phase 0 | Discovery dossier delivered | 15 discovery documents and architecture diagrams | The old D-01…D-70 queue is not a reliable live checklist by itself; later rulings and amendments must be reconciled into one current register |
| Phase 1 | Walking skeleton and tenant-isolation foundation delivered | Sign-in, tenancy, licences, RLS, ingestion, queues, worker, full UI shell, sync gates | Fresh formal exit sign-off against the amended no-document-carry-over rule; fresh proof of any externally configured storage/provider criteria |
| Phase 2 | Most business logic and UI delivered | P2-02…P2-19 logic commits, UI-0…UI-5, channel-intake API/plugin, audit and quality surfaces | Real iziBizi document commit; ROSE flow/test subscription; Primavera v10 remains dependent on Cegid installation; OneDrive/Google Drive are optional stretch work |
| D-S2-7 | Ruled and implemented on the E2 preparation branch | `Precondition.Schema` receipts now render only parsed role/count/missing values plus a SHA-256 body digest, never the response body; RED/GREEN source and adapter gates recorded at `09fc531` | Land the amendment before the E2 run so a migration id containing a secret-pattern word cannot turn a valid schema check into a redaction failure |
| Phase 3 | Production host is live, but the formal hardening/go-live checklist is not closed | hand-path production deployment, Phase L/D naming shift, legacy services stopped, deployment Slice 2 through D2; D-S2-7 is the immediate pre-E2 amendment | D-S2-7 merge, then E2; final independent deployment review; failure drills; restore drill; security closure; accessibility/browser regression; CI gate; monitoring/backups evidence; cutover criteria rewritten for the 2026-09-02 no-document-carry-over ruling |

## `D-E3` does not exist; `D-E2-3` does

There is no literal planning identifier named **`D-E3`** in the repository. The current E2 preparation
brief defines **`D-E2-1` through `D-E2-5`**. The likely reference is:

```text
D - E2 - 3
│   │    └─ third decision inside this run
│   └────── deployment sub-slice E2 (first module-driven production write)
└────────── Decision
```

**`D-E2-3` chooses the intentionally injected Configure failure used to prove rollback and resume.**
The recommended mechanism is to deny the running operator write access to one file under the
parallel release's `web` tree after Publish succeeds and before Configure, let `Acl.Apply` fail in a
typed and journaled way, remove that deny with one `icacls` command, and then resume the same
transaction. It is a temporary test fault on the new parallel release—not a normal product feature
and not a failure injected into the live legacy sites.

The five E2 decisions are:

| ID | Owner decides | Recommended answer in the brief | Status |
|---|---|---|---|
| `D-E2-1` | Commit to publish for all three hosts | clean `main` at the E2 time | Awaiting owner ruling |
| `D-E2-2` | Execution window | two-hour slot starting after 15:30 UTC or ending before 08:30 UTC | Awaiting named time |
| `D-E2-3` | Injected Configure failure | reversible deny on one file in the parallel web release | Awaiting owner ruling |
| `D-E2-4` | End by rolling forward or back | roll forward; retain previous releases as rollback targets | Awaiting owner ruling |
| `D-E2-5` | Expected commit gate | exact commit selected by `D-E2-1` | Derived after `D-E2-1` |

After those decisions, E2 itself is four ordered proofs: full `-Execute -WhatIf`, full parallel
execution, injected failure plus `-Resume`, then roll forward. Two independent read-only reviewers
must accept the complete evidence before E2 merges and the module replaces the hand path.

> A separate use of **E3** exists in the Argus business rules: evidence tiers are
> E1 source-stated, E2 linked-evidence, **E3 rule-assumed**, and E4 pattern-inferred. That E3 has no
> relationship to deployment sub-slice E2 or decision `D-E2-3`.

## Why there are so many `D` identifiers

`D` consistently means **decision**, but the characters after it name the decision's scope. The
punctuation matters; these are separate namespaces.

| Form | Scope | Example | Meaning / authority |
|---|---|---|---|
| `D1`…`D20` | Project-wide decisions in force | `D10` | Continuous sync strategy, later amended so POC financial documents are not carried over. Main plan §0 |
| `D-01`…`D-70` | Phase 0 discovery owner queue | `D-10` | The discovery question corresponding to `DN-10`; proposals are not accepted merely by being written. Discovery 14 §2 |
| `DN-1`…`DN-17` | Original discovery-note aliases | `DN-10` | Source IDs retained so the mapping/sync documents can be traced into `D-01`…`D-17` |
| `D-AI-1`…`D-AI-11` | AI Projects / Development Harness | `D-AI-10` | Per-licence Apollo/Hermes gateway configuration. Harness plan §2 |
| `D-CI-1`…`D-CI-10` | Channel-intake API and plugin | `D-CI-2` | Credential establishes owner; sender binding establishes company; unknown senders quarantine. Intake spec §2 |
| `D-S2-1`…`D-S2-7` | Deployment Slice 2 design | `D-S2-7` | Post-acceptance schema-receipt amendment: render `Observed` from parsed values and a body digest, never the raw response body. Slice 2 spec/review §1 and §5.5 |
| `D-E2-1`…`D-E2-5` | One operational E2 run | `D-E2-3` | Owner choices needed immediately before the first module-driven production mutation. E2 preparation brief |

### The collision to avoid

| Identifier | It is **not** the same as | Actual subject |
|---|---|---|
| `D2` | `D-02`, deployment `D2`, or `D-S2-2` | Project-wide choice: the Invoice Skill Build prototype is the table-structure authority |
| `D-02` | project decision `D2` | Discovery queue: accept array-position line identity before cutover |
| deployment `D2` | either decision above | A sub-slice: read-only `-Execute -ChecksOnly` against production; accepted and merged |
| `D-S2-2` | deployment `D2` | Slice 2 design decision: Configure acts on the activated release path |
| `D-S2-7` | `D-E2-3` or deployment `D2` | Slice 2 schema-receipt safety amendment that lands before E2 |
| `D-E2-3` | evidence tier `E3` | E2 run decision: how to inject the rollback/resume fault |

## Missing-items radar

```mermaid
flowchart TB
    PRODUCT["Product gap<br/>processed intake → Argus document"]
    CHANNEL["Channel assurance<br/>final evidence review · deferred tests"]
    ERP["Integration proof<br/>iziBizi commit · ROSE · Primavera installation"]
    DATA["Data-scope correction<br/>retire document carry-over after D10 amendment"]
    DEPLOY["Deployment automation<br/>D-S2-7 merge · E2 run · final review"]
    HARD["Phase 3 hardening<br/>drills · restore · security · accessibility · CI"]
    SUPPORT["Companion/provider work<br/>Nextcloud proof · Hermes harness"]
    PLAN["Planning hygiene<br/>one current decision and acceptance register"]
    CLOSE["Formal project/go-live closure"]

    PRODUCT --> CLOSE
    CHANNEL --> CLOSE
    ERP --> CLOSE
    DATA --> CLOSE
    DEPLOY --> CLOSE
    HARD --> CLOSE
    SUPPORT --> CLOSE
    PLAN --> CLOSE

    classDef gate fill:#fde2e2,stroke:#b42318,color:#5a1712;
    classDef work fill:#fff3cd,stroke:#9a6700,color:#4d3600;
    classDef target fill:#e6eefc,stroke:#3156a3,color:#172554;
    class PRODUCT,CHANNEL,ERP,DATA gate;
    class DEPLOY,HARD,SUPPORT,PLAN work;
    class CLOSE target;
```

The repository does not currently define one authoritative priority order across these workstreams.
A practical dependency order is:

1. Reconcile D10 and the acceptance criteria so the team is building and signing off the same current
   scope. P3-10…P3-12 still describe a final document sync and FDR authority switch that D10 removed.
2. Complete the native product path from processed intake into Argus; without it, the independently
   implemented intake and governed Argus workflows do not form one complete new-document journey.
3. Close the channel-intake final evidence review and explicitly deferred test debt; its traffic
   observation and legacy intake retirement sequence are already complete.
4. Run the missing real-provider demonstrations; a successful connection test is not a successful
   document push.
5. Land D-S2-7 before E2, then complete the E2 run, its independent review, and the wider Phase 3
   hardening gates.
6. Finish optional/companion capacity work only where it is still desired: OneDrive/Google Drive and
   the Hermes variant of the AI Projects harness.

## Source map

- [Living discovery and phased plan](apollo-discovery-and-plan-260826.md)
- [Phase acceptance criteria and D-01…D-70 queue](discovery/14-risks-acceptance-criteria.md)
- [Accepted deployment Slice 2 specification](apollo-deployment-slice2-spec.md)
- [Accepted C2+D2 checkpoint](../local/deploy/tests/Sibyla.Deployment.Tests/evidence/CHECKPOINT-C2D2-review.md)
- [Preview/Main role-parity gates](../tests/Sibyla.Tests.TenantIsolation/PreviewParityTests.cs)
- [Shared Preview-only test database boundary](../tests/Sibyla.Tests.Shared/TestDatabase.cs)
- [AI Projects / Development Harness decisions](ai-projects-harness-plan-260831.md)
- [Channel-intake decisions](apollo-channel-intake-api-spec.md)
- [Trusted gateway envelope and WhatsApp alias bridge](../local/hermes/apollo-channel-intake/envelope.py)
- [Production deployment and legacy-retirement run record](apollo-deployment-run-260903.md)
- E2 preparation brief and D-S2-7 amendment: `docs/apollo-deployment-slice2-e2-prompt-260904.md`
  on `ops/sibyla-deployment-e2-prep` at `09fc531`; this branch lands before E2