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

package/docs-live/business-rules/generation.md

@@ -4,7 +4,7 @@
 
 ---
 
-**302 rules** from 61 features. 302 rules have explicit invariants.
+**312 rules** from 62 features. 312 rules have explicit invariants.
 
 ---
 
@@ -362,17 +362,17 @@ _Validates that ARCHITECTURE.md retains its full reference content and that_
 
 ---
 
-#### MasterDataset shapes appear in ARCHITECTURE-TYPES reference
+#### PatternGraph shapes appear in ARCHITECTURE-TYPES reference
 
-> **Invariant:** The ARCHITECTURE-TYPES.md reference document contains core MasterDataset types (MasterDataset, RuntimeMasterDataset, RawDataset) and pipeline types (PipelineOptions, PipelineResult) extracted from shape annotations.
+> **Invariant:** The ARCHITECTURE-TYPES.md reference document contains core PatternGraph types (PatternGraph, RuntimePatternGraph, RawDataset) and pipeline types (PipelineOptions, PipelineResult) extracted from shape annotations.
 >
 > **Rationale:** Type shapes are the structural backbone of the pipeline. Generating their documentation from annotations ensures the reference always matches the actual TypeScript interfaces, eliminating manual drift.
 
 **Verified by:**
 
-- Core MasterDataset types appear in ARCHITECTURE-TYPES
+- Core PatternGraph types appear in ARCHITECTURE-TYPES
 - Pipeline types appear in ARCHITECTURE-TYPES reference
-- Unified Transformation section has full MasterDataset content
+- Unified Transformation section has full PatternGraph content
 
 ---
 
@@ -554,7 +554,7 @@ _arch-tag-extraction.feature_
 
 ### Business Rules Document Codec
 
-_Tests the BusinessRulesCodec transformation from MasterDataset to RenderableDocument._
+_Tests the BusinessRulesCodec transformation from PatternGraph to RenderableDocument._
 
 ---
 
@@ -709,12 +709,11 @@ _Tests the CodecBasedGenerator which adapts the RenderableDocument Model (RDM)_
 
 > **Invariant:** CodecBasedGenerator delegates document generation to the underlying codec and surfaces codec errors through the generator interface.
 >
-> **Rationale:** The adapter pattern enables codec-based rendering to integrate with the existing orchestrator without modifying either side.
+> **Rationale:** The adapter pattern enables codec-based rendering to integrate with the existing orchestrator without modifying either side. PatternGraph is required in context — enforced by the TypeScript type system, not at runtime.
 
 **Verified by:**
 
 - Generator delegates to codec
-- Missing MasterDataset returns error
 - Codec options are passed through
 
 _codec-based.feature_
@@ -1004,7 +1003,7 @@ _content-deduplication.feature_
 
 ### Convention Extractor
 
-_Extracts convention content from MasterDataset decision records_
+_Extracts convention content from PatternGraph decision records_
 
 ---
 
@@ -1477,7 +1476,7 @@ _Tests the full design review generation pipeline: sequence annotations are_
 
 > **Invariant:** buildSequenceIndexEntry produces a SequenceIndexEntry with steps sorted by stepNumber, participants deduplicated with orchestrator first, and data flow types collected from Input/Output annotations.
 >
-> **Rationale:** Pre-computing in the transform pass avoids repeated parsing in the codec. ADR-006 mandates the MasterDataset as the sole read model.
+> **Rationale:** Pre-computing in the transform pass avoids repeated parsing in the codec. ADR-006 mandates the PatternGraph as the sole read model.
 
 **Verified by:**
 
@@ -1612,7 +1611,7 @@ _Tests the full design review generation pipeline: sequence annotations are_
 
 #### Process API sequence lookup resolves pattern names case-insensitively
 
-> **Invariant:** The sequence subcommand resolves pattern names with the same case-insensitive matching behavior as other pattern-oriented process-api queries.
+> **Invariant:** The sequence subcommand resolves pattern names with the same case-insensitive matching behavior as other pattern-oriented pattern-graph queries.
 >
 > **Rationale:** Design review consumers should not need exact display-name casing when querying sequence data from the CLI.
 
