v0.38.1

Fixed

• --layering=clean after its first real run on ec-monolith (order-service). The
  specification, the API layer, the interactors, the contract tests and the conformance check all
  came out (unit 140 / integration 28 / acceptance 30 / contract 42 green apart from the design
  contradictions the run surfaced), and 27 places where the skills left the clean style to the
  generator's judgment are now stated: execute(<Op>InputData) as the boundary method,
  void present(<Op>OutputData) with a request-scoped presenter, domain-free data records with
  the domain → OutputData copy moved to the interactor (two mapper halves, two owners), use cases
  without an operationId (saga / recovery / workers) having no output boundary, shared
  collaborators allowed in usecase/ and the transaction-opening rule stated by package rather than
  class suffix, participant operations joining rather than opening, exception types the handler
  branches on living in usecase/, the component scan covering api/, the behaviour-visible
  consequence of a presenter with no business judgment, and — the biggest gap — a style switch on an
  already-generated service described as the migration it is, with generate-scalardb-code
  repairing JaCoCo, ArchUnit and the scan. generate-api-code now starts the context after
  compiling (a Boot 4 / Jackson 3 property key had left a compiling application unable to start),
  boxes required scalars so @NotNull can fire, and keeps schema key names on collision;
  generate-contract-tests adds the one-boundary-one-interactor and single-presenter ArchUnit
  rules, pins api-contract-map.json into the test tree, allows a separate contractTest source
  set when JUnit platforms collide, fixes its duplicated step number, and reports a red suite as a
  completed run with causes; verify-implementation checks the clean dependency rule and the
  component scan itself, records where the inherited contract map disagreed with the code, and names
  a delegate's missing inputs.

v0.38.0

Added

• /architect:design-implementation --layering=ddd|clean. clean records Clean Architecture
  vocabulary for the application layer — one Use Case (input boundary) + Interactor per
  operationId, InputData / OutputData records, an output boundary and a Presenter under
  api/presenter/, the usecase/ package in place of application/. The choice is written once as
  layering_style in the frontmatter of api-layer-spec.md (seeded by options.layering_style) and
  read from there by generate-api-code, generate-graphql-code, generate-scalardb-code,
  generate-contract-tests (ArchUnit: controllers bound to boundaries, interactors never importing
  api/ or infrastructure/, presenters importing no domain type), generate-acceptance-tests
  and verify-implementation — no generator takes a flag of its own. Repository ports keep their
  DDD name and domain ownership under both styles, since the aggregate manifest, the Fakes and the
  coverage / mutation thresholds are keyed on them. Documented in docs/ddd-coverage.md.

Changed

• AI code quality gate: what the second order-service gate run taught. A major finding without
  a recorded owner and decision keeps the verdict at FAIL rather than CONDITIONAL; SAST evidence is
  files and rules scanned, with 0 files reported as not-configured (the usual cause: a
  git-ignored tree scanned without --no-git-ignore); the mutation report's timestamp is the proof
  it re-ran, equivalent mutants are re-read from the current run and their acceptance is a recorded
  decision; coverage aggregated over several test tasks is reported per layer against the §6 budget;
  and two dependency-scanner traps are named — classifier-suffixed jar versions Trivy compares
  without the suffix, and transitive findings cleared by a looked-up constraints pin, never by
  suppressing the advisory.

v0.37.2

Changed

• Documentation brought in line with the TDD workflow and the test skills. docs/getting-started
  (en/ja) gains the characterization step on the legacy path, what gate stages 2 and 4 hold the
  scaffold to, and the delivery path described as test-driven (walking-skeleton Issue, the
  test: → feat: → refactor: series, Fakes and injected Clock, reproduce-first fixes);
  README's delivery paragraph says the same; docs/architect-input-requirements (en/ja) lists a
  runnable legacy system — or a test-only datasource substitution — as an input for
  characterization tests; docs/scalardb-development (en/ja) documents the scaffold's test tree;
  OMNIGENT's quality-gate section names the stage 2/4 tasks and the clean-build rule; the
  skill-reference rows for export-backlog, implement-backlog and review-issue describe the
  current behaviour.

