Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions docs/narratives/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -182,6 +182,22 @@ A new narrative is *not* warranted for:

When in doubt, prefer extending an existing narrative's Setting or per-Moment alternate-path subsection over forking a new narrative.

## When the narrative layer does not apply

The section above governs *variations of a journey that has a protagonist*. This section governs the prior question: **does the bounded context have a journey to render at all?** Some do not.

A narrative's load-bearing requirement is the [Voice and perspective](#voice-and-perspective) rule — the omniscient narrator dramatizes *what the protagonist actually perceives*. That convention tolerates Moments where the system does most of the work off-stage, but it still hangs on the protagonist perceiving **something**: a view they read (Context), an action they take or a trigger they witness (Interaction), a state change visible to them on screen (Response). A **headless / machine-to-machine bounded context** — one whose slices are entirely inter-service plumbing or server-side processing with no protagonist-perceivable surface — has all three phases empty. There is nothing to dramatize, and forcing a narrative would require **inventing** UX surfaces (a status indicator, a permission prompt) that the workshop never modeled — violating the [`Do not carry: UX / UI design`](#what-narratives-carry-and-dont) guardrail and the [two-layer-fidelity](#two-layer-fidelity) "no confabulation" discipline.

**The test is empirical, not presumed.** Before skipping, read the BC's workshop for *any* protagonist-app-visible detail — a "sharing is on" indicator, a permission prompt, a status surface, an action the protagonist takes or witnesses. If one exists, thread it into a (possibly very short) narrative. If none exists, skip — but **record the skip and its rationale here**; per the [session workflow](../../CLAUDE.md) the narrative step cannot be silently dropped.

This mirrors, one layer up, the same call an Event Modeling workshop makes when it takes the **EM-direct path and skips Domain Storytelling** for a machine-to-machine BC with no human language boundary (W005, W006). No perceiving protagonist, no journey to tell.

### Skipped narratives (recorded)

| BC / Workshop | Decision | Rationale |
|---|---|---|
| **Telemetry** ([Workshop 006](../workshops/006-telemetry-event-model.md)) | Narrative layer **does not apply** (recorded 2026-07-10). | Machine-to-machine throughout: a driver device streams GPS pings over gRPC client-streaming; Dispatch consumes a Kafka-joined view. W006 §6.2 processing is entirely server-side; the UL (§4) defines *driver session* as "a logical concept, decoupled from any physical stream"; no driver-app-visible surface — indicator, permission prompt, or status screen — is named anywhere in W006 or [ADR-018](../decisions/018-candidate-projection-ownership-and-telemetry-geospatial-supply.md). No protagonist-perceivable moment exists to dramatize. Matches W006's own EM-direct precedent (it skipped Domain Storytelling for the same reason). See [retro](../retrospectives/telemetry-narrative-layer-decision.md). |

## Retrospective convention