@@ -1905,6 +1904,159 @@ _Links to implementation files in generated pattern documents should have_
 
 _implementation-links.feature_
 
+### Index Codec
+
+_Validates the Index Codec that transforms PatternGraph into a_
+
+---
+
+#### Document metadata is correctly set
+
+> **Invariant:** The index document must have the title "Documentation Index", a purpose string referencing @libar-dev/architect, and all sections enabled when using default options.
+>
+> **Rationale:** Document metadata drives navigation and table of contents generation — incorrect titles or missing purpose strings produce broken index pages in generated doc sites.
+
+**Verified by:**
+
+- Document title is Documentation Index
+- Document purpose references @libar-dev/architect
+- Default options produce all sections
+
+---
+
+#### Package metadata section renders correctly
+
+> **Invariant:** The Package Metadata section must always render a table with hardcoded fields: Package (@libar-dev/architect), Purpose, Patterns count derived from dataset, Product Areas count derived from dataset, and License (MIT).
+>
+> **Rationale:** Package metadata provides readers with an instant snapshot of the project — hardcoded fields ensure consistent branding while dataset-derived counts stay accurate.
+
+**Verified by:**
+
+- Package name shows @libar-dev/architect
+- Purpose shows context engineering platform description
+- License shows MIT
+- Pattern counts reflect dataset
+- Product area count reflects dataset
+- Package metadata section can be disabled
+
+---
+
+#### Document inventory groups entries by topic
+
+> **Invariant:** When documentEntries is non-empty and includeDocumentInventory is true, entries must be grouped by topic with one H3 sub-heading and one table per topic group. When entries are empty, no inventory section is rendered.
+>
+> **Rationale:** A flat list of all documents becomes unnavigable beyond a small count — topic grouping gives readers a structured entry point into the documentation set.
+
+**Verified by:**
+
+- Empty entries produces no inventory section
+- Entries grouped by topic produce per-topic tables
+- Inventory section can be disabled
+
+---
+
+#### Product area statistics are computed from dataset
+
+> **Invariant:** The Product Area Statistics table must list each product area alphabetically with Patterns, Completed, Active, Planned, and Progress columns, plus a bolded Total row aggregating all areas. The progress column must contain a visual progress bar and percentage.
+>
+> **Rationale:** Product area statistics give team leads a cross-cutting view of work distribution — alphabetical order and a total row enable fast scanning and aggregate assessment.
+
+**Verified by:**
+
+- Product area table includes all areas alphabetically
+- Total row aggregates all areas
+- Progress bar and percentage are computed
+- Product area stats can be disabled
+
+---
+
+#### Phase progress summarizes pattern status
+
+> **Invariant:** The Phase Progress section must render a summary paragraph with total, completed, active, and planned counts, a status distribution table with Status/Count/Percentage columns, and — when patterns have phase numbers — a "By Phase" sub-section with a per-phase breakdown table.
+>
+> **Rationale:** Phase progress is the primary indicator of delivery health — the summary paragraph provides instant context while the distribution table enables deeper analysis.
+
+**Verified by:**
+
+- Phase progress shows total counts
+- Status distribution table shows completed/active/planned
+- Per-phase breakdown appears when phases exist
+- Phase progress can be disabled
+
+---
+
+#### Regeneration footer contains commands
+
+> **Invariant:** The Regeneration section must always be present (it is not optional), must contain the heading "Regeneration", and must include at least one code block with pnpm commands.
+>
+> **Rationale:** The regeneration footer ensures consumers always know how to rebuild the docs — it is unconditional so it cannot be accidentally omitted.
+
+**Verified by:**
+
+- Regeneration section has heading "Regeneration"
+- Code blocks contain pnpm commands
+
+---
+
+#### Section ordering follows layout contract
+
+> **Invariant:** Sections must appear in this fixed order: Package Metadata, preamble (if any), Document Inventory (if any), Product Area Statistics, Phase Progress, Regeneration. Separators must appear after each non-final section group. This order is the layout contract for INDEX.md.
+>
+> **Rationale:** Consumers depend on a predictable INDEX.md structure for navigation links — reordering sections would break existing bookmarks and tool-generated cross-references.
+
+**Verified by:**
+
+- Default layout order is metadata, stats, progress, regeneration
+- Preamble appears after metadata and before inventory
+- Separators appear between sections
+- Default layout order is metadata
+- stats
+- progress
+- regeneration
+
+---
+
+#### Custom purpose text overrides default
+
+> **Invariant:** When purposeText is set to a non-empty string, the document purpose must use that string instead of the auto-generated default. When purposeText is empty or omitted, the auto-generated purpose is used.
+>
+> **Rationale:** Consumers with different documentation sets need to customize the navigation purpose without post-processing the generated output.
+
+**Verified by:**
+
+- purposeText replaces auto-generated purpose
+- Empty purposeText uses auto-generated purpose
+
+---
+
+#### Epilogue replaces regeneration footer
+
+> **Invariant:** When epilogue sections are provided, they completely replace the built-in regeneration footer. When epilogue is empty, the regeneration footer is rendered as before.
+>
+> **Rationale:** Consumers may need a custom footer (e.g., links to CI, contribution guides) that has nothing to do with regeneration commands.
+
+**Verified by:**
+
+- Epilogue replaces built-in footer
+- Empty epilogue preserves regeneration footer
+
+---
+
+#### Package metadata overrides work
+
+> **Invariant:** When packageMetadataOverrides provides a value for name, purpose, or license, that value replaces the corresponding default or projectMetadata value in the Package Metadata table. Unset override keys fall through to the default chain.
+>
+> **Rationale:** Consumers reusing the IndexCodec for different packages need to override individual metadata fields without providing a full projectMetadata object.
+
+**Verified by:**
+
+- Name override replaces package name
+- Purpose override replaces purpose
+- License override replaces license
+- Unset overrides fall through to defaults
+
+_index-codec.feature_
+
 ### Layered Diagram Generation
 
 _As a documentation generator_
