v0.33.1

Gaps the first end-to-end run of /architect:design-aggregate --auto with the Domain Event
Catalog (the ec-monolith sample) surfaced in the skill itself.

Fixed

• The catalog can now name its own relationship. published-language joins the consumer
  relationship vocabulary — the catalog is defined as the context map's Published Language, yet
  the map's "OHS/PL" edges could only be recorded as open-host-service.
• A synchronous reply is not a consumer. The scope rule now says a consumer is an asynchronous
  subscriber; a context reading an event as the reply to its own command keeps the event
  internal, and api-style-decisions.json / asyncapi/ win over design prose when they
  disagree. Candidate contexts (an open OQ- on the CTX-) may consume, flagged
  candidate: true.
• Orphan events are listed, not dropped. An event the design names that no modeled aggregate
  declares goes into orphan_events (name + the document that names it); the validator rejects
  an orphan an aggregate does declare.
• Auto mode takes the consistency class from scalardb-transaction.md when it exists instead
  of defaulting every command to local and opening an OQ- per aggregate — the two passages
  contradicted each other.
• ADR gaps from the first design-microservices run. A legacy-path record whose drivers are
  all reports carries them as sources on the graph node (empty upstream, like physical-only
  nodes); upstream paths may be a review .json and carry a #anchor in any script; the
  "typical records" table is illustrative and the skill that decides first writes the record; a
  contradiction with another skill's design document is a Consequence and a review-consistency
  finding, not an edit; a colliding idempotency key already fixed by asyncapi/ is kept and
  recorded as an Open Item; the catalog .md names its completer in completed_by;
  design-microservices gains ADR outputs and Completion Criteria.
• also_writes is stated to be the local case only; re-runs update existing AGG- nodes in
  place; the idempotency key must be unique per event type (a review-risk finding the skill
  used to copy over); the catalog .md has a frontmatter template; completion criteria renumbered.

The DDD document-set check of 2026-08-29 (issues #32–#35): the four gaps between "the toolkit
covers every DDD technique" and "a reader can see the complete document set".

Added

• Architecture Decision Records (#32). reports/03_design/adr/adr-NNN-<slug>.md + index.md,
  MADR-shaped with a machine-readable frontmatter. redesign opens the log and registers the
  ADR- prefix; design-microservices, design-scalardb / design-data-layer and design-api
  append under the same additive contract as NFR- — allocate max + 1 over the graph, never
  rewrite another skill's record, supersede instead. Every record cites a non-empty upstream
  (a decision that cites nothing is a preference). rules/architecture-decision-records.md is the
  contract, tools/lib/adr_records.py the validator (24-check suite), review-consistency runs
  it. ADR- nodes are type: decision in work/traceability.json. On the legacy path, where
  no node exists yet, upstream cites the report that states the finding as a reports/ path.

• shared_outputs in the architect manifest. An artefact one phase writes and later phases
  append to (the ADR log, the domain event catalog) is declared as shared_outputs on every
  writer: known to the docs and the dashboard, but neither counted toward a phase's bar nor read
  as its last_write — so a later append never marks the first writer's dependents stale, and a
  project completed before the artefact existed does not drop below full.

• Domain Event Catalog — the context map's Published Language (#33).
  reports/03_design/domain-event-catalog.json + .md: every event the aggregates declare, its
  publisher, the contexts that consume it across which context-map relationship, and the delivery
  contract (guarantee, idempotency key, version, evolution) a consumer may rely on. Derived from
  the aggregate manifest and context-map.md — no new dialogue. design-aggregate writes it,
  design-microservices completes the consumer side once the service split is known (whichever
  runs second finishes it, as with the STM- link), and design-api's asyncapi/ is now emitted
  from it rather than re-derived. tools/lib/domain_event_catalog.py validates it (35-check
  suite): one publisher per event that really declares it, every declared event catalogued,
  consumers that are declared contexts other than the publisher's, a delivery contract on every
  published event. review-consistency runs it.

• User Story Map in define-features (#34). feature-list.md now carries the map — journey
  stages as backbone, FEAT- as stories, MoSCoW bands as release slices, Must as the walking
  skeleton — as a second view of the consolidated features, deciding nothing new.

• A committed reference DDD document set (#35). samples/ec-monolith/expected-reports/ holds
  what the DDD-relevant skills produce on the sample — ubiquitous language, Bounded Context
  Canvases, context map, four ADRs, four aggregates with their manifest, the domain event
  catalog, the Order state machine with its full matrix, the ScalarDB transaction design, a
  domain story and an example map — outside the git-ignored reports/ tree, so the document set
  can be seen rather than inferred. samples/ec-monolith/reference-set.test.py stages it as a
  project, runs the four manifest validators and both output hooks, and keeps it in step with
  docs/ddd-coverage.md in both directions.

Changed

• docs/ddd-coverage.md takes a position on its three △ rows (#34). User Story Mapping is ○
  (above). Event Modeling and Impact Mapping move to Deliberately not implemented with the
  reason: their content is already the manifests, the catalog and the traceability graph, and a
  timeline or impact rendering would be another view with no validator of its own. The △ status
  no longer appears in the table.