v0.37.1

What the first real run of the v0.37.0 test skills on the ec-monolith sample taught. The run
itself worked — order-service generated with unit 99/99, integrationTest 21/21 over an
in-process ScalarDB, PIT 96 %, 32 characterization fixtures pinning 6/6 entry points of the legacy
order module, 30/30 Gherkin scenarios bound — and the gate returned FAIL for the right reasons:
two acceptance scenarios red because three design artefacts disagree on one rejection slug, and
a transitive CRITICAL CVE. The fixes below are to the skills, not to the sample.

Fixed

• generate-characterization-tests. A test-only environment substitution (an H2 profile when
  the docker-compose database is absent) is not a modification of the system — allowed, with its
  boundary reported; the recording mechanism is now specified (-Precord mode, two runs, a
  mask-derivation script); non-determinism inside a string is normalized at observation time
  under a named rule; a defective outer seam is pinned together with the next one in; defects
  with no DEBT- id get @ObservedDefect("CHAR-…") and a follow-up; the standalone output root
  is defined.
• generate-scalardb-code. The blind-write scenario is Put / Insert — Update on an
  unread record performs an implicit read and commits on 3.19; a multi-service TX- is tested
  for this service's part with Fake participants asserting the binding; Cluster transaction
  propagation is named as unproven by the SQLite backend; the run summary has a path; outbound
  ports and Fakes are this skill's, the HTTP client adapters are generate-api-code's (new
  Outbound Clients section there).
• generate-acceptance-tests. @SelectPackages rather than the classpath-resource selector
  the engine warns against; @wip goes on the pinned copy only; the three red cases are kept
  apart — not implemented (@wip), unobservable at the chosen driver (@wip + PendingException),
  contradicted by the code (a finding, never @wip); the RULE- / EX- criterion is conditional
  on an example map; the driver default follows the contract map; fixtures are fixed builders
  with arbitrary-supplied defaults; the coverage report is per service; features another service
  owns are reported out of scope.
• Quality gate / verify-implementation. Every gate command runs from a clean build state —
  an UP-TO-DATE Gradle task exited 0 having run 0 tests; trivy fs on the fat jar scanned 0
  packages, so dependency scanning without OSV-Scanner uses Trivy rootfs over the extracted
  libs; an equivalent mutant is recorded as such only with evidence; a stage-4 red caused by the
  design contradicting itself stays FAIL and goes to the design for a decision; stages 5–6 put
  tool identifiers (CVE ids) in blocking; an absent API layer makes the contract map's unmapped
  operations info, not criticals; the project's package coverage rule decides while per-file
  figures are reported; the test-first record is not-applicable without a work item.
• .gitignore covers graphify-out/.

v0.37.0

A second pass over the toolkit with test-driven development as the premise, closing what the
v0.36.0 rules declared but did not connect, and the areas they did not reach.

Added

• Transaction-scenario integration suite. generate-scalardb-code now emits one *IT per
  TX- entry — happy path, OCC conflict, blind write, 2PC failure and saga compensation where the
  design uses them, indeterminate commit — over an in-process SQLite-backed ScalarDB, with an
  integrationTest task (failOnNoMatchingTests), so stage 4 of the quality gate has a suite
  behind it instead of a permanent not-configured. samples/scalardb-transaction-tests/ is
  the reference shape.
• /architect:generate-acceptance-tests. Cucumber-JVM step definitions for the Gherkin
  scenarios in reports/07_test-specs/bdd-scenarios/ (RULE- / EX- tag bound), an api or
  application driver over the Fakes with a fixed Clock, @wip on scenarios whose item has not
  landed (excluded from pass/fail, counted), an acceptanceTest task and
  reports/07_test-specs/acceptance-test-coverage.md — the ATDD outer loop of
  rules/tdd-workflow.md §3 made executable. Twenty-first extension-tier skill (108 commands).