@@ -3111,12 +3263,12 @@ _Scoped diagram generation from diagramScopes config, including archContext,_
 
 > **Invariant:** Hardcoded diagram sources render without relationship-scoping input and emit stable, source-specific Mermaid content.
 >
-> **Rationale:** Domain diagrams such as pipeline and MasterDataset fan-out encode canonical architecture views that should not depend on ad-hoc test dataset shape.
+> **Rationale:** Domain diagrams such as pipeline and PatternGraph fan-out encode canonical architecture views that should not depend on ad-hoc test dataset shape.
 
 **Verified by:**
 
-- master-dataset-views source produces MasterDataset fan-out diagram
-- master-dataset-views source renders expected fan-out nodes
+- pattern-graph-views source produces PatternGraph fan-out diagram
+- pattern-graph-views source renders expected fan-out nodes
 
 ---
 
@@ -3636,7 +3788,7 @@ _- Need to generate product requirements documents with flexible groupings_
 
 #### RequirementsDocumentCodec generates PRD-style documentation from patterns
 
-> **Invariant:** RequirementsDocumentCodec transforms MasterDataset patterns into a PRD-style document with flexible grouping (product area, user role, or phase), optional detail file generation, and business value rendering.
+> **Invariant:** RequirementsDocumentCodec transforms PatternGraph patterns into a PRD-style document with flexible grouping (product area, user role, or phase), optional detail file generation, and business value rendering.
 >
 > **Rationale:** Flexible grouping lets stakeholders view requirements through their preferred lens (area, role, or phase), and detail files provide deep-dive context without bloating the summary document.
 
@@ -3659,7 +3811,7 @@ _- Need to generate product requirements documents with flexible groupings_
 
 #### AdrDocumentCodec documents architecture decisions
 
