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 06 · Questions, interest, discussions and actions

Goal. Private questions, approved EOI, separate discussions, next actions, lifecycle and races.

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

Steps 01–05. 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: sender roles (Q02), pause/close matrix and reopen (Q04), EOI fields and state machine (Q05), contact allowlist (Q08), overdue and visibility rules (Q10). Policy-independent here: question, EOI and action plumbing and the idempotency mechanism.

Changes (illustrative, not a final schema)

Question threads, EOI records with a version reference, discussion and action records, idempotency records; events emitted through the outbox helper. Illustrative.

Build items:

• Question threads independent of EOI
• EOI required fields and version reference
• Atomic transitions: accept / decline / withdraw
• Attempt-aware idempotency; safe conflict on the loser
• Lifecycle matrix for pause/close
• Next actions scoped to participants

Expected outputs and invariants

One logical discussion per acceptance; one active EOI per respondent per opportunity; a third respondent is isolated; the pause/close matrix behaves as approved.

Tests-first subset

Primary scenarios of this step (write these tests first): T09, T10, T11, T12, T17, T18, T19, T20, T23, T24, T29, T32.

Assertions to write first: T09–T12, T17–T20, T23, T24, T29, T32; the engagement-side halves of T02, T03, T04, T13–T16, T21, T22, T25, T27, T28, DG22.

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:

• T10 — needs step 07: The notification and email canary scan needs the worker.
• T11 — needs step 07: No private body in email or logs needs the worker.
• T18 — needs step 07: One logical event for the retry needs the worker side.
• T19 — needs step 07: One acceptance event and no duplicate logical delivery identity need the outbox contract (01) and worker (07).
• T23 — needs step 07: No closure email event is confirmed with the worker.
• T29 — needs step 08: Cross-party visibility and daily-view effects are checked with 08.
• T32 — needs step 07: Notification history for reassignment is checked with 07.

Follow-up verification brought here

Earlier scenarios that can only be completed or rechecked once this step exists:

• T02 — Publish (04) and formal-interest submit, accept and message (06) rows complete the matrix; cells depending on pending Q02 stay Pending decision.
• T03 — Admin visibility of A-B and A-C engagements needs private engagements, messages and actions.
• T04 — Moving a question and an action needs step 06 records; reassignment notification behaviour needs step 07 and Q07 (no new event type assumed).
• T13 — Formal interest submit bound to the approved version needs step 06.
• T14 — A stale approved send of formal interest or accept needs step 06.
• T15 — Interest-side returned work needs step 06.
• T16 — Needs real publish/approve (04) and accept (06) commands to race.
• T21 — Recommendation refresh (05), EOI keeping V1 (06) and the safe change alert (07) complete it.
• T22 — Needs recommendations (05), EOI submission (06) and duplicate worker jobs (07).
• T25 — Revoked access to engagement records needs 06; suppression of a queued email needs the worker (07).
• T27 — Applies entity by entity as drafts, search results and conversations are built.
• T28 — Message bodies exist only after 06; the DG tool and metadata view (09) complete it.
• T33 — Verified for each real event-producing mutation as it is built; delivery in 07.
• T39 — Core screens exist only after those steps; measured at step 10 on the integrated build.
• DG22 — Needs engagement records (06) and the DG metadata view (09).

Decisions DG must settle (dependent behaviour stays blocked until DG chooses)

Q02, Q04, Q05, Q07, Q08, Q09, Q10

Exit evidence

Engagement scenarios green on the named build, except cells whose decision is still pending. Notification, email and DG-view dependent assertions remain open for steps 07 and 09.

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: Step-05-Discovery-and-Rule-Ranking ← this step → Step-07-Outbox-Worker-Email · Implementation-Order-Overview