Skip to content

Strata

Typed, local-first memory for Claude Code

Claude should remember your codebase.

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

Three memory shapes, kept distinct.

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

pr-context/

What happened on this branch. Per-PR working notes that archive when the PR merges. Time-bounded by design.

/strata:save

Semantic

domain/ · decisions/

What things mean here. What you've chosen and why. Long-lived, stable, audited via ADR supersession.

/strata:domain · /strata:decide

Procedural

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

Claude remembers what your team decided.

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.

you

Quick reminder, what's our ordering for Order events? I keep forgetting whether OrderPriced fires before or after OrderConfirmed.

strata

consulting the vault…

claude

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 .

consulted 3 notes · 280 tokens · stayed local
  • decisions/ 2026-05-12-event-ordering.md Use OrderPriced before OrderConfirmed
  • domain/ order-aggregate.md Aggregate state, events, transitions
  • lessons/ 2026-04-29-double-confirm-bug.md What happened, root cause, the fix

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.

lessons/ 2026-04-29-double-confirm-bug.md
---
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.
decisions/ 2026-05-12-event-ordering.md
---
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

Plain markdown. Your filesystem. No lock-in.

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.

~/StrataVault / myrepo / INDEX.md

Strata dashboard

Generated 2026-05-25 17:42 UTC · auto-regenerated on every write

Scope counts

Episodicpr-context/2
Semanticdomain/21
Semanticdecisions/11
Proceduralprocedural/4
Lifecyclepropositions/2 open
Bridgelessons/3

Drifted notes

  • domain/old-pattern.md3 unresolved · 47 commits since

Hot files (90d)

  • services/orders/OrderAggregate.cs42 commits
  • services/orders/Events.cs28 commits