Every narrative ships its retrospective in the same file, appended after the `## Deferred from this narrative` section. The retrospective shape mirrors workshop 001's §12 with narrative-flavored content. See narrative 001's retrospective for the canonical structure.
Expand All @@ -193,7 +209,10 @@ Every narrative ships its retrospective in the same file, appended after the `##
| [001](./001-rider-books-a-ride.md) | Accepted | Rider | Happy path | 5.1, 5.2, 5.3, 5.4, 5.5, 5.10 |
| [002](./002-driver-accepts-a-ride.md) | Accepted | Driver | Happy path | 5.4, 5.5, 5.10 |

*Telemetry (Workshop 006) is intentionally **not** narrativized — a headless machine-to-machine BC with no protagonist-perceivable moment. See [§ When the narrative layer does not apply](#when-the-narrative-layer-does-not-apply).*

## Document history

- **v0.1** (2026-04-25): Initial authoring conventions established alongside narrative 001. Format dialect locked (NDD-informed structured markdown; no NDK dependency). Frontmatter schema v1 bounded. Moment body structure (prose-paragraph labels) locked. Single-named-protagonist voice convention locked. Cumulative deferral discipline established with seven disposition tags. Bidirectional referencing convention proposed (forward-looking; not yet adopted in workshops).
- **v0.2** (2026-05-04): Added "Two-layer fidelity" section per narrative 002's session — locked prose stays in narrator-omniscient voice; assumptions about un-modeled BC behavior live in the authorial-call layer as forward-constraints on later workshops. Added narrative 002 row to the Index.
- **v0.3** (2026-07-10): Added the "When the narrative layer does not apply" section — the criterion for a headless / machine-to-machine BC with no protagonist-perceivable moment, its empirical test, and a "Skipped narratives (recorded)" table. First entry: **Telemetry (Workshop 006)** — narrative layer does not apply; no driver-app-visible surface exists in W006 to dramatize, matching W006's own EM-direct (Domain-Storytelling-skip) precedent. Recorded per the session-workflow rule that the narrative step cannot be silently dropped. Session produced no narrative and no prompt doc; a disposable planning note (`docs/planning/2026-07-10-telemetry-narrative-decision-handoff.md`) served as the prompt-equivalent (W005/W006 precedent). See [retro](../retrospectives/telemetry-narrative-layer-decision.md).
2 changes: 2 additions & 0 deletions docs/retrospectives/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -87,6 +87,8 @@ Subsequent sections are session-specific. Existing retros in this directory serv
- [`frontend-architecture-unpark.md`](./frontend-architecture-unpark.md) — **First frontend design-return.** Unparked the frontend decision parked since vision v0.1, after the [sibling-repo frontend survey](../research/frontend-survey-sibling-repos.md) discharged the "CritterBids lands on a stable live-update pattern" trigger. Five decisions walked: transport recording (Accepted, SignalR — gRPC-web ruled out as niche/experimental before grill reached question 2); stack/monorepo (vision doc only, no ADR); map library (re-filed to open question); gRPC-web spike (moot); contracts-package shape (open question). ADR-016 (Frontend Live-Update Transport) authored and Accepted: SignalR with transport-agnostic push→Query-cache-bridge architecture; component contract decoupled from transport at the `createConnection` seam. Vision bumped to v0.6: frontend stack + audience-SPA monorepo direction adopted; two parked items retired; three new open questions filed (map library, contracts-package shape, monorepo vs. separate repos). Two successor sessions named: map-library spike (after Telemetry geospatial representation is settled); contracts/monorepo session (at first frontend implementation). Null narrative/workshop spec delta — fifth honest-null instance. Triggered by [`prompts/frontend-architecture-unpark.md`](../prompts/frontend-architecture-unpark.md). Status: complete (2026-06-16).
- [`skills-tidy-wolverine-marten-automation.md`](./skills-tidy-wolverine-marten-automation.md) — Second skill-tidy session. Drained the two 2026-06-25 `DEBT.md` rows surfaced by retro 005 (slice 5.3): the marker-interface union return type and the event-triggered automation handler shape. Critter-skill-auditor Phase 1 discovery ruled out both candidate bolt-on homes and recommended a new skill — [`docs/skills/wolverine-marten-automation/SKILL.md`](../skills/wolverine-marten-automation/SKILL.md), a fourth sibling alongside the HTTP/messaging/gRPC handler-shape skills. Reading `Program.cs` directly surfaced a second, independent registration prerequisite (`CustomizeHandlerDiscovery(...WithNameSuffix("Automation"))`) the DEBT row hadn't named — source-of-truth precedence (working code → retro → external docs) paying off a second time, same lesson as the first skill-tidy session's namespace catch. `docs/skills/README.md` updated across all four navigation surfaces (cluster index, tag index, entry-point hubs, Phase 2 cross-reference graph). Item 1 of the [post-W006 handoff](../planning/2026-07-02-post-w006-next-steps-handoff.md)'s ordered table. Honest null spec delta. Triggered by [`prompts/skills-tidy-wolverine-marten-automation.md`](../prompts/skills-tidy-wolverine-marten-automation.md). Status: complete (2026-07-02).

- [`telemetry-narrative-layer-decision.md`](./telemetry-narrative-layer-decision.md) — **Narrative-layer decision session** (design-layer, no code). Resolved the single open pre-implementation question for the Telemetry chain: does a thin driver-device narrative apply, or is the narrative step skipped? Decision: **the narrative layer does not apply** — an empirical scan of W006 §6.2–§6.5 + the Ubiquitous Language found no driver-app-perceivable surface (server-side processing throughout; *driver session* defined as "a logical concept, decoupled from any physical stream"; no indicator / permission prompt / status screen named in W006 or ADR-018). Recorded in [`docs/narratives/README.md`](../narratives/README.md) via a new "When the narrative layer does not apply" section + "Skipped narratives (recorded)" table + v0.3 Document-history entry, rather than folded into the not-yet-written first implementation prompt. Mirrors W006's own EM-direct (Domain-Storytelling-skip) precedent one layer up. No prompt doc authored — a disposable planning note (`docs/planning/2026-07-10-telemetry-narrative-decision-handoff.md`) served as prompt-equivalent (W005/W006 precedent). Spec delta lands at the narratives-README convention layer (no narrative/workshop amended — that *is* the decision). Status: complete (2026-07-10).

Phase 1–3 retrospectives were not authored at the time those phases ran (the retrospective convention solidified during Phase 4). They may be reconstructed from the working transcripts and skill artifacts if needed; otherwise they remain a known gap in the project record.

### Per-skill retros (`skills/`)
Expand Down
49 changes: 49 additions & 0 deletions docs/retrospectives/telemetry-narrative-layer-decision.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# Retrospective — Telemetry Narrative-Layer Decision

- **Triggering intent record (prompt-equivalent):** `docs/planning/2026-07-10-telemetry-narrative-decision-handoff.md` — a disposable planning handoff (left untracked) that scoped this single decision. No separate prompt document was authored; the handoff served as the prompt-equivalent, per the W005/W006 precedent (a planning/grill note standing in for a prompt). Guardrail #3 of the handoff explicitly permitted retro-direct for a decision this small.
- **Status:** Complete (2026-07-10).
- **Output artifacts:** [`docs/narratives/README.md`](../narratives/README.md) — new "When the narrative layer does not apply" section (criterion + empirical test + "Skipped narratives (recorded)" table), an Index note, and a v0.3 Document-history entry. This retro.
- **Outcome:** Telemetry's narrative step is **explicitly skipped** — the narrative layer does not apply — recorded durably in the narratives layer's own operational manual.

## Framing

Per the session workflow ([CLAUDE.md](../../CLAUDE.md) §Session Workflow, step 4), a narrative is normally authored between an Event Modeling workshop and its implementation prompt(s). Workshop 006 (Telemetry) is locked, its `v1` protobuf contracts shipped (PR #39), and the first transport build is queued next. This session resolved the one open pre-implementation question: does a thin driver-device narrative apply to Telemetry, or is the narrative step skipped with recorded rationale? The workflow forbids silently dropping the step, so the decision had to be made and recorded — as its own PR — before implementation begins.

## The decision and how it was reached

**Decision: the narrative layer does not apply to Telemetry.** No narrative is authored.

The handoff mandated an *empirical* check rather than a presumption: re-read W006 §6.2–§6.5 (and the Ubiquitous Language) for any driver-app-perceivable detail — a "location sharing is on" indicator, a permission prompt, a status surface, or an action the driver takes or witnesses. The scan found none:

- **§6.2 (GPS ingest):** the trigger is "a mobile client opens a windowed `ReportLocations` stream" — the device/software acts, not the driver; `driverId` comes from the authenticated principal, never the payload; all processing is server-side and in-flight.
- **§6.3 / §6.4 / §6.5:** Kafka publish, document upsert + eviction sweep, and the Dispatch-side consumer view — all inter-service plumbing or server-side housekeeping.
- **§4 (UL):** *driver session* is defined as "a **logical** concept, decoupled from any physical stream"; *active* means *pinging*, not anything the driver sees.

Applying the narratives README's own rubric, the load-bearing gate is **Voice and perspective**: the omniscient narrator dramatizes *what the protagonist actually perceives*. Telemetry's protagonist perceives nothing across the whole BC — Context, Interaction, and Response all collapse to empty. Forcing a narrative would require **inventing** a UX surface that neither W006 nor ADR-018 names, violating the "do not carry: UX/UI design" guardrail and the two-layer-fidelity "no confabulation" discipline. This is the same reasoning W006 used one layer up when it took the EM-direct path and skipped Domain Storytelling (machine-to-machine; no human language boundary).

The rationale was recorded in `docs/narratives/README.md` (Option A of the two the handoff floated) rather than folded into the not-yet-written first implementation prompt (Option B). Option A lands the decision durably in the most stable artifact in the chain, is discoverable exactly where a future reader would look ("where's the Telemetry narrative?"), generalizes into a reusable criterion for future headless BCs, and lets this session ship self-contained. Option B would have split "decide" from "record" across two PRs and buried a durable cross-BC decision in a transient artifact. User signed off on Option A.

## What worked

- **The empirical-test discipline the handoff insisted on.** Reading the workshop for a concrete perceivable surface — rather than reasoning abstractly from "Telemetry is machine-to-machine" — made the call dispositive and defensible, and produced the exact citations the recorded rationale needed (§6.2 server-side processing; §4 "logical concept").
- **The README already contained the deciding rubric.** The Voice-and-perspective rule and the UX/UI-design guardrail settled the question without inventing new criteria; the new section layers *on top of* the existing "warranted / not warranted" split rather than competing with it (variations-of-a-journey vs. no-journey-at-all).
- **A generalized "Skipped narratives (recorded)" table** turns a one-off decision into a reusable convention with a home for the next headless BC, and mirrors the workshop-layer EM-direct precedent for structural consistency across layers.

## What was harder than expected

- **Deciding the session's own paperwork shape.** With the deliverable being a single README amendment, the questions "does this need a prompt?" and "where does the retro live?" carried more deliberation than the design decision itself. Resolved by precedent: planning-note-as-prompt-equivalent (W005/W006) → no prompt; README-convention amendment → root-level retro (as with the spec-delta-closure-loop encoding session).
- **Handoff-doc lifecycle.** The 2026-07-10 and 2026-07-04 handoffs are untracked working notes ("disposable by design"). Rather than commit spent scaffolding, they were left untracked; the durable record lives in the README + this retro. The 2026-07-04 handoff remains the live orientation for the next session (its item 2).

## Methodology refinements that emerged

- **"When the narrative layer does not apply" is now a named, tested convention.** Future headless / machine-to-machine BCs run the same empirical test and record the skip in the same table — the narrative step can be discharged without silently dropping it.
- **Layer symmetry made explicit.** The narrative-skip-for-headless-BC decision is the same shape as the workshop-layer EM-direct (Domain-Storytelling-skip) decision. Both hinge on "no perceiving protagonist / no human language boundary." Naming the parallel in the README keeps the two design layers reasoning consistently.

## Outstanding items / next-session inputs

- **The first real transport build** (item 2 of the 2026-07-04 post-PR-39 handoff, `docs/planning/2026-07-04-post-pr39-telemetry-next-steps-handoff.md`, the live orientation note) is now unblocked at the design layer and is the next session (its own PR, or skeleton + first slice sharing one per the named exception). Carry forward its **load-bearing forward-constraint**: WolverineFx.Grpc had no client-streaming auto-codegen adapter on the verified 5.x line; `ReportLocations` must be hand-wired against `IMessageBus` or re-verified against 6.8 first. Do not "upgrade" R5's client-streaming to bidirectional to dodge the gap.
- **The 2026-07-10 handoff is fully discharged** and may be deleted at will (disposable by design).

## Spec delta — landed?

**Landed as planned.** This session amends no narrative or workshop (none applies — that *is* the decision), so there is no narrative/workshop `## Document History` amendment. The spec-shaped delta is the convention itself: `docs/narratives/README.md` gains the "When the narrative layer does not apply" section, the Index note, and the v0.3 Document-history entry recording the Telemetry skip. The README's own Document history is the closure-loop record for this session.
Loading