Status. Proposed design only. Nothing in this vault is DG client approval. No application, service or test has been executed; every scenario is Not executed. Fees and dates are open.
Step 01 · Foundation and outbox contract
Goal. Repository, CI, environments, migrations, secrets, safe error visibility, and the base transactional-outbox contract that every event-producing mutation will use.
Not started. This is a specification; no code has been written. The primary-step mapping is an index, not proof that each full scenario can be completed in its step: see Dependency-and-Regression-Table.
Prerequisites
Policy-independent scaffolding may start only after the overall start conditions are met (statement of work, ready-to-start kickoff checklist, funded DG-owned accounts, region and identity provider chosen). Decision-dependent behaviour and its final oracle stay blocked until DG chooses the applicable rule. Proposed defaults are recommendations, never prerequisites. Any provisional synthetic exploration must be labelled reversible and unapproved and is not accepted production behaviour. Blocked until DG decides: retention, MFA and session policy, hosting region and processors (Q09); acceptance and launch authority (Q11). Scaffolding that does not depend on those choices (repository, CI, migrations, secrets handling, outbox helper) may start.
Changes (illustrative, not a final schema)
Repository layout, CI configuration, environment configuration, migration tooling, an outbox helper contract (state + event in one transaction). Contract is illustrative; no final schema is chosen here.
Build items:
- Version-controlled source and migrations
- CI: tests, build, scan
- Separate local / staging / production data and credentials
- Authentication, invitation and session configuration baseline
- Logging that never contains private bodies
- Base transactional-outbox contract: one helper that commits business state and an outbox event in one database transaction (delivery worker comes in step 07)
Expected outputs and invariants
Staging deploys from CI; secrets only server-side; synthetic data only; the outbox helper refuses to commit state without its event and the reverse.
Tests-first subset
Primary scenarios of this step (write these tests first): T37, T38.
Assertions to write first: Only the configuration and harness subsets of T37 and T38 (environment separation, secrets handling, credential isolation); the transaction-atomicity assertions of T33 against a test mutation.
Method: make one meaningful test fail for the expected reason, implement the minimum behaviour, refactor without changing the observable contract. A scenario whose decision is still pending stays Pending decision; no oracle is invented.
Deferred integration checks
Scenarios whose primary step is this one but whose full variants need later components:
- T37 — needs step 02, 03, 09, 11: Needs actual identity, role and revocation behaviour (02, 03), protected DG admin operations with MFA (09) and an integrated recheck (11).
- T38 — needs step 07, 10: Worker-failure visibility and staging email-sink isolation need the worker (07); the integrated operations review is at step 10.
Follow-up verification brought here
Earlier scenarios that can only be completed or rechecked once this step exists:
- None.
Decisions DG must settle (dependent behaviour stays blocked until DG chooses)
Exit evidence
Named foundation build deployed to staging with the implemented configuration and harness subsets of T37, T38 and T33 reported on their own terms. Full T37 and T38 remain unverified: they need identity, role and revocation behaviour (02, 03), DG admin operations (09), the worker and a staging email sink (07), operations review (10) and the named integrated build (11). T33 stays limited to a test mutation until every real event-producing mutation exists (04, 06).
Evidence is recorded only for a named build and fixture. A software scenario is not recorded as Passed until all its relevant variants have been exercised on a named integrated build (step 11).
Navigation: — ← this step → Step-02-Identity-Membership-Roles · Implementation-Order-Overview