-> **Invariant:** AdrDocumentCodec transforms MasterDataset ADR patterns into an architecture decision record document with status tracking, category/phase/date grouping, supersession relationships, and optional detail file generation.
+> **Invariant:** AdrDocumentCodec transforms PatternGraph ADR patterns into an architecture decision record document with status tracking, category/phase/date grouping, supersession relationships, and optional detail file generation.
 >
 > **Rationale:** Architecture decisions lose value without status tracking and supersession chains; without them, teams act on outdated decisions and cannot trace why a previous approach was abandoned.
 
@@ -4165,7 +4317,7 @@ _table-extraction.feature_
 
 ### Taxonomy Codec
 
-_Validates the Taxonomy Codec that transforms MasterDataset into a_
+_Validates the Taxonomy Codec that transforms PatternGraph into a_
 
 ---
 
@@ -4333,7 +4485,7 @@ _- Generators need multiple views of the same pattern data_
 
 #### Empty dataset produces valid zero-state views
 
-> **Invariant:** An empty input produces a MasterDataset with all counts at zero and no groupings.
+> **Invariant:** An empty input produces a PatternGraph with all counts at zero and no groupings.
 >
 > **Rationale:** Generators must handle the zero-state gracefully; a missing or malformed empty dataset would cause null-reference errors across all rendering codecs.
 
@@ -4418,7 +4570,7 @@ _- Generators need multiple views of the same pattern data_
 
 #### Workflow integration conditionally includes delivery process data
 
-> **Invariant:** The workflow is included in the MasterDataset only when provided, and phase names are resolved from the workflow configuration.
+> **Invariant:** The workflow is included in the PatternGraph only when provided, and phase names are resolved from the workflow configuration.
 >
 > **Rationale:** Projects without a delivery workflow must still produce valid datasets; unconditionally requiring workflow data would break standalone documentation generation.
 
@@ -4431,7 +4583,7 @@ _transform-dataset.feature_
 
 ### Validation Rules Codec
 
-_Validates the Validation Rules Codec that transforms MasterDataset into a_
+_Validates the Validation Rules Codec that transforms PatternGraph into a_
 
 ---
 

package/docs-live/decisions/adr-003-source-first-pattern-architecture.md

@@ -112,7 +112,7 @@ artifacts are annotated source code, executable specs, and decision specs.
 
 **Invariant:** `@architect-pattern:X` may appear in exactly one file across the entire codebase. The `mergePatterns()` conflict check in `orchestrator.ts` correctly enforces this.
 
-**Rationale:** Duplicate pattern definitions cause merge conflicts in the MasterDataset and produce ambiguous ownership in generated documentation.
+**Rationale:** Duplicate pattern definitions cause merge conflicts in the PatternGraph and produce ambiguous ownership in generated documentation.
 
 | Current State                   | Resolution                                      |
 | ------------------------------- | ----------------------------------------------- |

package/docs-live/decisions/adr-005-codec-based-markdown-rendering.md

@@ -13,7 +13,7 @@
 
 **Context:**
 The documentation generator needs to transform structured pattern data
-(MasterDataset) into markdown files. The initial approach used direct
+(PatternGraph) into markdown files. The initial approach used direct
 string concatenation in generator functions, mixing data selection,
 formatting logic, and output assembly in a single pass. This made
 generators hard to test, difficult to compose, and impossible to
@@ -22,7 +22,7 @@ AI context).
 
 **Decision:**
 Adopt a codec architecture inspired by serialization codecs (encode/decode).
-Each document type has a codec that decodes a MasterDataset into a
+Each document type has a codec that decodes a PatternGraph into a
 RenderableDocument — an intermediate representation of sections, headings,
 tables, paragraphs, and code blocks. A separate renderer transforms the
 RenderableDocument into markdown. This separates data selection (what to
@@ -52,15 +52,15 @@ include) from formatting (how it looks) from serialization (markdown syntax).
 
 ### Codecs implement a decode-only contract
 
