@libar-dev/architect 1.0.0-pre.3 → 1.0.0-pre.4

package/docs-live/product-areas/PROCESS.md

@@ -236,7 +236,7 @@ graph LR
     ValidatorReadModelConsolidation["ValidatorReadModelConsolidation"]
     StepDefinitionCompletion["StepDefinitionCompletion"]
     SessionFileCleanup["SessionFileCleanup"]
-    ProcessAPILayeredExtraction["ProcessAPILayeredExtraction"]
+    PatternGraphLayeredExtraction["PatternGraphLayeredExtraction"]
     OrchestratorPipelineFactoryMigration["OrchestratorPipelineFactoryMigration"]
     MvpWorkflowImplementation["MvpWorkflowImplementation"]
     LivingRoadmapCLI["LivingRoadmapCLI"]
@@ -252,8 +252,8 @@ graph LR
     ValidatorReadModelConsolidation -.->|depends on| ADR006SingleReadModelArchitecture
     StepDefinitionCompletion -.->|depends on| ADR002GherkinOnlyTesting
     SessionFileCleanup -.->|depends on| SessionFileLifecycle
-    ProcessAPILayeredExtraction -.->|depends on| ValidatorReadModelConsolidation
-    OrchestratorPipelineFactoryMigration -.->|depends on| ProcessAPILayeredExtraction
+    PatternGraphLayeredExtraction -.->|depends on| ValidatorReadModelConsolidation
+    OrchestratorPipelineFactoryMigration -.->|depends on| PatternGraphLayeredExtraction
     LivingRoadmapCLI -.->|depends on| MvpWorkflowImplementation
     EffortVarianceTracking -.->|depends on| MvpWorkflowImplementation
     ConfigBasedWorkflowDefinition -.->|depends on| MvpWorkflowImplementation
@@ -295,7 +295,7 @@ graph LR
 | Tier 1 specs are ephemeral working documents | Tier 1 roadmap specs serve planning and delivery tracking. They are not the source of truth for pattern identity, invariants, or acceptance criteria. After completion, they may be archived. | Treating tier 1 specs as durable creates a maintenance burden — at scale only 39% maintain traceability, and duplicated Rules/Scenarios average 200-400 stale lines.           |
 | Three durable artifact types                 | The delivery process produces three artifact types with long-term value. All other artifacts are projections or ephemeral.                                                                    | Without a clear boundary between durable and ephemeral artifacts, teams maintain redundant documents that inevitably drift from the source of truth.                           |
 | Implements is UML Realization (many-to-one)  | `@architect-implements` declares a realization relationship. Multiple files can implement the same pattern. One file can implement multiple patterns (CSV format).                            | Without many-to-one realization, cross-cutting patterns that span multiple files cannot be traced back to a single canonical definition.                                       |
-| Single-definition constraint                 | `@architect-pattern:X` may appear in exactly one file across the entire codebase. The `mergePatterns()` conflict check in `orchestrator.ts` correctly enforces this.                          | Duplicate pattern definitions cause merge conflicts in the MasterDataset and produce ambiguous ownership in generated documentation.                                           |
+| Single-definition constraint                 | `@architect-pattern:X` may appear in exactly one file across the entire codebase. The `mergePatterns()` conflict check in `orchestrator.ts` correctly enforces this.                          | Duplicate pattern definitions cause merge conflicts in the PatternGraph and produce ambiguous ownership in generated documentation.                                            |
 | Reverse links preferred over forward links   | `@architect-implements` (reverse: "I verify this pattern") is the primary traceability mechanism. `@architect-executable-specs` (forward: "my tests live here") is retained but not required. | Forward links in tier 1 specs go stale when specs are archived, while reverse links in test files are self-maintaining because the test cannot run without the implementation. |
 
 ### Cli Behavior Testing

package/docs-live/product-areas/VALIDATION.md

