Single Read Model Architecture (ADR-006): unify all consumers onto MasterDataset#28
Merged
darko-mijic merged 18 commits intomainfrom Feb 21, 2026
Merged
Single Read Model Architecture (ADR-006): unify all consumers onto MasterDataset#28darko-mijic merged 18 commits intomainfrom
darko-mijic merged 18 commits intomainfrom
Conversation
Eliminate the parallel pipeline anti-pattern in validate-patterns.ts: the validator now consumes RuntimeMasterDataset instead of wiring its own scan→extract→match pipeline with lossy GherkinPatternInfo types. Key changes: - Wire canonical 8-step pipeline (scan→extract→merge→transform) - Two-phase cross-source matching via relationshipIndex (DD-3) - Symmetric implements resolution in both TS→Gherkin and Gherkin→TS - Naming collision guards in both match directions - Remove spurious @libar-docs-phase from 5 utility patterns - Delete GherkinPatternInfo and extractGherkinPatternInfo - Use getPatternName() consistently to match relationshipIndex keying Resolves: 7 false-positive warnings → 0 warnings, 0 errors Matched: 0 → 64 cross-source pattern matches
All 6 deliverables verified: phase tag removal, pipeline wiring, validatePatterns() rewrite, lossy type deletion, import cleanup, and zero warnings on validate:patterns.
Update deliverable list to reflect design decisions: handleStubs, handleDecisions, and handlePdr already delegate correctly (DD-5), handleArch stays inline (DD-6). Replace 7 deliverables with 6 focused on pipeline factory extraction, CLI migration, and rules-query extraction.
- Wire PipelineOptions.exclude through to scanPatterns() and scanGherkinFiles() — was silently dropped, breaking --exclude in validate-patterns when building the MasterDataset - Update PipelineFactory and RulesQueryModule status to completed (matches parent spec ProcessAPILayeredExtraction) - Remove unused includeValidation field from PipelineOptions (YAGNI)
… failures PipelineResult now includes a warnings array so non-fatal issues (e.g. Gherkin scan failure) reach CLI consumers via stderr rather than being silently dropped.
Align documentation with the completed ValidatorReadModelConsolidation and ProcessAPILayeredExtraction refactoring. Key changes: - ARCHITECTURE.md: Add Single Read Model principle, Pipeline Factory section with types/consumer tables/anti-patterns, expand relationshipIndex schema from 4 to 10 fields, add factory flow diagram - PROCESS-API.md: Document rules subcommand, update overview to mention buildMasterDataset() - VALIDATION.md: Add architecture note on MasterDataset consumption via shared pipeline factory - METHODOLOGY.md: Broaden Read Model definition to all consumers - SESSION-GUIDES.md: Replace stale npx generate-docs with pnpm docs:all - INDEX.md: Update line counts and detailed ToC ranges
…nd test file splits DoD validator now accepts n/a and superseded as terminal deliverable statuses via isDeliverableStatusTerminal(). Raised anti-pattern thresholds (scenario bloat: 20→30, mega-feature: 500→750) and split 8 over-threshold test/spec files into 20+ focused files with shared state helpers. Process Guard now supports file splits: new files with @libar-docs-unlock-reason bypass the FSM transition check, preventing false invalid-status-transition errors when reorganizing completed patterns. All 7801 tests pass, validate:all exits 0 with 0 errors and 0 warnings.
Eliminate the last Parallel Pipeline anti-pattern from ADR-006 by making generateDocumentation() delegate to buildMasterDataset(). - Move mergePatterns to pipeline/merge-patterns.ts (fix inverted dep) - Add PipelineWarning/ScanMetadata types with structured detail - Add includeValidation and failOnScanErrors options to PipelineOptions - Replace ~145 lines of inline pipeline with single factory call - Update process-api.ts and validate-patterns.ts for PipelineWarning
…g warning - Update @libar-docs-uses in process-api.ts to reflect PipelineFactory/RulesQueryModule - Fix stale JSDoc in dod-validator.ts: "complete" → terminal statuses - Add warning when merge conflicts are silently concatenated in pipeline factory - Make RuleOutput fields readonly to match RulesQueryResult discipline - Add explicit LoadedWorkflow type annotation in build-pipeline.ts
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (185)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughAdds an advanced architecture-diagram spec, migrates the orchestrator pipeline to a factory, extracts process-API rules query, and updates several deliverable/status metadata entries across delivery-process specs. Changes
Sequence Diagram(s)sequenceDiagram
participant CLI
participant Orchestrator
participant PipelineFactory
participant MergePatterns
participant Generators
participant FS as FileSystem
CLI->>Orchestrator: generateDocumentation(options)
Orchestrator->>PipelineFactory: buildMasterDataset(options)
PipelineFactory->>MergePatterns: mergePatterns(masterDataset)
MergePatterns->>Generators: generateDiagrams(mergedDataset)
Generators->>FS: write(diagramFiles -> outputDir)
FS-->>CLI: return(output paths)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…output The 130 INFO messages (Gherkin patterns with no TS match) are structurally expected for ADRs, roadmap specs, and test features — never actionable. They are now hidden by default and available via --verbose flag. JSON output is unchanged.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
delivery-process/specs/validator-read-model-consolidation.feature (1)
62-66:⚠️ Potential issue | 🟡 MinorDD-1 and DD-4 are stale now that the shared pipeline factory is completed in this same PR.
- DD-1 (line 62): States "not a shared factory yet" — but
ProcessAPILayeredExtraction(which extractedbuild-pipeline.ts) is listed as completed in this PR's commit set.- DD-4 (lines 81–82): States "temporary parallel pipeline (acknowledged) that will be replaced when the pipeline factory exists" — the factory now exists. If the validator was not migrated to it, this is undocumented technical debt; if it was, the DD is factually incorrect.
Either update the DDs to reflect the final implementation decision (did the validator adopt
buildMasterDataset()or not?), or note why the validator intentionally remained on the inline pipeline.Also applies to: 79-82
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@delivery-process/specs/validator-read-model-consolidation.feature` around lines 62 - 66, Update the DD notes in validator-read-model-consolidation.feature to reflect the current state: replace the stale claims that the pipeline factory doesn't exist with a statement that the shared pipeline factory (extracted by ProcessAPILayeredExtraction / build-pipeline.ts) is now present, and explicitly state whether the validator was migrated to use buildMasterDataset() from the factory or intentionally left using the inline scan-extract-merge-transform pipeline; if migrated, mention the adoption of buildMasterDataset(), otherwise document the deliberate reason for retaining the inline pipeline and remove references to a "temporary parallel pipeline."
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@delivery-process/specs/architecture-diagram-advanced.feature`:
- Around line 10-26: The problem description block in
architecture-diagram-advanced.feature duplicates the core feature text (the tags
list and Problem/Solution paragraph referencing `@libar-docs-arch-role`,
`@libar-docs-arch-context`, `@libar-docs-arch-layer`), causing maintenance drift;
edit the advanced feature to remove the near‑verbatim copy and replace it with a
focused description tailored to advanced concerns (call out layered diagrams,
generator registry/CLI integration, and sequence/interaction diagrams) while
keeping a short reference to the three annotation tags for context, so the core
feature remains the canonical tag/extraction explanation and advanced highlights
layering, registry, and sequence use cases.
In `@delivery-process/specs/orchestrator-pipeline-factory-migration.feature`:
- Around line 313-318: The "Full verification passes" scenario in
orchestrator-pipeline-factory-migration.feature is declared at feature-level
rather than inside a Rule block; update the file by wrapping the existing
Scenario "Full verification passes" in a Rule: block and add the required
headers (**Invariant:**, **Rationale:**, **Verified by:**) above the Scenario to
match the pattern used in process-api-layered-extraction.feature and maintain
traceability; keep the Scenario text unchanged but indent it under the new Rule
block so docs generation and consistency are preserved.
- Around line 64-78: Remove the triple-backtick/""" code-fenced TypeScript
blocks from the feature description and instead place the PipelineWarning and
PipelineWarningDetail interface definitions as plain inline comments or
reference their source file; specifically, eliminate the """typescript ... """
blocks that contain the PipelineWarning and PipelineWarningDetail declarations
and either convert them to single-line or block comments within the feature text
or add a brief note pointing to the file where those interfaces are defined.
In `@delivery-process/specs/process-api-layered-extraction.feature`:
- Around line 306-312: The "Scenario: Full verification passes" is defined at
the Feature level rather than inside a Rule; to match the project's convention,
wrap that scenario inside a new Rule (e.g., Rule: End-to-end verification
confirms behavioral equivalence) and add the structured headers used elsewhere:
include an **Invariant:** describing the expected outcome, a **Rationale:**
explaining why this end-to-end check is needed, and a **Verified by:** noting
the commands (pnpm build, pnpm test, pnpm lint, pnpm validate:patterns and the
two pnpm process:query checks); move the existing "Full verification passes"
scenario into that Rule so all scenarios are consistently nested and
traceability generation will work.
In `@delivery-process/specs/typescript-taxonomy-implementation.feature`:
- Line 39: The `@acceptance-criteria` tag is only applied to the first scenario
(the line with "@happy-path `@acceptance-criteria`") but the Background table
lists three acceptance criteria; update the feature file so each criterion is
covered by a tagged scenario: add `@acceptance-criteria` to the scenario(s) that
demonstrate "Zod schemas use TypeScript constants" (the scenarios around lines
126–136) and either add a new scenario tagged `@acceptance-criteria` that verifies
"Existing consumers work unchanged" or remove that criterion from the Background
table if it is not applicable; ensure the tag is present on the scenario names
that exercise those behaviors so tracing matches the Background acceptance
criteria.
In `@delivery-process/specs/validator-read-model-consolidation.feature`:
- Line 3: This spec is missing the required unlock tag when set to completed;
update the header to include the `@libar-docs-unlock-reason`:<reason> tag
alongside `@libar-docs-status`:completed (e.g.,
`@libar-docs-unlock-reason`:finalized-spec-review) so future edits aren’t blocked
by the hard-lock; ensure you add the tag exactly as
`@libar-docs-unlock-reason`:<reason> in the
validator-read-model-consolidation.feature header and use a brief, descriptive
reason string.
---
Outside diff comments:
In `@delivery-process/specs/validator-read-model-consolidation.feature`:
- Around line 62-66: Update the DD notes in
validator-read-model-consolidation.feature to reflect the current state: replace
the stale claims that the pipeline factory doesn't exist with a statement that
the shared pipeline factory (extracted by ProcessAPILayeredExtraction /
build-pipeline.ts) is now present, and explicitly state whether the validator
was migrated to use buildMasterDataset() from the factory or intentionally left
using the inline scan-extract-merge-transform pipeline; if migrated, mention the
adoption of buildMasterDataset(), otherwise document the deliberate reason for
retaining the inline pipeline and remove references to a "temporary parallel
pipeline."
delivery-process/specs/orchestrator-pipeline-factory-migration.feature
Outdated
Show resolved
Hide resolved
delivery-process/specs/orchestrator-pipeline-factory-migration.feature
Outdated
Show resolved
Hide resolved
- Tailor architecture-diagram-advanced.feature description to advanced scope instead of duplicating core description verbatim - Replace fragile """typescript blocks in orchestrator-pipeline-factory-migration feature description with references to actual implementation files - Wrap standalone "Full verification passes" scenarios in Rule blocks with structured headers in both orchestrator and process-api specs - Add @acceptance-criteria tags to 3 additional scenarios in typescript-taxonomy-implementation.feature for complete traceability - Dismiss comment 006 (missing unlock-reason): Process Guard exempts transitions TO terminal states per decider.ts:186-189
…c shift Reflect the pipeline factory architecture (buildMasterDataset, mergePatterns, rules-query) across 7 modules. Fix stale references (deleted test files, DoD terminal status). Add undocumented API commands (rules, files, decisions, pdr, arch queries) and replace static handoff template with handoff --pattern.
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@delivery-process/specs/architecture-diagram-advanced.feature`:
- Around line 139-170: Update the "**Verified by:**" header to include the
missing third scenario name so the list matches the three scenarios;
specifically, add "Participant ordering follows architectural layers" alongside
"Generate command flow sequence" and "Generate saga flow sequence" in the
Verified by line referenced in the Rule 7 block (look for the "**Verified by:**"
header and the three Scenario titles: "Generate command flow sequence",
"Generate saga flow sequence", and "Participant ordering follows architectural
layers").
In `@delivery-process/specs/orchestrator-pipeline-factory-migration.feature`:
- Around line 275-296: The feature rule covers both failOnScanErrors=true and
false but only tests the false path; add a new Scenario that verifies the
true/default behavior: reuse the existing Given (codebase with 1 of 10 TS files
having a syntax error), run the factory with failOnScanErrors set to true (or
omit it to rely on the default), and assert the outcome is Result.err (or that
the pipeline returns Result.err on the first scan failure) and that no patterns
are returned; reference the Rule text and the failOnScanErrors flag and mirror
the existing scenario structure (Given/When/Then) so the feature fully covers
both invariant branches.
In `@delivery-process/specs/typescript-taxonomy-implementation.feature`:
- Line 39: The acceptance-criteria tag mapping shows criterion 3 is only
implicitly covered by the scenario titled "buildRegistry returns expected
structure"; make this explicit by either renaming that scenario to mention
consumer backward-compatibility (e.g., include "consumer backward-compatibility"
or "existing generators compatibility" in the scenario title) or add a new
`@acceptance-criteria` scenario whose steps explicitly assert "And all existing
generators work without modification" (reuse that step text) so the traceability
to "Existing consumers work unchanged" is unambiguous; update the scenario title
or add the new scenario in the same feature file next to the existing
"buildRegistry returns expected structure" scenario to preserve context.
Comment on lines
+139
to
+170
| Rule: Sequence diagrams render interaction flows | ||
|
|
||
| **Invariant:** Sequence diagrams must render interaction flows (command flow, | ||
| saga flow) showing step-by-step message passing between components. | ||
|
|
||
| **Rationale:** Component diagrams show structure but not behavior. Sequence | ||
| diagrams show runtime flow - essential for understanding command/saga execution. | ||
|
|
||
| **Verified by:** Generate command flow sequence, Generate saga flow sequence | ||
|
|
||
| @acceptance-criteria @happy-path @future | ||
| Scenario: Generate command flow sequence diagram | ||
| Given a command handler pattern with uses relationships | ||
| When the sequence diagram codec runs with command flow template | ||
| Then output contains mermaid sequenceDiagram | ||
| And participants are derived from uses relationships | ||
| And 7-step CommandOrchestrator flow is rendered | ||
|
|
||
| @acceptance-criteria @happy-path @future | ||
| Scenario: Generate saga flow sequence diagram | ||
| Given a saga pattern with uses relationships to multiple BCs | ||
| When the sequence diagram codec runs with saga flow template | ||
| Then output contains mermaid sequenceDiagram | ||
| And participants include each bounded context | ||
| And compensation steps are shown | ||
|
|
||
| @acceptance-criteria @happy-path @future | ||
| Scenario: Participant ordering follows architectural layers | ||
| Given patterns spanning multiple layers | ||
| When the sequence diagram codec runs | ||
| Then participants are ordered by layer | ||
| And infrastructure layer appears first |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Rule 7 (Sequence Diagram Generation) — appropriate use of @future tag.
The three future scenarios are clearly marked with @future and define expected behaviors for command flow, saga flow, and participant ordering. The **Verified by:** header lists only two scenario names but there are three scenarios — consider adding "Participant ordering follows architectural layers" for completeness.
Proposed fix
- **Verified by:** Generate command flow sequence, Generate saga flow sequence
+ **Verified by:** Generate command flow sequence, Generate saga flow sequence,
+ Participant ordering follows architectural layers🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@delivery-process/specs/architecture-diagram-advanced.feature` around lines
139 - 170, Update the "**Verified by:**" header to include the missing third
scenario name so the list matches the three scenarios; specifically, add
"Participant ordering follows architectural layers" alongside "Generate command
flow sequence" and "Generate saga flow sequence" in the Verified by line
referenced in the Rule 7 block (look for the "**Verified by:**" header and the
three Scenario titles: "Generate command flow sequence", "Generate saga flow
sequence", and "Participant ordering follows architectural layers").
Comment on lines
+275
to
+296
| Rule: Pipeline factory supports partial success mode | ||
|
|
||
| **Invariant:** When `failOnScanErrors` is false, the factory captures | ||
| scan errors and extraction errors as warnings and continues with | ||
| successfully processed files. When true (default), the factory returns | ||
| `Result.err` on the first scan failure. | ||
|
|
||
| **Rationale:** The orchestrator treats scan errors as non-fatal | ||
| warnings — documentation generation should succeed for all scannable | ||
| files even if some files have syntax errors. The process-api treats | ||
| scan errors as fatal because the query layer requires a complete | ||
| dataset. The factory must support both strategies via configuration. | ||
|
|
||
| **Verified by:** Partial success mode works | ||
|
|
||
| @acceptance-criteria | ||
| Scenario: Partial success mode works | ||
| Given a codebase where 1 of 10 TypeScript files has a syntax error | ||
| When the factory runs with failOnScanErrors false | ||
| Then the result is Result.ok with 9 patterns | ||
| And warnings include the scan error for the failing file | ||
| And the pipeline does not return Result.err |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Rule: Pipeline factory supports partial success mode — single scenario may lack edge-case coverage.
The rule's invariant describes two behaviors (failOnScanErrors: true returns Result.err; false captures warnings), but only the false path has a scenario. Consider adding a scenario for the true (default) path to fully verify the invariant.
Proposed additional scenario
And the pipeline does not return Result.err
+
+ `@acceptance-criteria`
+ Scenario: Strict mode fails on scan errors
+ Given a codebase where 1 of 10 TypeScript files has a syntax error
+ When the factory runs with failOnScanErrors true
+ Then the result is Result.err with a PipelineError
+ And the error includes the failing file details🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@delivery-process/specs/orchestrator-pipeline-factory-migration.feature`
around lines 275 - 296, The feature rule covers both failOnScanErrors=true and
false but only tests the false path; add a new Scenario that verifies the
true/default behavior: reuse the existing Given (codebase with 1 of 10 TS files
having a syntax error), run the factory with failOnScanErrors set to true (or
omit it to rely on the default), and assert the outcome is Result.err (or that
the pipeline returns Result.err on the first scan failure) and that no patterns
are returned; reference the Rule text and the failOnScanErrors flag and mirror
the existing scenario structure (Given/When/Then) so the feature fully covers
both invariant branches.
| # ───────────────────────────────────────────────────────────────────────────── | ||
|
|
||
| @happy-path | ||
| @happy-path @acceptance-criteria |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
@acceptance-criteria coverage now addresses the three Background criteria.
The new tags provide the following mapping, resolving the previously flagged gap:
| Background Criterion | Covering Scenario |
|---|---|
| Constants provide compile-time safety | L40 "Define status values as TypeScript constant" |
| Zod schemas use TypeScript constants | L127 "MetadataTagDefinitionSchema uses FORMAT_TYPES" + L134 "Status field validation uses constant" |
| Existing consumers work unchanged | L160 "buildRegistry returns expected structure" (via step And all existing generators work without modification) |
The third criterion is now satisfied, though its coverage is implicit — it rests on a single And step embedded in a scenario whose title ("buildRegistry returns expected structure") emphasises structure rather than consumer compatibility. Consider either renaming the scenario or adding a dedicated @acceptance-criteria scenario specifically titled around consumer backward-compatibility if this traceability link needs to be unambiguous for audit or tooling purposes.
✏️ Optional: make criterion-3 coverage explicit via scenario rename
- `@acceptance-criteria`
- Scenario: buildRegistry returns expected structure
- Given the taxonomy module
- When buildRegistry() is called
- Then it returns the expected TagRegistry structure
- And all existing generators work without modification
+ `@acceptance-criteria`
+ Scenario: Existing consumers work unchanged after taxonomy refactor
+ Given the taxonomy module
+ When buildRegistry() is called
+ Then it returns the expected TagRegistry structure
+ And all existing generators work without modificationAlso applies to: 126-126, 133-133, 159-159
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@delivery-process/specs/typescript-taxonomy-implementation.feature` at line
39, The acceptance-criteria tag mapping shows criterion 3 is only implicitly
covered by the scenario titled "buildRegistry returns expected structure"; make
this explicit by either renaming that scenario to mention consumer
backward-compatibility (e.g., include "consumer backward-compatibility" or
"existing generators compatibility" in the scenario title) or add a new
`@acceptance-criteria` scenario whose steps explicitly assert "And all existing
generators work without modification" (reuse that step text) so the traceability
to "Existing consumers work unchanged" is unambiguous; update the scenario title
or add the new scenario in the same feature file next to the existing
"buildRegistry returns expected structure" scenario to preserve context.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implements ADR-006 — Single Read Model Architecture: the MasterDataset becomes the single read model for all feature consumers. Three specs completed across 12 commits:
validate-patterns.tsfrom a parallel pipeline with lossy local types to MasterDataset consumptionbuild-pipeline.ts) and domain logic (rules-query.ts) from the 1,700-lineprocess-api.tsorchestrator.ts(the original pipeline host) to the shared factory, eliminating the last parallel pipelineAdditionally: split 7 oversized test files into 18 focused files with shared state helpers, fixed DoD terminal status validation, and added Process Guard support for file splits.
Motivation
The MasterDataset is a single-pass O(n) transformer that pre-computes relationship indices, cross-source resolution, status groupings, and dependency graphs. Before this PR, the validator bypassed it entirely — wiring its own mini-pipeline from raw scanner/extractor output, creating a lossy local type (
GherkinPatternInfowith 5 of 30+ fields), and producing 7 false-positive warnings because it couldn't resolve@libar-docs-implementslinks.Three consumers independently wired the same 8-step scan-extract-merge-transform sequence. This is the Parallel Pipeline anti-pattern that ADR-006 names and targets.
Architecture: Before vs After
What Changed (source code, verified)
New Files
src/generators/pipeline/build-pipeline.tsbuildMasterDataset()returningResult<PipelineResult, PipelineError>src/generators/pipeline/merge-patterns.tsmergePatterns()moved from orchestrator — now a pipeline step alongside scan/extract/transformsrc/api/rules-query.tsqueryBusinessRules()extracted fromhandleRules— business rules grouping, annotation parsing, statisticsModified Files
src/cli/validate-patterns.tsMasterDatasetvia pipeline factory. DeletedGherkinPatternInfotype andextractGherkinPatternInfo(). Cross-source matching now usesdataset.relationshipIndexfor implements resolution (DD-3 two-phase approach). Retains direct scans for DoD/anti-pattern checks (stage-1 consumers per ADR-006 exception).src/cli/process-api.tsbuildPipeline()replaced withbuildMasterDataset()call.handleRulesis now a 28-line thin wrapper callingqueryBusinessRules(). No more imports fromscanner/,extractor/, orrenderable/codecs/.src/generators/orchestrator.tsbuildMasterDataset()call.mergePatterns()removed (moved to pipeline module). UsesincludeValidation: falseandfailOnScanErrors: falsefor doc-generation semantics. No more imports fromscanner/orextractor/.src/generators/index.tsmergePatternsre-export updated from./orchestrator.jsto./pipeline/index.jssrc/taxonomy/deliverable-status.tsisDeliverableStatusTerminal()function — returns true forcomplete,n/a,superseded(notdeferred)src/validation/dod-validator.ts'complete'to any terminal status viaisDeliverableStatusTerminal()src/lint/process-guard/decider.tsisNewFile, supporting spec file splitssrc/lint/process-guard/detect-changes.tsunlock-reasontag presence in diff hunks, propagates toStatusTransitionsrc/lint/process-guard/types.tshasUnlockReason?: booleantoStatusTransitioninterface@libar-docs-phasetags fromcontent-deduplicator.ts,file-cache.ts,warning-collector.ts,source-mapping-validator.ts,source-mapper.ts— infrastructure patterns shouldn't carry roadmap phase metadataPipeline Factory Design
The
PipelineOptionsinterface supports all three consumers through configuration:mergeConflictStrategy'fatal''concatenate''fatal'includeValidationtrue(default)true(default)falsefailOnScanErrorstrue(default)true(default)falseexcludeReturns
Result<PipelineResult, PipelineError>so each consumer maps errors to its own strategy (exit, throw, or Result.err).PipelineResultincludes structured warnings (PipelineWarning[]with type discriminator, counts, and file-level details including line/column) plusScanMetadatafor the orchestrator's diagnostic messages.Test File Splits
7 oversized test files (largest: 921 lines) split into 18 focused files with shared state helpers:
ast-parser.feature(921 lines)ast-parser-state.ts(412 lines)reference-codec.feature(588 lines)reference-codec-state.ts(86 lines)process-api.feature(493 lines)process-api-state.ts(325 lines)pr-changes-codec.featurepr-changes-codec-state.ts(612 lines)render.featurerender-state.ts(77 lines)shape-extraction.featureshape-extraction-state.ts(46 lines)lint-rules.featurelint-rules-state.ts(98 lines)Additionally,
architecture-diagram-generation.featurewas renamed toarchitecture-diagram-core.featurewitharchitecture-diagram-advanced.featureextracted as a new file.Spec file splits
delivery-process/specs/architecture-diagram-generation.featurearchitecture-diagram-core.feature(renamed) +architecture-diagram-advanced.feature(new)ADR-006 Anti-Patterns Eliminated
validate-patterns.tslines 32-35,process-api.tsbuildPipeline(),orchestrator.tslines 282-427buildMasterDataset()validate-patterns.tsGherkinPatternInfo(5 of 30+ fields)validate-patterns.tslines 373-384 (name-equality Map)dataset.relationshipIndexorchestrator.tsline 701pipeline/merge-patterns.tsStats
roadmap→active→completed)Test Plan
pnpm build— compiles with zero errorspnpm test— all Gherkin specs pass (18 new split files + existing)pnpm lint— zero warningspnpm validate:patterns— zero errors, zero warnings (was 7 warnings before)pnpm validate:all— all validations pass including DoD and anti-patternspnpm docs:all— documentation generates identicallypnpm process:query -- overview— output unchangedpnpm process:query -- rules— output unchanged (now via rules-query.ts)process-api,validate-patterns,orchestrator) callbuildMasterDataset()frombuild-pipeline.ts— no inline pipeline wiringDecision Spec
delivery-process/decisions/adr-006-single-read-model-architecture.feature— the architectural decision driving all three implementation specs.Summary by CodeRabbit
Documentation
Refactor
Chores