-**Invariant:** Every codec is a pure function that accepts a MasterDataset and returns a RenderableDocument. Codecs do not perform side effects, do not write files, and do not access the filesystem. The codec contract is decode-only because the transformation is one-directional: structured data becomes a document, never the reverse.
+**Invariant:** Every codec is a pure function that accepts a PatternGraph and returns a RenderableDocument. Codecs do not perform side effects, do not write files, and do not access the filesystem. The codec contract is decode-only because the transformation is one-directional: structured data becomes a document, never the reverse.
 
-**Rationale:** Pure functions are deterministic and trivially testable. For the same MasterDataset, a codec always produces the same RenderableDocument. This makes snapshot testing reliable and enables codec output comparison across versions.
+**Rationale:** Pure functions are deterministic and trivially testable. For the same PatternGraph, a codec always produces the same RenderableDocument. This makes snapshot testing reliable and enables codec output comparison across versions.
 
 **Codec call signature:**
 
 ```typescript
 interface DocumentCodec {
-  decode(dataset: MasterDataset): RenderableDocument;
+  decode(dataset: PatternGraph): RenderableDocument;
 }
 ```
 

package/docs-live/decisions/adr-006-single-read-model-architecture.md

@@ -14,26 +14,26 @@
 **Context:**
 The Architect package applies event sourcing to itself: git is
 the event store, annotated source files are authoritative state, generated
-documentation is a projection. The MasterDataset is the read model —
+documentation is a projection. The PatternGraph is the read model —
 produced by a single-pass O(n) transformer with pre-computed views
 and a relationship index.
 
-ADR-005 established that codecs consume MasterDataset as their sole input.
-The ProcessStateAPI consumes it. But the validation layer bypasses it,
+ADR-005 established that codecs consume PatternGraph as their sole input.
+The PatternGraphAPI consumes it. But the validation layer bypasses it,
 wiring its own mini-pipeline from raw scanner/extractor output. It creates
 a lossy local type that discards relationship data, then discovers it
 lacks the information needed — requiring ad-hoc re-derivation of what
-the MasterDataset already computes.
+the PatternGraph already computes.
 
-This is the same class of problem the MasterDataset was created to solve.
+This is the same class of problem the PatternGraph was created to solve.
 Before the single-pass transformer, each generator called `.filter()`
-independently. The MasterDataset eliminated that duplication for codecs.
+independently. The PatternGraph eliminated that duplication for codecs.
 This ADR extends the same principle to all consumers.
 
 **Decision:**
-The MasterDataset is the single read model for all consumers. No consumer
+The PatternGraph is the single read model for all consumers. No consumer
 re-derives pattern data from raw scanner/extractor output when that data
-is available in the MasterDataset. Validators, codecs, and query APIs
+is available in the PatternGraph. Validators, codecs, and query APIs
 consume the same pre-computed read model.
 
 **Consequences:**
@@ -42,27 +42,27 @@ consume the same pre-computed read model.
 | -------- | ---------------------------------------------------------------------------------------------- |
 | Positive | Relationship resolution happens once — no consumer re-derives implements, uses, or dependsOn   |
 | Positive | Eliminates lossy local types that discard fields from canonical ExtractedPattern               |
-| Positive | Validation rules automatically benefit from new MasterDataset views and indices                |
+| Positive | Validation rules automatically benefit from new PatternGraph views and indices                 |
 | Positive | Aligns with the monorepo's own ADR-006: projections for all reads, never query aggregate state |
 | Negative | Validators that today only need stage 1-2 data will import the transformer                     |
-| Negative | MasterDataset schema changes affect more consumers                                             |
+| Negative | PatternGraph schema changes affect more consumers                                              |
 
 ## Rules
 
 ### All feature consumers query the read model, not raw state
 
-**Invariant:** Code that needs pattern relationships, status groupings, cross-source resolution, or dependency information consumes the MasterDataset. Direct scanner/extractor imports are permitted only in pipeline orchestration code that builds the MasterDataset.
+**Invariant:** Code that needs pattern relationships, status groupings, cross-source resolution, or dependency information consumes the PatternGraph. Direct scanner/extractor imports are permitted only in pipeline orchestration code that builds the PatternGraph.
 