@@ -467,6 +467,36 @@ function detectProcessInCode(
 
 **Returns:** Array of anti-pattern violations
 
+### detectRemovedTags (function)
+
+```typescript
+/**
+ * Detect removed tags in feature files
+ *
+ * Finds tags that were removed from the registry but still appear in source files.
+ * These tags are silently discarded by the scanner, causing data loss without
+ * any diagnostic. This detector makes the failure explicit.
+ *
+ * @param features - Array of scanned feature files
+ * @param registry - Optional tag registry for prefix-aware detection (defaults to @architect-)
+ * @returns Array of anti-pattern violations
+ */
+```
+
+```typescript
+function detectRemovedTags(
+  features: readonly ScannedGherkinFile[],
+  registry?: TagRegistry
+): AntiPatternViolation[];
+```
+
+| Parameter | Type | Description                                                                |
+| --------- | ---- | -------------------------------------------------------------------------- |
+| features  |      | Array of scanned feature files                                             |
+| registry  |      | Optional tag registry for prefix-aware detection (defaults to @architect-) |
+
+**Returns:** Array of anti-pattern violations
+
 ### detectMagicComments (function)
 
 ```typescript
@@ -893,21 +923,6 @@ const severityOrder: Record<LintSeverity, number>;
 const missingPatternName: LintRule;
 ```
 
-### missingStatus (const)
-
-```typescript
-/**
- * Rule: missing-status
- *
- * Patterns should have an explicit status (completed, active, roadmap, deferred).
- * This helps readers understand if the pattern is ready for use.
- */
-```
-
-```typescript
-const missingStatus: LintRule;
-```
-
 ---
 
 ## Business Rules
@@ -1118,11 +1133,11 @@ const missingStatus: LintRule;
 
 ### Validator Read Model Consolidation
 
-| Rule                                                       | Invariant                                                                                                                                                                                         | Rationale                                                                                                                                                                                                                                                                                                                                                     |
-| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Validator queries the read model for cross-source matching | Pattern identity resolution — including implements relationships in both directions — uses `MasterDataset.relationshipIndex` rather than ad-hoc name-equality maps built from raw scanner output. | The MasterDataset computes implementedBy reverse lookups in transform-dataset.ts (second pass, lines 488-546). The validator's current name-equality Map cannot resolve ShapeExtractor -> ShapeExtraction or DecisionDocGeneratorTesting -> DecisionDocGenerator because these are implements relationships, not name matches.                                |
-| No lossy local types in the validator                      | The validator operates on `ExtractedPattern` from the MasterDataset, not a consumer-local DTO that discards fields.                                                                               | GherkinPatternInfo keeps only name, phase, status, file, and deliverables — discarding uses, dependsOn, implementsPatterns, include, productArea, rules, and 20+ other fields. When the validator needs relationship data, it cannot access it through the lossy type.                                                                                        |
-| Utility patterns without specs are not false positives     | Internal utility patterns that have a `@architect-phase` but will never have a Gherkin spec should not carry phase metadata. Phase tags signal roadmap participation.                             | Five utility patterns (ContentDeduplicator, FileCache, WarningCollector, SourceMappingValidator, SourceMapper) have phase tags from the phase when they were built. They are infrastructure, not roadmap features. The validator correctly reports missing Gherkin for patterns with phases — the fix is removing the phase tag, not suppressing the warning. |
+| Rule                                                       | Invariant                                                                                                                                                                                        | Rationale                                                                                                                                                                                                                                                                                                                                                     |
+| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Validator queries the read model for cross-source matching | Pattern identity resolution — including implements relationships in both directions — uses `PatternGraph.relationshipIndex` rather than ad-hoc name-equality maps built from raw scanner output. | The PatternGraph computes implementedBy reverse lookups in transform-dataset.ts (second pass, lines 488-546). The validator's current name-equality Map cannot resolve ShapeExtractor -> ShapeExtraction or DecisionDocGeneratorTesting -> DecisionDocGenerator because these are implements relationships, not name matches.                                 |
+| No lossy local types in the validator                      | The validator operates on `ExtractedPattern` from the PatternGraph, not a consumer-local DTO that discards fields.                                                                               | GherkinPatternInfo keeps only name, phase, status, file, and deliverables — discarding uses, dependsOn, implementsPatterns, include, productArea, rules, and 20+ other fields. When the validator needs relationship data, it cannot access it through the lossy type.                                                                                        |
+| Utility patterns without specs are not false positives     | Internal utility patterns that have a `@architect-phase` but will never have a Gherkin spec should not carry phase metadata. Phase tags signal roadmap participation.                            | Five utility patterns (ContentDeduplicator, FileCache, WarningCollector, SourceMappingValidator, SourceMapper) have phase tags from the phase when they were built. They are infrastructure, not roadmap features. The validator correctly reports missing Gherkin for patterns with phases — the fix is removing the phase tag, not suppressing the warning. |
 
 ### Workflow Config Schemas Validation
 

package/docs-live/reference/ANNOTATION-REFERENCE.md

@@ -64,7 +64,7 @@ List specific declaration names in the file-level JSDoc:
 ```typescript
 /**
  * @architect
- * @architect-extract-shapes MasterDatasetSchema, StatusGroupsSchema
+ * @architect-extract-shapes PatternGraphSchema, StatusGroupsSchema
  */
 ```
 
@@ -103,7 +103,7 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i
 
 | Wrong (type alias)                       | Correct (schema constant)                 |
 | ---------------------------------------- | ----------------------------------------- |
-| `@extract-shapes MasterDataset`          | `@extract-shapes MasterDatasetSchema`     |
+| `@extract-shapes PatternGraph`           | `@extract-shapes PatternGraphSchema`      |
 | Shows: `z.infer<typeof ...>` (unhelpful) | Shows: `z.object({...})` (full structure) |
 
 ---
@@ -115,9 +115,9 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i
 ```typescript
 /**
  * @architect
- * @architect-pattern MasterDataset
+ * @architect-pattern PatternGraph
  * @architect-status completed
- * @architect-extract-shapes MasterDatasetSchema, StatusGroupsSchema, PhaseGroupSchema
+ * @architect-extract-shapes PatternGraphSchema, StatusGroupsSchema, PhaseGroupSchema
  */
 ```
 
@@ -141,7 +141,7 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i
  * @architect-status completed
  * @architect-arch-context generator
  * @architect-arch-layer application
- * @architect-extract-shapes transformToMasterDataset, RuntimeMasterDataset
+ * @architect-extract-shapes transformToPatternGraph, RuntimePatternGraph
  */
 ```
 

package/docs-live/reference/ARCHITECTURE-CODECS.md

@@ -7,7 +7,7 @@
 
 ## ValidationRulesCodec
 
-Transforms MasterDataset into a RenderableDocument for Process Guard validation
+Transforms PatternGraph into a RenderableDocument for Process Guard validation
 rules reference. Generates VALIDATION-RULES.md and detail files (validation/\*.md).
 
 **Purpose:** Process Guard validation rules reference with FSM diagrams and protection level matrix.
@@ -91,7 +91,7 @@ const doc = ValidationRulesCodec.decode(dataset);
 
 ## TaxonomyDocumentCodec
 
-Transforms MasterDataset into a RenderableDocument for taxonomy reference output.
+Transforms PatternGraph into a RenderableDocument for taxonomy reference output.
 Generates TAXONOMY.md and detail files (taxonomy/\*.md).
 
 **Purpose:** Taxonomy reference documentation with tag definitions, preset comparison, and format type reference.
@@ -161,7 +161,7 @@ const doc = TaxonomyDocumentCodec.decode(dataset);
 
 ## RequirementsDocumentCodec
 
-Transforms MasterDataset into RenderableDocument for PRD/requirements output.
+Transforms PatternGraph into RenderableDocument for PRD/requirements output.
 Generates PRODUCT-REQUIREMENTS.md and detail files (requirements/\*.md).
 
 **Purpose:** Product requirements documentation grouped by product area or user role.
@@ -302,7 +302,7 @@ const doc = codec.decode(dataset);
 
 ## PrChangesCodec
 
-Transforms MasterDataset into RenderableDocument for PR-scoped output.
+Transforms PatternGraph into RenderableDocument for PR-scoped output.
 Filters patterns by changed files and/or release version tags.
 
 **Purpose:** PR-scoped view filtered by changed files or release version.
@@ -389,7 +389,7 @@ const doc = codec.decode(dataset);
 
 ## PatternsDocumentCodec
 
-Transforms MasterDataset into a RenderableDocument for pattern registry output.
+Transforms PatternGraph into a RenderableDocument for pattern registry output.
 Generates PATTERNS.md and category detail files (patterns/\*.md).
 
 **Purpose:** Pattern registry with category-based organization.
@@ -429,7 +429,7 @@ const doc = PatternsDocumentCodec.decode(dataset);
 
 ## IndexCodec
 
-**Purpose:** Navigation hub composing editorial preamble with MasterDataset statistics.
+**Purpose:** Navigation hub composing editorial preamble with PatternGraph statistics.
 
 **Output Files:** `INDEX.md` (single page, no detail files)
 
@@ -454,7 +454,7 @@ const doc = PatternsDocumentCodec.decode(dataset);
 
 ## DesignReviewCodec
 
-Transforms MasterDataset into a RenderableDocument containing design review
+Transforms PatternGraph into a RenderableDocument containing design review
 artifacts: sequence diagrams, component diagrams, type definition tables,
 and design question templates.
 
@@ -509,7 +509,7 @@ const doc = composeDocuments([docA, docB], { title: 'Combined' });
 
 ## ClaudeModuleCodec
 
-Transforms MasterDataset into RenderableDocuments for CLAUDE.md module generation.
+Transforms PatternGraph into RenderableDocuments for CLAUDE.md module generation.
 Filters patterns with `claudeModule` tags and generates compact markdown modules
 suitable for the `_claude-md/` directory structure.
 
@@ -537,7 +537,7 @@ const doc = codec.decode(dataset);
 
 ## BusinessRulesCodec
 
-Transforms MasterDataset into a RenderableDocument for business rules output.
+Transforms PatternGraph into a RenderableDocument for business rules output.
 Generates BUSINESS-RULES.md organized by product area, phase, and feature.
 
 **Purpose:** Business rules documentation organized by product area, phase, and feature. Extracts domain constraints from Gherkin Rule: blocks.
@@ -592,7 +592,7 @@ const doc = codec.decode(dataset);
 
 ## ArchitectureDocumentCodec
 
-Transforms MasterDataset into a RenderableDocument containing
+Transforms PatternGraph into a RenderableDocument containing
 architecture diagrams (Mermaid) generated from source annotations.
 
 **Purpose:** Architecture diagrams (Mermaid) generated from source annotations. Supports component and layered views.
@@ -637,7 +637,7 @@ const doc = ArchitectureDocumentCodec.decode(dataset);
 
 ## AdrDocumentCodec
 
-Transforms MasterDataset into RenderableDocument for Architecture Decision Records.
+Transforms PatternGraph into RenderableDocument for Architecture Decision Records.
 Extracts ADRs from patterns with `@architect-adr` tags.
 
 **Purpose:** Architecture Decision Records extracted from patterns with @architect-adr tags.

package/docs-live/reference/ARCHITECTURE-TYPES.md

@@ -7,11 +7,11 @@
 
 ## API Types
 
-### MasterDatasetSchema (const)
+### PatternGraphSchema (const)
 
 ```typescript
 /**
- * Master Dataset - Unified view of all extracted patterns
+ * PatternGraph - Unified view of all extracted patterns
  *
  * Contains raw patterns plus pre-computed views and statistics.
  * This is the primary data structure passed to generators and sections.
@@ -20,7 +20,7 @@
 ```
 
 ```typescript
-MasterDatasetSchema = z.object({
+PatternGraphSchema = z.object({
   // ─────────────────────────────────────────────────────────────────────────
   // Raw Data
   // ─────────────────────────────────────────────────────────────────────────
@@ -52,7 +52,7 @@ MasterDatasetSchema = z.object({
   byCategory: z.record(z.string(), z.array(ExtractedPatternSchema)),
 
   /** Patterns grouped by source type */
-  bySource: SourceViewsSchema,
+  bySourceType: SourceViewsSchema,
 
   /** Patterns grouped by product area (for O(1) product area lookups) */
   byProductArea: z.record(z.string(), z.array(ExtractedPatternSchema)),
@@ -244,13 +244,13 @@ RelationshipEntrySchema = z.object({
 });
 ```
 
-### RuntimeMasterDataset (interface)
+### RuntimePatternGraph (interface)
 
 ```typescript
 /**
- * Runtime MasterDataset with optional workflow
+ * Runtime PatternGraph with optional workflow
  *
- * Extends the Zod-compatible MasterDataset with workflow reference.
+ * Extends the Zod-compatible PatternGraph with workflow reference.
  * LoadedWorkflow contains Maps which aren't JSON-serializable,
  * so it's kept separate from the Zod schema.
  *
@@ -258,7 +258,7 @@ RelationshipEntrySchema = z.object({
 ```
 
 ```typescript
-interface RuntimeMasterDataset extends MasterDataset {
+interface RuntimePatternGraph extends PatternGraph {
   /** Optional workflow configuration (not serializable) */
   readonly workflow?: LoadedWorkflow;
 }
