Episodic
pr-context/
What happened on this branch. Per-PR working notes that archive when the PR merges. Time-bounded by design.
/strata:save
Typed, local-first memory for Claude Code
Decisions, domain rules, and runbooks, kept as plain markdown Claude reads on its own — not crammed into one giant context file, not lost in a vector database.
/plugin install strata@strata 0
memory scopes
episodic / semantic / procedural / propositions / lessons / pr-context
0
graphify hooks
recall, drift, churn, ADR linkage, projection, verification
0
network calls
local FTS5 + fastembed, no port, no telemetry
~0×
token economy
progressive disclosure vs naive context dump
the model
Strata splits memory into three kinds — episodic, semantic, and procedural — and keeps each on its own retrieval path. A decision you make once and a runbook you follow weekly age differently, so the right shape comes back when you ask.
Episodic
What happened on this branch. Per-PR working notes that archive when the PR merges. Time-bounded by design.
/strata:save
Semantic
What things mean here. What you've chosen and why. Long-lived, stable, audited via ADR supersession.
/strata:domain · /strata:decide
Procedural
How you do things here. Recipes and runbooks. The sequence that turns "we should" into "here's the steps."
/strata:procedure
lessons/ bridges episodic and procedural.
propositions/ tracks open questions through their
lifecycle, from open to contested to settled or refuted.
in practice
No commands. No queries. Ask something that touches durable knowledge and Strata surfaces the relevant ADR, domain note, or retrospective. With the exact file paths cited, so the answer is traceable.
Quick reminder, what's our ordering for Order events? I keep
forgetting whether OrderPriced fires before or
after OrderConfirmed.
consulting the vault…
OrderPriced fires before OrderConfirmed. The reason: confirmation events
need to carry the final priced state, otherwise downstream
projections see stale totals.
You hit this last April, there's a postmortem in . The fix became .
Strata runs the search in a background context. Only the curated answer comes back to your main conversation, so your token budget stays clean. Tap the receipt to see what was consulted; any citation chip opens the source note.
---
title: OrderConfirmed without final price → stale projections
kind: handoff
date: 2026-04-29
branch: feat/order-pricing
tags: [order, events, ordering]
---
# What happened
Tuesday 22:14, the Branch Ready projection started showing wrong
totals. A nightly rebuild from the event store fixed it, but only
until the next live `OrderConfirmed` arrived.
# Root cause
`OrderConfirmed` was emitted BEFORE `OrderPriced` in the
`PricingProcessManager`. The confirmation snapshot captured the
draft total, then pricing finalised and emitted a different one.
Projections subscribed to confirmation events, so they kept the
stale figure.
# What we'll do differently
- Confirmation events should always carry the final priced state.
- Process managers that emit a "settled" event must wait for
every dependent calculation to commit first.
- Add an integration test that asserts the order of these two
events for every order lifecycle path.
---
title: Order events emit in pricing-then-confirmation order
status: accepted
date: 2026-05-12
supersedes: []
superseded_by: []
tags: [order, events, ordering, projections]
---
## Context
Projections that consumed `OrderConfirmed` were occasionally
seeing pre-pricing totals (see [[lessons/2026-04-29-double-confirm-bug]]).
We needed a rule that prevents this class of bug for every
order-pricing path, not a one-off fix.
## Decision
The `Order` aggregate emits events in this order, every time:
1. `OrderPlaced`
2. `OrderPriced` ← carries the final total
3. `OrderConfirmed` ← snapshots priced state
The `PricingProcessManager` is responsible for sequencing.
Confirmation cannot complete until pricing has committed to
the event store.
## Alternatives considered
- Emit `OrderConfirmed` first, then a `PricingFinalised` event
that projections subscribe to. Rejected: makes "what's the
confirmed total" a two-step lookup.
- Make pricing synchronous inside the confirmation handler.
Rejected: couples two concerns into one transaction; pricing
needs to be re-runnable.
## Consequences
- All Order projections subscribe to `OrderConfirmed` and trust
the carried total.
- Adding new pricing inputs requires re-running pricing BEFORE
confirmation, never after.
- Tests assert event order for every order lifecycle path.
the vault is yours
Notes are markdown with YAML frontmatter on your disk. Sync them with whatever you already use. Open the vault in Obsidian, VS Code, or your terminal. Read them years from now without the plugin running.
| Episodic | pr-context/ | 2 |
| Semantic | domain/ | 21 |
| Semantic | decisions/ | 11 |
| Procedural | procedural/ | 4 |
| Lifecycle | propositions/ | 2 open |
| Bridge | lessons/ | 3 |
domain/old-pattern.md — 3 unresolved · 47 commits sinceservices/orders/OrderAggregate.cs — 42 commitsservices/orders/Events.cs — 28 commitsdocumentation
Install, init, first session, first save.
→ 02Episodic / semantic / procedural and why it matters.
→ 03Vault, scopes, branch awareness, the things to know.
→ 04Every slash command and when each auto-invokes.
→ 05One-time migration of existing planning docs into the vault.
→ 06Graphify integration: code_map, drift, ADR linkage.
→ 07Fix, invalidate, supersede, with full audit trail.
→ 08The ambient surface plus the memory-recall subagent.
→ 09How the pieces fit. The seam between skills, scripts, vault.
→