-**Rationale:** Bypassing the read model forces consumers to re-derive data that the MasterDataset already computes, creating duplicate logic and divergent behavior when the pipeline evolves.
+**Rationale:** Bypassing the read model forces consumers to re-derive data that the PatternGraph already computes, creating duplicate logic and divergent behavior when the pipeline evolves.
 
-| Layer                  | May Import                       | Examples                                            |
-| ---------------------- | -------------------------------- | --------------------------------------------------- |
-| Pipeline Orchestration | scanner/, extractor/, pipeline/  | orchestrator.ts, process-api.ts pipeline setup      |
-| Feature Consumption    | MasterDataset, relationshipIndex | codecs, ProcessStateAPI, validators, query handlers |
+| Layer                  | May Import                      | Examples                                             |
+| ---------------------- | ------------------------------- | ---------------------------------------------------- |
+| Pipeline Orchestration | scanner/, extractor/, pipeline/ | orchestrator.ts, pattern-graph-cli.ts pipeline setup |
+| Feature Consumption    | PatternGraph, relationshipIndex | codecs, PatternGraphAPI, validators, query handlers  |
 
 **Verified by:**
 
-- Feature consumers import from MasterDataset not from raw pipeline stages
+- Feature consumers import from PatternGraph not from raw pipeline stages
 
   Exception: `lint-patterns.ts` is a pure stage-1 consumer. It validates
   annotation syntax on scanned files. No relationships
@@ -74,21 +74,21 @@ consume the same pre-computed read model.
 
 **Invariant:** Consumers do not define local DTOs that duplicate and discard fields from ExtractedPattern. If a consumer needs a subset, the type system provides the projection — not a hand-written extraction function that becomes a barrier between the consumer and canonical data.
 
-**Rationale:** Lossy local types silently drop fields that later become needed, causing bugs that only surface when new MasterDataset capabilities are added and the local type lacks them.
+**Rationale:** Lossy local types silently drop fields that later become needed, causing bugs that only surface when new PatternGraph capabilities are added and the local type lacks them.
 
 **Verified by:**
 
-- Feature consumers import from MasterDataset not from raw pipeline stages
+- Feature consumers import from PatternGraph not from raw pipeline stages
 
 ### Relationship resolution is computed once
 
-**Invariant:** Forward relationships (uses, dependsOn, implementsPatterns) and reverse lookups (usedBy, implementedBy, extendedBy) are computed in `transformToMasterDataset()`. No consumer re-derives these from raw pattern arrays or scanned file tags.
+**Invariant:** Forward relationships (uses, dependsOn, implementsPatterns) and reverse lookups (usedBy, implementedBy, extendedBy) are computed in `transformToPatternGraph()`. No consumer re-derives these from raw pattern arrays or scanned file tags.
 
 **Rationale:** Re-deriving relationships in consumers duplicates the resolution logic and risks inconsistency when different consumers implement subtly different traversal or filtering rules.
 
 **Verified by:**
 
-- Feature consumers import from MasterDataset not from raw pipeline stages
+- Feature consumers import from PatternGraph not from raw pipeline stages
 
 ### Three named anti-patterns
 