• Suite policies. rules/tdd-workflow.md §6: a runtime budget per layer (unit ≤ 60 s,
  contract ≤ 3 min, integration / acceptance / characterization ≤ 10 min — over budget is a
  major with the slowest ten named), tests per layer reported, a flaky-test quarantine
  (@Tag("flaky"), counted and aged, major after 14 days, automatic retry never enabled on a
  gate task) and ubiquitous-language test naming; the gate records all of it, and
  review-consistency's terminology dimension checks test and scenario names against the glossary.
• Tests in /scalardb:* and /product:generate-frontend. scaffold lays out src/test/
  (repository port + InMemory*Repository Fake, unit test, ScalarDbTestBackend, *IT) and the
  integrationTest task; build-app writes each operation's tests before its service code;
  review-code gains a Tests item (real engine, OCC / blind write, testable without a database,
  weakened tests). generate-frontend emits Vitest + Testing Library tests over composed stories,
  page routing tests, a Playwright story-flow smoke and vitest.config.ts thresholds.

Changed

• review-issue reproduces before fixing. Every behavioural blocker gets a
  test: reproduce <blocker> commit shown failing before its fix: commit; non-behavioural
  blockers say why they skipped it.
• export-backlog emits the walking skeleton. One walking-skeleton Issue per new service,
  first in its Sub-Epic, cited by every sibling as its prerequisite.
• Characterization gate connected. implement-backlog records the characterizationTest
  baseline before a transformation-step item starts (red baseline → stop and generate the net);
  stage 4 of the gate and verify-implementation run it after, and a fixture edited in between is
  a decision on the Issue.
• docs/ddd-coverage(.ja).md. The three remaining △/× TDD rows are ◎; rows added for the
  integration suite, reproduce-first fixes and frontend tests.

v0.36.0

Closes the gap a DDD × TDD review of the toolkit found: the tests it generated were exhaustive
but nothing made them drive the code, nothing measured whether they would fail if the code were
wrong, and nothing pinned a legacy module before a transformation step touched it.

Added

• rules/tdd-workflow.md. Merge-bound code is written test-first as a Red → Green → Refactor
  commit series per unit (test: naming the tests that failed, feat:, refactor: editing no
  test), verifiable from the branch log; the ATDD outer loop (Gherkin scenario, else contract test,
  else invariant example) and the walking skeleton; the structure that makes test-first possible —
  one in-memory Fake per repository port, injected Clock / id generator, transactions opened by
  the application service; the exemptions; and what the gate records. implement-backlog Steps
  4/5/7 and its acceptance criteria follow it, design-implementation specifies the testability
  constraints, generate-scalardb-code emits the Fakes under **/fakes/, and
  generate-contract-tests adds the ArchUnit rules (no now() / randomUUID() in the domain).
• Test quality in the quality gate. Stage 2 of rules/ai-code-quality-gate.md now measures
  line/branch coverage of the changed files (JaCoCo, 90/80 on domain/ + application/, 70
  elsewhere), the mutation score of the touched domain packages (PIT, 80 % — and one surviving
  mutant on an invariant-enforcing or guard line fails the stage by name), and the test-first
  record per unit (reported, never thresholded). The gate JSON carries coverage, mutation and
  test_first; options.quality_gate overrides the thresholds per project;
  verify-implementation, the CI workflow generate-infra-code emits and the build files
  generate-scalardb-code writes are wired to the new tasks.
• /architect:generate-characterization-tests. Golden-master tests recorded from the
  running legacy system — a seam inventory per module, fixtures whose every value the code
  produced (a second run finds and masks non-determinism), @KnownDefect(DEBT-xx) markers that
  pin a bug without blessing it, and reports/07_test-specs/characterization-test-coverage.md by
  entry point. design-microservices now requires every transformation-plan step to name its
  characterization gate. Registered as the twentieth extension-tier skill (107 commands).