@@ -304,7 +304,7 @@ interface RawDataset {
 
 ```typescript
 /**
- * Options for building a MasterDataset via the shared pipeline.
+ * Options for building a PatternGraph via the shared pipeline.
  *
  * DD-1: Factory lives at src/generators/pipeline/build-pipeline.ts.
  * DD-2: mergeConflictStrategy controls per-consumer conflict handling.
@@ -327,13 +327,16 @@ interface PipelineOptions {
   readonly includeValidation?: boolean;
   /** DD-5: When true, return error on individual scan failures (default false). */
   readonly failOnScanErrors?: boolean;
+  /** Pre-loaded tag registry. When provided, skips internal config load (Step 1). */
+  readonly tagRegistry?: TagRegistry;
 }
 ```
 
-| Property          | Description                                                                |
-| ----------------- | -------------------------------------------------------------------------- |
-| includeValidation | DD-3: When false, skip validation pass (default true).                     |
-| failOnScanErrors  | DD-5: When true, return error on individual scan failures (default false). |
+| Property          | Description                                                                  |
+| ----------------- | ---------------------------------------------------------------------------- |
+| includeValidation | DD-3: When false, skip validation pass (default true).                       |
+| failOnScanErrors  | DD-5: When true, return error on individual scan failures (default false).   |
+| tagRegistry       | Pre-loaded tag registry. When provided, skips internal config load (Step 1). |
 
 ### PipelineResult (interface)
 
@@ -346,7 +349,7 @@ interface PipelineOptions {
 
 ```typescript
 interface PipelineResult {
-  readonly dataset: RuntimeMasterDataset;
+  readonly dataset: RuntimePatternGraph;
   readonly validation: ValidationSummary;
   readonly warnings: readonly PipelineWarning[];
   readonly scanMetadata: ScanMetadata;
@@ -363,11 +366,11 @@ interface PipelineResult {
 
 ---
 
-## Steps 1-8 via buildMasterDataset()
+## Steps 1-8 via buildPatternGraph()
 
 Steps 1-8 (config load, TypeScript/Gherkin scan + extraction, merge, hierarchy
-derivation, workflow load, and `transformToMasterDataset`) are delegated to
-`buildMasterDataset()`.
+derivation, workflow load, and `transformToPatternGraph`) are delegated to
+`buildPatternGraph()`.
 
 ---
 
@@ -387,7 +390,7 @@ policy, and persisted file writes).
 
 ## Shared Pipeline Factory Responsibilities
 
-**Invariant:** `buildMasterDataset()` is the shared factory for Steps 1-8 of the architecture pipeline and returns `Result<PipelineResult, PipelineError>` without process-level side effects.
+**Invariant:** `buildPatternGraph()` is the shared factory for Steps 1-8 of the architecture pipeline and returns `Result<PipelineResult, PipelineError>` without process-level side effects.
 
 **Rationale:** Centralizing scan/extract/merge/transform flow prevents divergence between CLI consumers and preserves a single ADR-006 read-model path.
 
@@ -397,37 +400,37 @@ policy, and persisted file writes).
 
 The factory owns: configuration load, TypeScript scan + extraction, Gherkin scan +
 extraction, merge conflict handling, hierarchy child derivation, workflow load,
-and `transformToMasterDataset` with validation summary.
+and `transformToPatternGraph` with validation summary.
 
 ---
 
 ## Consumer Architecture and PipelineOptions Differentiation
 
-Three consumers share this factory: `process-api`, `validate-patterns`, and the
+Three consumers share this factory: `pattern-graph-cli`, `validate-patterns`, and the
 generation orchestrator. `PipelineOptions` differentiates behavior by
 `mergeConflictStrategy` (`fatal` vs `concatenate`), `includeValidation` toggles,
 and `failOnScanErrors` policy without forking pipeline logic.
 
 ### When to Use
 
-- Any consumer needs a MasterDataset without rewriting scan/extract/merge flow
+- Any consumer needs a PatternGraph without rewriting scan/extract/merge flow
 - CLI consumers require differentiated conflict strategy and validation behavior
 - Orchestrator needs a shared steps 1-8 implementation before codec/file execution
 
 ---
 
-## MasterDataset View Fan-out
+## PatternGraph View Fan-out
 
-Pre-computed view fan-out from MasterDataset (single-pass transform):
+Pre-computed view fan-out from PatternGraph (single-pass transform):
 
 ```mermaid
 graph TB
-    MD[MasterDataset]
+    MD[PatternGraph]
     MD --> byStatus["byStatus<br/>(completed / active / planned)"]
     MD --> byPhase["byPhase<br/>(sorted, with counts)"]
     MD --> byQuarter["byQuarter<br/>(keyed by Q-YYYY)"]
     MD --> byCategory["byCategory<br/>(keyed by category name)"]
-    MD --> bySource["bySource<br/>(typescript / gherkin / roadmap / prd)"]
+    MD --> bySourceType["bySourceType<br/>(typescript / gherkin / roadmap / prd)"]
     MD --> counts["counts<br/>(aggregate statistics)"]
     MD --> RI["relationshipIndex?<br/>(forward + reverse lookups)"]
     MD --> AI["archIndex?<br/>(role / context / layer / view)"]

package/docs-live/reference/{PROCESS-API-RECIPES.md → CLI-RECIPES.md}

@@ -1,6 +1,6 @@
-# Process API CLI — Recipes & Workflow Guide
+# Pattern Graph CLI Recipes & Workflow Guide
 
-> Auto-generated from CLI schema. See [CLI Reference](./PROCESS-API-REFERENCE.md) for flag tables.
+> Auto-generated from CLI schema. See [CLI Reference](./CLI-REFERENCE.md) for flag tables.
 
 ## Why Use This
 
@@ -35,7 +35,7 @@ Example `overview` output:
 318 patterns (224 completed, 47 active, 47 planned) = 70%
 
 === ACTIVE PHASES ===
-Phase 24: ProcessStateAPIRelationshipQueries (1 active)
+Phase 24: PatternGraphAPIRelationshipQueries (1 active)
 Phase 25: DataAPIStubIntegration (1 active)
 
 === BLOCKING ===
@@ -79,7 +79,7 @@ Example output:
 318 patterns (224 completed, 47 active, 47 planned) = 70%
 
 === ACTIVE PHASES ===
-Phase 24: ProcessStateAPIRelationshipQueries (1 active)
+Phase 24: PatternGraphAPIRelationshipQueries (1 active)
 Phase 25: DataAPIStubIntegration (1 active)
 
 === BLOCKING ===
@@ -130,20 +130,20 @@ Example output:
 Status: active | Category: pattern
 ## ContextAssembler — Session-Oriented Context Bundle Builder
 
-Pure function composition over MasterDataset.
+Pure function composition over PatternGraph.
 File: src/api/context-assembler.ts
 
 === DEPENDENCIES ===
-[active] ProcessStateAPI (implementation) src/api/process-state.ts
-[completed] MasterDataset (implementation) src/validation-schemas/master-dataset.ts
+[active] PatternGraphAPI (implementation) src/api/pattern-graph-api.ts
+[completed] PatternGraph (implementation) src/validation-schemas/pattern-graph.ts
 
 === CONSUMERS ===
 ContextFormatterImpl (active)
-ProcessAPICLIImpl (active)
+PatternGraphCLIImpl (active)
 
 === ARCHITECTURE (context: api) ===
-MasterDataset (completed, read-model)
-ProcessStateAPI (active, service)
+PatternGraph (completed, read-model)
+PatternGraphAPI (active, service)
 ...
 ```
 
@@ -169,7 +169,7 @@ Example output:
 
 ```
 === PRIMARY ===
-src/cli/process-api.ts
+src/cli/pattern-graph-cli.ts
 
 === ARCHITECTURE NEIGHBORS ===
 src/cli/version.ts

package/docs-live/reference/{PROCESS-API-REFERENCE.md → CLI-REFERENCE.md}

@@ -1,6 +1,6 @@
-# Process API CLI Reference
+# Pattern Graph CLI Reference
 
-> Auto-generated from CLI schema. See [Process API Guide](../../docs/PROCESS-API.md) for usage examples and recipes.
+> Auto-generated from CLI schema. See [CLI Recipes & Workflow Guide](../../docs-live/reference/CLI-RECIPES.md) for usage examples and recipes.
 
 ## Global Options