@@ -106,7 +106,7 @@ consume the same pre-computed read model.
 
 ```typescript
 // Good: consume the read model
-    function validateCrossSource(dataset: RuntimeMasterDataset): ValidationSummary {
+    function validateCrossSource(dataset: RuntimePatternGraph): ValidationSummary {
       const rel = dataset.relationshipIndex[patternName];
       const isImplemented = rel.implementedBy.length > 0;
     }
@@ -121,12 +121,12 @@ consume the same pre-computed read model.
 **References**
 
     - Monorepo ADR-006: Projections for All Reads (same principle, application domain)
-    - ADR-005: Codec-Based Markdown Rendering (established MasterDataset as codec input)
+    - ADR-005: Codec-Based Markdown Rendering (established PatternGraph as codec input)
     - Order-management ARCHITECTURE.md: CommandOrchestrator + Read Model separation
 
 **Verified by:**
 
-- Feature consumers import from MasterDataset not from raw pipeline stages
+- Feature consumers import from PatternGraph not from raw pipeline stages
 
   Naming them makes them visible in code review — including AI-assisted
   sessions where the default proposal is often "add a helper function."

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

@@ -198,12 +198,6 @@ interface CategoryDefinition {
 | description | Brief description of the category's purpose and typical patterns                  |
 | aliases     | Alternative tag names that map to this category (e.g., "es" for "event-sourcing") |
 
-### TagDefinition (type)
-
-```typescript
-type TagDefinition = MetadataTagDefinitionForRegistry;
-```
-
 ### CategoryTag (type)
 
 ```typescript
@@ -231,6 +225,22 @@ type CategoryTag = (typeof CATEGORIES)[number]['tag'];
 function buildRegistry(): TagRegistry;
 ```
 
+### isShapeOnlyDirective (function)
+
+```typescript
+/**
+ * Check if a directive is a shape-only annotation (declaration-level @architect-shape).
+ *
+ * Shape directives annotate individual interfaces/types for documentation extraction.
+ * They inherit context from a parent pattern and should not enter the directive pipeline
+ * as standalone patterns.
+ */
+```
+
+```typescript
+function isShapeOnlyDirective(directive: DocDirective, registry: TagRegistry): boolean;
+```
+
 ### METADATA_TAGS_BY_GROUP (const)
 
 ```typescript
@@ -239,7 +249,7 @@ function buildRegistry(): TagRegistry;
  * Used for documentation generation to create organized sections.
  *
  * Groups:
- * - core: Essential pattern identification (pattern, status, core, usecase, brief)
+ * - core: Essential pattern identification (pattern, status, usecase)
  * - relationship: Pattern dependencies and connections
  * - process: Timeline and assignment tracking
  * - prd: Product requirements documentation
@@ -255,7 +265,7 @@ function buildRegistry(): TagRegistry;
 
 ```typescript
 METADATA_TAGS_BY_GROUP = {
-  core: ['pattern', 'status', 'core', 'usecase', 'brief'] as const,
+  core: ['pattern', 'status', 'usecase'] as const,
   relationship: [
     'uses',
     'used-by',
@@ -521,7 +531,7 @@ CATEGORY_TAGS = CATEGORIES.map((c) => c.tag) as readonly CategoryTag[];
 
 | Rule                                                                        | Invariant                                                                                                                                  | Rationale                                                                                                                                                 |
 | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Single value tags produce scalar metadata fields                            | Each single-value tag (pattern, phase, status, brief) maps to exactly one metadata field with the correct type.                            | Incorrect type coercion (e.g., phase as string instead of number) causes downstream pipeline failures in filtering and sorting.                           |
+| Single value tags produce scalar metadata fields                            | Each single-value tag (pattern, phase, status) maps to exactly one metadata field with the correct type.                                   | Incorrect type coercion (e.g., phase as string instead of number) causes downstream pipeline failures in filtering and sorting.                           |
 | Array value tags accumulate into list metadata fields                       | Tags for depends-on and enables split comma-separated values and accumulate across multiple tag occurrences.                               | Missing a dependency value silently breaks the dependency graph, causing incorrect build ordering and orphaned pattern references.                        |
 | Category tags are colon-free tags filtered against known non-categories     | Tags without colons become categories, except known non-category tags (acceptance-criteria, happy-path) and the architect opt-in marker.   | Including test-control tags (acceptance-criteria, happy-path) as categories pollutes the pattern taxonomy with non-semantic values.                       |
 | Complex tag lists produce fully populated metadata                          | All tag types (scalar, array, category) are correctly extracted from a single mixed tag list.                                              | Real feature files combine many tag types; extraction must handle all types simultaneously without interference between parsers.                          |