• docs/ddd-coverage.md § Test-driven development. The TDD practices with their status, and
  the gaps that remain visible as rows: suite runtime budget, flaky-test policy, test naming from
  the ubiquitous language.

v0.35.1

Fixed

• CI. The contracts workflow installs requirements.txt before running the suites;
  tools/build_report.test.py needs markdown and pyyaml and failed on the runner while
  passing locally, so v0.35.0 was tagged against a red run.

v0.35.0

What the first full pass over the sample project after v0.34 surfaced — design-implementation,
generate-test-specs, a review-consistency re-run, review-synthesizer, report and
review-report — and what it changed in the toolkit.

Added

• tools/build-report.py. /architect:report no longer re-authors full-report.html by hand
  on every run: the consolidated HTML report is built by a tool — one article per source document
  with stable ids, phase sections for before/, 01–04, 06_implementation, 07_test-specs
  (Gherkin .feature files as code) and review/, an executive summary from
  review-synthesis.json and the Open Questions store (or a clean "review not yet run" state),
  Mermaid inlined from the docs-site node_modules (cache, then CDN fallback), bilingual chrome
  from options.output_language, a single page h1 with documents at h3 and their bodies
  from h4. tools/build_report.test.py guards the rendering contract (35 checks); the report
  skill's Input Sources table gained the two new directories.

Fixed

• Body H1 in generated documents. The design-aggregate and design-state-machine templates
  and the api-style-decisions.md projection repeated the frontmatter title as a body #,
  against rules/output-conventions.md (nine documents per project — review-consistency
  CON-110). The templates and tools/lib/api_style_decisions.py drop it, the committed reference
  set is regenerated, and reference-set.test.py asserts that bodies start at ##.
• Docs site. Gherkin .feature files under reports/07_test-specs/bdd-scenarios/ render as
  code pages instead of being copied to public/ as static files.

v0.34.1

Two blume validate findings from the first run of tools/docs-site.sh over a full report set.

Fixed

• Docs site. A section-number anchor in a report link (scalardb-schema.md#9.5 — the shape
  rules/architecture-decision-records.md allows in upstream) is not a Blume heading slug and
  produced a broken link on every ADR provenance line; a purely numeric anchor now resolves to the
  page. Nested report directories (adr/, aggregates/, state-machines/, …) get distinct
  sidebar orders instead of all falling back to alphabetical, and a directory that has its own
  index page is labelled by that page's title so the sidebar and the page agree.

v0.34.0

Added

• Report documentation site. tools/docs-site.sh serves a project's reports/ tree as a
  local, searchable documentation site on Blume (Astro; Node ≥ 22.12):
  one page per report with Mermaid rendered, the OpenAPI / AsyncAPI specs mounted as Blume's API
  reference (/api/<service>, /events/<name>), the consolidated full-report.html served
  as-is, and a landing page built from work/pipeline-progress.json (options, every phase with
  its status and links to its outputs). sync, dev (re-syncs as reports/ changes), build,
  preview, validate (internal links), clean. Nothing in reports/ is modified: the site is
  a stage rebuilt on every run, and every generated directory under tools/docs-site/ is
  git-ignored.
• tools/docs-site/sync_reports.py — the conversion: reports become MDX (Blume renders Mermaid
  only in .mdx); {…} and a bare < outside code are escaped; numeric phase prefixes are
  dropped from routes (01_analysis/x.md → /analysis/x) so cross-report links can be
  rewritten; links to project files the site cannot serve (samples/…, work/context.md)
  become plain text; each report's own frontmatter is kept under a declared nexus key (Blume
  rejects unknown keys and its built-in id / status collide with the ADR shape); top-level
  directories are sidebar groups in pipeline order, pages inside follow the manifest's
  declared-output order.
• docs/docs-site.md (+ _ja), with pointers from README, docs/getting-started and CLAUDE.md.