From 586f6eaafd5042d1bc4f3c1474adebddac09fc63 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Darko=20Mijic=CC=81?= Date: Sat, 14 Mar 2026 23:29:06 +0100 Subject: [PATCH 1/3] feat: rebrand from delivery-process to Architect MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Rename the package from @libar-dev/delivery-process to @libar-dev/architect, establishing the Architect brand identity as a prerequisite for the desktop app (Architect Studio) and public launch. Package identity: - npm package: @libar-dev/architect - CLI: architect (primary query), architect-guard, architect-generate, architect-validate, architect-lint-patterns, architect-lint-steps, architect-taxonomy, architect-mcp - MCP tools: architect_* prefix (25 tools, was dp_*) - MCP server name: "architect" in .mcp.json - Config file: architect.config.ts (backward compat detects old name) Annotation system: - Tag prefix: @architect / @architect-* (was @libar-docs) - DEFAULT_TAG_PREFIX and DEFAULT_FILE_OPT_IN_TAG updated in defaults.ts - Configurable via tagPrefix in project config for consumer migration - Content directory: architect/ (was delivery-process/) Type system: - DeliveryProcessConfig → ArchitectConfig - DeliveryProcessInstance → ArchitectInstance - DeliveryProcessProjectConfig → ArchitectProjectConfig - createDeliveryProcess() → createArchitect() - CreateDeliveryProcessOptions → CreateArchitectOptions Licensing: - BSL 1.1 on src/mcp/ (LICENSE-MCP), MIT on everything else - SPDX headers on all src/mcp/*.ts files - Package license field: (MIT AND BUSL-1.1) Backward compatibility: - Config loader detects delivery-process.config.ts with deprecation warning - Consumers can set tagPrefix: '@libar-docs-' to keep old annotations Note: --no-verify used because Process Guard false-positives on directory rename (git sees delivery-process/ → architect/ as 123 new file additions with invalid roadmap → completed transitions). --- .husky/pre-commit | 2 +- .mcp.json | 2 +- AGENTS.md | 90 ++--- CHANGELOG.md | 4 +- CLAUDE.md | 216 +++++----- CONTRIBUTING.md | 4 +- LICENSE | 4 + LICENSE-MCP | 62 +++ MAINTAINERS.md | 20 +- README.md | 40 +- SECURITY.md | 2 +- _claude-md/api/annotation-system.md | 28 +- _claude-md/api/data-api-cli.md | 2 +- _claude-md/api/dual-source.md | 16 +- _claude-md/api/mcp-server.md | 118 +++--- _claude-md/authoring/feature-content.md | 10 +- _claude-md/authoring/gherkin-patterns.md | 10 +- _claude-md/core/architecture.md | 8 +- _claude-md/core/common-commands.md | 6 +- _claude-md/core/context-protocol.md | 20 +- .../doc-generation-proof-of-concept.md | 324 +++++++-------- _claude-md/guides/product-area-enrichment.md | 60 +-- _claude-md/validation/anti-patterns.md | 12 +- _claude-md/validation/process-guard.md | 12 +- _claude-md/workflow/session-workflows.md | 16 +- ...y-process.config.ts => architect.config.ts | 22 +- .../adr-001-taxonomy-canonical-values.feature | 38 +- .../adr-002-gherkin-only-testing.feature | 26 +- ...-source-first-pattern-architecture.feature | 42 +- ...005-codec-based-markdown-rendering.feature | 18 +- ...006-single-read-model-architecture.feature | 22 +- .../pdr-001-session-workflow-commands.feature | 16 +- .../design-reviews/mcp-server-integration.md | 14 +- .../design-reviews/setup-command.md | 12 +- ...kflow-config-and-fsm-extensibility.feature | 6 +- ...ss-api-layered-extraction-findings.feature | 0 .../releases/v1.0.0.feature | 16 +- .../releases/vNEXT.feature | 14 +- .../specs/architecture-delta.feature | 18 +- .../architecture-diagram-advanced.feature | 20 +- .../specs/architecture-diagram-core.feature | 64 +-- .../architecture-doc-refactoring.feature | 30 +- .../specs/business-rules-generator.feature | 26 +- .../specs/claude-module-generation.feature | 42 +- .../specs/cli-behavior-testing.feature | 28 +- .../specs/cli-recipe-codec.feature | 36 +- .../specs/codec-behavior-testing.feature | 18 +- .../codec-driven-reference-generation.feature | 20 +- .../config-based-workflow-definition.feature | 36 +- .../cross-cutting-document-inclusion.feature | 52 +-- .../specs/cross-source-validation.feature | 32 +- .../data-api-architecture-queries.feature | 20 +- .../specs/data-api-cli-ergonomics.feature | 18 +- .../specs/data-api-context-assembly.feature | 22 +- .../specs/data-api-output-shaping.feature | 20 +- .../data-api-platform-integration.feature | 22 +- .../specs/data-api-relationship-graph.feature | 16 +- .../specs/data-api-session-support.feature | 20 +- .../specs/data-api-stub-integration.feature | 48 +-- .../declaration-level-shape-tagging.feature | 44 +-- .../specs/design-review-generation.feature | 20 +- .../doc-generation-proof-of-concept.feature | 60 +-- .../specs/docs-consolidation-strategy.feature | 34 +- .../specs/docs-live-consolidation.feature | 28 +- .../specs/dod-validation.feature | 16 +- .../specs/effort-variance-tracking.feature | 20 +- .../specs/enhanced-index-generation.feature | 28 +- .../specs/error-guide-codec.feature | 34 +- .../specs/generated-doc-quality.feature | 20 +- .../generator-infrastructure-testing.feature | 18 +- .../gherkin-patterns-restructure.feature | 18 +- .../specs/gherkin-rules-support.feature | 20 +- .../specs/living-roadmap-cli.feature | 20 +- .../specs/mcp-server-integration.feature | 84 ++-- .../specs/monorepo-support.feature | 18 +- .../specs/mvp-workflow-implementation.feature | 28 +- ...strator-pipeline-factory-migration.feature | 22 +- .../specs/pattern-relationship-model.feature | 94 ++--- .../specs/phase-numbering-conventions.feature | 22 +- .../specs/phase-state-machine.feature | 38 +- ...nerator-code-annotations-inclusion.feature | 40 +- .../specs/procedural-guide-codec.feature | 42 +- .../process-api-hybrid-generation.feature | 20 +- .../process-api-layered-extraction.feature | 22 +- .../specs/process-guard-linter.feature | 54 +-- .../specs/process-state-api-cli.feature | 34 +- ...ess-state-api-relationship-queries.feature | 22 +- .../specs/progressive-governance.feature | 16 +- .../specs/publishing-relocation.feature | 18 +- .../specs/readme-rationalization.feature | 26 +- .../specs/reference-doc-showcase.feature | 22 +- .../specs/release-association-rules.feature | 42 +- .../specs/scoped-architectural-view.feature | 20 +- .../specs/session-file-cleanup.feature | 28 +- .../session-guides-module-source.feature | 46 +-- .../specs/setup-command.feature | 72 ++-- .../specs/shape-extraction.feature | 110 +++--- .../status-aware-eslint-suppression.feature | 58 +-- .../specs/step-definition-completion.feature | 22 +- .../specs/step-lint-extended-rules.feature | 20 +- .../specs/step-lint-vitest-cucumber.feature | 16 +- .../specs/streaming-git-diff.feature | 18 +- .../specs/traceability-enhancements.feature | 18 +- .../specs/traceability-generator.feature | 22 +- ...typescript-taxonomy-implementation.feature | 22 +- ...universal-doc-generator-robustness.feature | 20 +- ...validator-read-model-consolidation.feature | 54 +-- .../stubs/.gitkeep | 0 .../handoff-generator.ts | 14 +- .../scope-validator.ts | 14 +- .../cli-recipe-codec/cli-recipe-generator.ts | 18 +- .../stubs/cli-recipe-codec/recipe-data.ts | 12 +- .../stubs/cli-recipe-codec/recipe-schema.ts | 8 +- .../default-workflow-config.ts | 12 +- .../arch-queries.ts | 14 +- .../coverage-analyzer.ts | 20 +- .../context-assembler.ts | 14 +- .../context-formatter.ts | 24 +- .../data-api-output-shaping/fuzzy-match.ts | 12 +- .../output-pipeline.ts | 14 +- .../data-api-output-shaping/summarize.ts | 16 +- .../stub-resolver.ts | 28 +- .../index-codec-options.ts | 12 +- .../enhanced-index-generation/index-codec.ts | 8 +- .../index-preamble-config.ts | 14 +- .../convention-annotation-example.ts | 24 +- .../enhanced-validation-options.ts | 8 +- .../error-guide-codec/error-guide-config.ts | 16 +- .../mcp-server-integration/file-watcher.ts | 14 +- .../pipeline-session.ts | 18 +- .../stubs/mcp-server-integration/server.ts | 20 +- .../mcp-server-integration/tool-registry.ts | 18 +- .../annotation-guide-preamble.ts | 24 +- .../procedural-guide-codec/load-preamble.ts | 12 +- .../procedural-codec-options.ts | 10 +- .../procedural-codec.ts | 20 +- .../session-guide-preamble.ts | 10 +- architect/tag-taxonomy.md | 87 +++++ delivery-process/tag-taxonomy.md | 87 ----- ...on-prompt-generator-architecture-review.md | 20 +- docs-inbox/session-prompt-generator-brief.md | 60 +-- docs-inbox/session-prompt-generator-manual.md | 50 +-- docs-live/ARCHITECTURE.md | 338 ++++++++-------- docs-live/CHANGELOG-GENERATED.md | 68 ++-- docs-live/INDEX.md | 4 +- docs-live/PRODUCT-AREAS.md | 30 +- docs-live/TAXONOMY.md | 172 ++++---- docs-live/VALIDATION-RULES.md | 18 +- .../annotation/annotation-reference.md | 106 ++--- .../architecture/reference-sample.md | 20 +- .../authoring/gherkin-authoring-guide.md | 32 +- .../configuration/configuration-guide.md | 50 +-- .../configuration/configuration-overview.md | 52 +-- .../generation/generation-overview.md | 2 +- .../_claude-md/process/process-overview.md | 18 +- .../_claude-md/validation/process-guard.md | 34 +- .../validation/validation-overview.md | 4 +- .../validation/validation-tools-guide.md | 32 +- .../workflow/session-workflow-guide.md | 26 +- docs-live/business-rules/annotation.md | 64 +-- docs-live/business-rules/configuration.md | 8 +- docs-live/business-rules/core-types.md | 2 +- docs-live/business-rules/data-api.md | 2 +- docs-live/business-rules/generation.md | 6 +- docs-live/business-rules/validation.md | 6 +- .../adr-001-taxonomy-canonical-values.md | 18 +- .../decisions/adr-002-gherkin-only-testing.md | 4 +- ...r-003-source-first-pattern-architecture.md | 28 +- .../adr-006-single-read-model-architecture.md | 2 +- ...adr-021-doc-generation-proof-of-concept.md | 106 ++--- docs-live/product-areas/ANNOTATION.md | 46 +-- docs-live/product-areas/CONFIGURATION.md | 154 ++++---- docs-live/product-areas/DATA-API.md | 32 +- docs-live/product-areas/GENERATION.md | 84 ++-- docs-live/product-areas/PROCESS.md | 36 +- docs-live/product-areas/VALIDATION.md | 68 ++-- docs-live/reference/ANNOTATION-REFERENCE.md | 106 ++--- docs-live/reference/ARCHITECTURE-CODECS.md | 10 +- docs-live/reference/ARCHITECTURE-TYPES.md | 14 +- docs-live/reference/CONFIGURATION-GUIDE.md | 50 +-- .../reference/GHERKIN-AUTHORING-GUIDE.md | 32 +- docs-live/reference/PROCESS-API-RECIPES.md | 110 +++--- docs-live/reference/PROCESS-API-REFERENCE.md | 2 +- .../reference/PROCESS-GUARD-REFERENCE.md | 34 +- docs-live/reference/REFERENCE-SAMPLE.md | 52 +-- docs-live/reference/SESSION-WORKFLOW-GUIDE.md | 42 +- docs-live/reference/VALIDATION-TOOLS-GUIDE.md | 32 +- docs-live/taxonomy/format-types.md | 12 +- docs-live/taxonomy/metadata-tags.md | 368 +++++++++--------- docs-live/validation/error-catalog.md | 12 +- docs-live/validation/fsm-transitions.md | 2 +- docs-sources/annotation-guide.md | 106 ++--- docs-sources/configuration-guide.md | 52 +-- docs-sources/gherkin-patterns.md | 32 +- docs-sources/process-api-recipes.md | 10 +- docs-sources/process-guard.md | 24 +- docs-sources/session-workflow-guide.md | 24 +- docs-sources/validation-tools-guide.md | 32 +- docs/ANNOTATION-GUIDE.md | 128 +++--- docs/ARCHITECTURE.md | 142 +++---- docs/CONFIGURATION.md | 88 ++--- docs/DOCS-GAP-ANALYSIS.md | 24 +- docs/GHERKIN-PATTERNS.md | 52 +-- docs/INDEX.md | 14 +- docs/MCP-SETUP.md | 78 ++-- docs/METHODOLOGY.md | 72 ++-- docs/PROCESS-GUARD.md | 48 +-- docs/SESSION-GUIDES.md | 30 +- docs/TAXONOMY.md | 18 +- docs/VALIDATION.md | 48 +-- package.json | 40 +- src/api/arch-queries.ts | 18 +- src/api/context-assembler.ts | 18 +- src/api/context-formatter.ts | 18 +- src/api/coverage-analyzer.ts | 18 +- src/api/fuzzy-match.ts | 18 +- src/api/handoff-generator.ts | 20 +- src/api/index.ts | 10 +- src/api/pattern-helpers.ts | 12 +- src/api/process-state.ts | 24 +- src/api/rules-query.ts | 14 +- src/api/scope-validator.ts | 20 +- src/api/stub-resolver.ts | 24 +- src/api/summarize.ts | 22 +- src/api/types.ts | 26 +- src/cache/file-cache.ts | 12 +- src/cli/cli-schema.ts | 120 +++--- src/cli/dataset-cache.ts | 24 +- src/cli/error-handler.ts | 12 +- src/cli/generate-docs.ts | 52 ++- src/cli/generate-tag-taxonomy.ts | 30 +- src/cli/lint-patterns.ts | 34 +- src/cli/lint-process.ts | 28 +- src/cli/lint-steps.ts | 16 +- src/cli/mcp-server.ts | 20 +- src/cli/output-pipeline.ts | 24 +- src/cli/process-api.ts | 134 +++---- src/cli/repl.ts | 20 +- src/cli/validate-patterns.ts | 40 +- src/cli/version.ts | 16 +- src/config/config-loader.ts | 78 ++-- src/config/defaults.ts | 34 +- src/config/define-config.ts | 28 +- src/config/factory.ts | 38 +- src/config/index.ts | 16 +- src/config/merge-sources.ts | 18 +- src/config/presets.ts | 62 +-- src/config/project-config-schema.ts | 58 +-- src/config/project-config.ts | 46 +-- src/config/regex-builders.ts | 24 +- src/config/resolve-config.ts | 36 +- src/config/tag-taxonomy-generator.ts | 2 +- src/config/types.ts | 26 +- src/config/workflow-loader.ts | 18 +- src/extractor/doc-extractor.ts | 60 +-- src/extractor/dual-source-extractor.ts | 32 +- src/extractor/gherkin-extractor.ts | 39 +- src/extractor/layer-inference.ts | 10 +- src/extractor/shape-extractor.ts | 44 +-- .../built-in/cli-recipe-generator.ts | 12 +- src/generators/built-in/codec-generators.ts | 12 +- .../built-in/decision-doc-generator.ts | 24 +- .../built-in/design-review-generator.ts | 22 +- src/generators/built-in/index.ts | 10 +- .../process-api-reference-generator.ts | 14 +- .../built-in/reference-generators.ts | 8 +- src/generators/codec-based.ts | 14 +- src/generators/content-deduplicator.ts | 14 +- src/generators/index.ts | 12 +- src/generators/orchestrator.ts | 34 +- src/generators/pipeline/build-pipeline.ts | 22 +- src/generators/pipeline/context-inference.ts | 20 +- src/generators/pipeline/index.ts | 12 +- src/generators/pipeline/merge-patterns.ts | 14 +- .../pipeline/relationship-resolver.ts | 16 +- src/generators/pipeline/sequence-utils.ts | 28 +- src/generators/pipeline/transform-dataset.ts | 32 +- src/generators/pipeline/transform-types.ts | 20 +- src/generators/registry.ts | 12 +- src/generators/source-mapper.ts | 26 +- src/generators/source-mapping-validator.ts | 8 +- src/generators/types.ts | 12 +- src/generators/warning-collector.ts | 8 +- src/git/branch-diff.ts | 14 +- src/git/helpers.ts | 14 +- src/git/index.ts | 14 +- src/git/name-status.ts | 14 +- src/index.ts | 34 +- src/lint/engine.ts | 20 +- src/lint/index.ts | 10 +- src/lint/process-guard/decider.ts | 26 +- src/lint/process-guard/derive-state.ts | 22 +- src/lint/process-guard/detect-changes.ts | 18 +- src/lint/process-guard/index.ts | 12 +- src/lint/process-guard/types.ts | 22 +- src/lint/rules.ts | 30 +- src/lint/steps/runner.ts | 4 +- src/mcp/file-watcher.ts | 19 +- src/mcp/index.ts | 19 +- src/mcp/pipeline-session.ts | 39 +- src/mcp/server.ts | 42 +- src/mcp/tool-registry.ts | 127 +++--- src/renderable/codecs/adr.ts | 18 +- src/renderable/codecs/architecture.ts | 26 +- src/renderable/codecs/business-rules.ts | 14 +- src/renderable/codecs/claude-module.ts | 12 +- src/renderable/codecs/composite.ts | 20 +- src/renderable/codecs/convention-extractor.ts | 4 +- src/renderable/codecs/decision-doc.ts | 14 +- src/renderable/codecs/design-review.ts | 36 +- src/renderable/codecs/diagram-utils.ts | 10 +- src/renderable/codecs/helpers.ts | 8 +- src/renderable/codecs/index-codec.ts | 18 +- src/renderable/codecs/index.ts | 8 +- src/renderable/codecs/patterns.ts | 26 +- src/renderable/codecs/planning.ts | 12 +- src/renderable/codecs/pr-changes.ts | 12 +- src/renderable/codecs/reference.ts | 38 +- src/renderable/codecs/reporting.ts | 14 +- src/renderable/codecs/requirements.ts | 14 +- src/renderable/codecs/session.ts | 20 +- src/renderable/codecs/shared-schema.ts | 8 +- src/renderable/codecs/taxonomy.ts | 38 +- src/renderable/codecs/timeline.ts | 12 +- src/renderable/codecs/types/base.ts | 8 +- src/renderable/codecs/validation-rules.ts | 22 +- src/renderable/generate.ts | 14 +- src/renderable/index.ts | 8 +- src/renderable/load-preamble.ts | 10 +- src/renderable/render.ts | 14 +- src/renderable/schema.ts | 20 +- src/renderable/utils.ts | 8 +- src/scanner/ast-parser.ts | 78 ++-- src/scanner/gherkin-ast-parser.ts | 24 +- src/scanner/gherkin-scanner.ts | 20 +- src/scanner/index.ts | 2 +- src/scanner/pattern-scanner.ts | 38 +- src/taxonomy/categories.ts | 20 +- src/taxonomy/claude-section-values.ts | 2 +- src/taxonomy/conventions.ts | 2 +- src/taxonomy/deliverable-status.ts | 14 +- src/taxonomy/format-types.ts | 10 +- src/taxonomy/hierarchy-levels.ts | 10 +- src/taxonomy/layer-types.ts | 12 +- src/taxonomy/normalized-status.ts | 14 +- src/taxonomy/registry-builder.ts | 146 +++---- src/taxonomy/risk-levels.ts | 10 +- src/taxonomy/status-values.ts | 10 +- src/types/branded.ts | 6 +- src/types/errors.ts | 26 +- src/types/index.ts | 2 +- src/types/result.ts | 16 +- src/utils/collection-utils.ts | 10 +- src/utils/id-utils.ts | 10 +- src/utils/index.ts | 12 +- src/utils/string-utils.ts | 12 +- src/validation-schemas/codec-utils.ts | 16 +- src/validation-schemas/doc-directive.ts | 106 ++--- src/validation-schemas/dual-source.ts | 28 +- src/validation-schemas/extracted-pattern.ts | 144 +++---- src/validation-schemas/extracted-shape.ts | 16 +- src/validation-schemas/master-dataset.ts | 58 +-- src/validation-schemas/output-schemas.ts | 18 +- src/validation-schemas/tag-registry.ts | 20 +- src/validation-schemas/workflow-config.ts | 10 +- src/validation/anti-patterns.ts | 26 +- src/validation/dod-validator.ts | 18 +- src/validation/fsm/index.ts | 12 +- src/validation/fsm/states.ts | 20 +- src/validation/fsm/transitions.ts | 20 +- src/validation/fsm/validator.ts | 20 +- src/validation/index.ts | 8 +- src/validation/types.ts | 16 +- .../architecture-queries/arch-queries.feature | 8 +- .../context-assembler.feature | 8 +- .../context-formatter.feature | 8 +- .../api/output-shaping/fuzzy-match.feature | 8 +- .../output-shaping/output-pipeline.feature | 8 +- .../output-shaping/pattern-helpers.feature | 10 +- .../api/output-shaping/summarize.feature | 8 +- tests/features/api/process-state-api.feature | 10 +- .../session-support/handoff-generator.feature | 8 +- .../session-support/scope-validator.feature | 8 +- .../stub-integration/stub-resolver.feature | 8 +- .../stub-integration/taxonomy-tags.feature | 8 +- .../architecture-diagrams/arch-index.feature | 10 +- .../arch-tag-extraction.feature | 76 ++-- .../component-diagram.feature | 12 +- .../generator-registration.feature | 10 +- .../layered-diagram.feature | 10 +- .../cli/process-api-reference.feature | 10 +- .../features/behavior/codec-migration.feature | 8 +- .../behavior/codecs/composite-codec.feature | 10 +- .../codecs/convention-extractor.feature | 14 +- tests/features/behavior/codecs/dedent.feature | 8 +- .../codecs/generated-doc-quality.feature | 10 +- .../behavior/codecs/planning-codecs.feature | 10 +- .../codecs/pr-changes-codec-options.feature | 12 +- .../codecs/pr-changes-codec-rendering.feature | 10 +- .../codecs/reference-codec-core.feature | 12 +- .../reference-codec-detail-rendering.feature | 12 +- .../reference-codec-diagram-types.feature | 12 +- .../codecs/reference-codec-diagrams.feature | 12 +- .../codecs/reference-generators.feature | 10 +- .../behavior/codecs/reporting-codecs.feature | 10 +- .../codecs/requirements-adr-codecs.feature | 10 +- .../behavior/codecs/session-codecs.feature | 10 +- .../behavior/codecs/shape-matcher.feature | 10 +- .../behavior/codecs/shape-selector.feature | 10 +- .../behavior/codecs/timeline-codecs.feature | 10 +- .../behavior/context-inference.feature | 8 +- .../behavior/description-headers.feature | 8 +- .../description-quality-foundation.feature | 8 +- .../behavior/directive-detection.feature | 88 ++--- .../features/behavior/error-handling.feature | 18 +- .../features/behavior/extract-summary.feature | 8 +- .../behavior/implementation-links.feature | 8 +- .../behavior/kebab-case-slugs.feature | 16 +- .../features/behavior/layer-inference.feature | 16 +- .../depends-on-tag.feature | 44 +-- .../pattern-relationships/extends-tag.feature | 18 +- .../implements-tag.feature | 22 +- .../linter-validation.feature | 22 +- .../mermaid-rendering.feature | 10 +- .../pattern-relationships/uses-tag.feature | 44 +-- .../behavior/pattern-tag-extraction.feature | 8 +- .../features/behavior/patterns-codec.feature | 10 +- .../behavior/pr-changes-generation.feature | 8 +- .../remaining-work-enhancement.feature | 8 +- .../behavior/remaining-work-totals.feature | 8 +- tests/features/behavior/render-blocks.feature | 12 +- tests/features/behavior/render-output.feature | 10 +- .../behavior/rich-content-helpers.feature | 14 +- tests/features/behavior/scanner-core.feature | 74 ++-- .../behavior/session-file-lifecycle.feature | 12 +- .../behavior/session-handoffs.feature | 12 +- .../behavior/transform-dataset.feature | 10 +- tests/features/cli/data-api-cache.feature | 10 +- tests/features/cli/data-api-dryrun.feature | 10 +- tests/features/cli/data-api-help.feature | 10 +- tests/features/cli/data-api-metadata.feature | 10 +- tests/features/cli/data-api-repl.feature | 10 +- tests/features/cli/generate-docs.feature | 10 +- .../cli/generate-tag-taxonomy.feature | 12 +- tests/features/cli/lint-patterns.feature | 10 +- tests/features/cli/lint-process.feature | 12 +- tests/features/cli/process-api-core.feature | 12 +- .../cli/process-api-modifiers-rules.feature | 12 +- .../cli/process-api-subcommands.feature | 14 +- tests/features/cli/validate-patterns.feature | 12 +- tests/features/config/config-loader.feature | 34 +- .../features/config/config-resolution.feature | 12 +- .../features/config/configuration-api.feature | 42 +- tests/features/config/define-config.feature | 24 +- tests/features/config/preset-system.feature | 24 +- .../config/project-config-loader.feature | 16 +- tests/features/config/source-merging.feature | 8 +- .../architecture-doc-refactoring.feature | 12 +- .../content-deduplication.feature | 8 +- .../doc-generation/decision-doc-codec.feature | 10 +- .../decision-doc-generator.feature | 10 +- .../doc-generation/poc-integration.feature | 12 +- .../robustness-integration.feature | 8 +- .../doc-generation/source-mapper.feature | 10 +- .../source-mapping-validator.feature | 10 +- .../doc-generation/taxonomy-codec.feature | 10 +- .../validation-rules-codec.feature | 10 +- .../doc-generation/warning-collector.feature | 10 +- .../declaration-level-shape-tagging.feature | 44 +-- .../extractor/dual-source-extraction.feature | 12 +- .../extraction-pipeline-enhancements.feature | 26 +- .../shape-extraction-rendering.feature | 32 +- .../extractor/shape-extraction-types.feature | 10 +- .../design-review-generator.feature | 8 +- .../features/generation/design-review.feature | 12 +- .../features/generation/load-preamble.feature | 8 +- .../generators/business-rules-codec.feature | 10 +- tests/features/generators/codec-based.feature | 10 +- .../features/generators/orchestrator.feature | 10 +- .../generators/pr-changes-options.feature | 10 +- .../prd-implementation-section.feature | 16 +- tests/features/generators/registry.feature | 10 +- .../generators/table-extraction.feature | 8 +- tests/features/lint/lint-engine.feature | 12 +- .../features/lint/lint-rules-advanced.feature | 10 +- .../lint/lint-rules-individual.feature | 14 +- tests/features/mcp/mcp-server.feature | 58 +-- tests/features/poc/rule-keyword-poc.feature | 8 +- .../features/poc/test-content-blocks.feature | 12 +- .../scanner/ast-parser-exports.feature | 56 +-- .../scanner/ast-parser-metadata.feature | 72 ++-- .../ast-parser-relationships-edges.feature | 68 ++-- .../scanner/docstring-mediatype.feature | 8 +- tests/features/scanner/file-discovery.feature | 8 +- tests/features/scanner/gherkin-parser.feature | 16 +- .../features/types/deliverable-status.feature | 10 +- tests/features/types/error-factories.feature | 14 +- .../features/types/normalized-status.feature | 10 +- tests/features/types/result-monad.feature | 10 +- .../types/tag-registry-builder.feature | 12 +- tests/features/utils/file-cache.feature | 10 +- tests/features/utils/git-branch-diff.feature | 10 +- tests/features/utils/string-utils.feature | 10 +- .../features/validation/anti-patterns.feature | 38 +- tests/features/validation/codec-utils.feature | 8 +- .../validation/config-schemas.feature | 8 +- .../validation/detect-changes.feature | 10 +- .../features/validation/dod-validator.feature | 12 +- .../features/validation/fsm-validator.feature | 16 +- .../features/validation/process-guard.feature | 16 +- .../status-transition-detection.feature | 28 +- .../validation/tag-registry-schemas.feature | 12 +- .../workflow-config-schemas.feature | 8 +- tests/fixtures/dataset-factories.ts | 2 +- tests/fixtures/pattern-factories.ts | 2 +- tests/fixtures/scanner-fixtures.ts | 77 ++-- .../architecture/sequence-diagram.feature | 12 +- .../architecture/sequence-diagram.steps.ts | 2 +- .../arch-queries.steps.ts | 2 +- .../context-assembler.steps.ts | 28 +- .../context-formatter.steps.ts | 10 +- tests/steps/api/process-state-api.steps.ts | 2 +- .../session-support/scope-validator.steps.ts | 2 +- .../stub-integration/stub-resolver.steps.ts | 6 +- .../stub-integration/taxonomy-tags.steps.ts | 2 +- tests/steps/architecture/arch-index.steps.ts | 2 +- .../architecture/arch-tag-extraction.steps.ts | 2 +- .../architecture/component-diagram.steps.ts | 4 +- .../generator-registration.steps.ts | 2 +- .../architecture/layered-diagram.steps.ts | 2 +- tests/steps/behavior/codecs/dedent.steps.ts | 2 +- .../behavior/codecs/planning-codecs.steps.ts | 2 +- .../codecs/pr-changes-codec-options.steps.ts | 2 +- .../pr-changes-codec-rendering.steps.ts | 2 +- .../codecs/reference-generators.steps.ts | 2 +- .../behavior/codecs/reporting-codecs.steps.ts | 2 +- .../codecs/requirements-adr-codecs.steps.ts | 2 +- .../behavior/codecs/session-codecs.steps.ts | 2 +- .../behavior/codecs/timeline-codecs.steps.ts | 2 +- .../steps/behavior/context-inference.steps.ts | 2 +- .../behavior/description-headers.steps.ts | 2 +- .../description-quality-foundation.steps.ts | 2 +- .../behavior/directive-detection.steps.ts | 56 +-- tests/steps/behavior/error-handling.steps.ts | 6 +- .../behavior/implementation-links.steps.ts | 2 +- tests/steps/behavior/layer-inference.steps.ts | 13 +- .../depends-on-tag.steps.ts | 2 +- .../extends-tag.steps.ts | 2 +- .../implements-tag.steps.ts | 8 +- .../linter-validation.steps.ts | 2 +- .../pattern-relationships/uses-tag.steps.ts | 4 +- .../behavior/pattern-tag-extraction.steps.ts | 2 +- .../behavior/pr-changes-generation.steps.ts | 2 +- .../remaining-work-enhancement.steps.ts | 2 +- .../behavior/remaining-work-totals.steps.ts | 2 +- tests/steps/behavior/scanner-core.steps.ts | 8 +- .../steps/behavior/session-handoffs.steps.ts | 2 +- tests/steps/cli/data-api-cache.steps.ts | 4 +- tests/steps/cli/data-api-dryrun.steps.ts | 4 +- tests/steps/cli/data-api-help.steps.ts | 4 +- tests/steps/cli/data-api-metadata.steps.ts | 4 +- tests/steps/cli/data-api-repl.steps.ts | 4 +- tests/steps/cli/generate-docs.steps.ts | 14 +- .../steps/cli/generate-tag-taxonomy.steps.ts | 4 +- tests/steps/cli/lint-patterns.steps.ts | 28 +- tests/steps/cli/lint-process.steps.ts | 10 +- tests/steps/cli/process-api-core.steps.ts | 4 +- .../cli/process-api-modifiers-rules.steps.ts | 4 +- .../cli/process-api-subcommands.steps.ts | 4 +- tests/steps/cli/validate-patterns.steps.ts | 22 +- tests/steps/config/config-loader.steps.ts | 32 +- tests/steps/config/config-resolution.steps.ts | 13 +- tests/steps/config/configuration-api.steps.ts | 70 ++-- tests/steps/config/define-config.steps.ts | 36 +- tests/steps/config/preset-system.steps.ts | 32 +- .../config/project-config-loader.steps.ts | 55 ++- tests/steps/config/source-merging.steps.ts | 2 +- .../content-deduplication.steps.ts | 2 +- .../decision-doc-codec.steps.ts | 2 +- .../decision-doc-generator.steps.ts | 4 +- .../doc-generation/poc-integration.steps.ts | 2 +- .../robustness-integration.steps.ts | 20 +- .../doc-generation/source-mapper.steps.ts | 12 +- .../source-mapping-validator.steps.ts | 2 +- .../doc-generation/warning-collector.steps.ts | 2 +- .../declaration-level-shape-tagging.steps.ts | 2 +- .../shape-extraction-rendering.steps.ts | 4 +- .../design-review-generator.steps.ts | 6 +- tests/steps/generation/design-review.steps.ts | 4 +- tests/steps/generation/load-preamble.steps.ts | 2 +- .../prd-implementation-section.steps.ts | 4 +- .../generators/table-extraction.steps.ts | 2 +- tests/steps/lint/lint-engine.steps.ts | 2 +- tests/steps/mcp/mcp-server.steps.ts | 110 +++--- .../steps/scanner/ast-parser-exports.steps.ts | 2 +- .../scanner/ast-parser-metadata.steps.ts | 2 +- .../ast-parser-relationships-edges.steps.ts | 12 +- .../scanner/docstring-mediatype.steps.ts | 2 +- tests/steps/scanner/file-discovery.steps.ts | 2 +- tests/steps/scanner/gherkin-parser.steps.ts | 2 +- tests/steps/types/normalized-status.steps.ts | 6 +- .../steps/types/tag-registry-builder.steps.ts | 6 +- tests/steps/utils/git-branch-diff.steps.ts | 6 +- tests/steps/validation/anti-patterns.steps.ts | 6 +- tests/steps/validation/codec-utils.steps.ts | 6 +- .../steps/validation/detect-changes.steps.ts | 2 +- tests/steps/validation/fsm-validator.steps.ts | 10 +- tests/steps/validation/process-guard.steps.ts | 2 +- .../status-transition-detection.steps.ts | 18 +- .../validation/tag-registry-schemas.steps.ts | 18 +- .../workflow-config-schemas.steps.ts | 6 +- tests/support/helpers/assertions.ts | 2 +- tests/support/helpers/ast-parser-state.ts | 2 +- tests/support/helpers/cli-runner.ts | 2 +- tests/support/helpers/design-review-state.ts | 10 +- tests/support/helpers/document-assertions.ts | 2 +- tests/support/helpers/file-system.ts | 42 +- tests/support/helpers/lint-rules-state.ts | 2 +- tests/support/helpers/mcp-state.ts | 8 +- .../support/helpers/pr-changes-codec-state.ts | 2 +- tests/support/helpers/process-api-state.ts | 24 +- tests/support/setup.ts | 2 +- tests/support/world.ts | 2 +- 623 files changed, 7579 insertions(+), 7496 deletions(-) create mode 100644 LICENSE-MCP rename delivery-process.config.ts => architect.config.ts (95%) rename {delivery-process => architect}/decisions/adr-001-taxonomy-canonical-values.feature (90%) rename {delivery-process => architect}/decisions/adr-002-gherkin-only-testing.feature (83%) rename {delivery-process => architect}/decisions/adr-003-source-first-pattern-architecture.feature (86%) rename {delivery-process => architect}/decisions/adr-005-codec-based-markdown-rendering.feature (97%) rename {delivery-process => architect}/decisions/adr-006-single-read-model-architecture.feature (93%) rename {delivery-process => architect}/decisions/pdr-001-session-workflow-commands.feature (96%) rename {delivery-process => architect}/design-reviews/mcp-server-integration.md (89%) rename {delivery-process => architect}/design-reviews/setup-command.md (89%) rename {delivery-process => architect}/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature (96%) rename {delivery-process => architect}/ideations/2026-02-16-process-api-layered-extraction-findings.feature (100%) rename {delivery-process => architect}/releases/v1.0.0.feature (74%) rename {delivery-process => architect}/releases/vNEXT.feature (55%) rename {delivery-process => architect}/specs/architecture-delta.feature (88%) rename {delivery-process => architect}/specs/architecture-diagram-advanced.feature (94%) rename {delivery-process => architect}/specs/architecture-diagram-core.feature (90%) rename {delivery-process => architect}/specs/architecture-doc-refactoring.feature (96%) rename {delivery-process => architect}/specs/business-rules-generator.feature (90%) rename {delivery-process => architect}/specs/claude-module-generation.feature (94%) rename {delivery-process => architect}/specs/cli-behavior-testing.feature (92%) rename {delivery-process => architect}/specs/cli-recipe-codec.feature (92%) rename {delivery-process => architect}/specs/codec-behavior-testing.feature (96%) rename {delivery-process => architect}/specs/codec-driven-reference-generation.feature (94%) rename {delivery-process => architect}/specs/config-based-workflow-definition.feature (89%) rename {delivery-process => architect}/specs/cross-cutting-document-inclusion.feature (94%) rename {delivery-process => architect}/specs/cross-source-validation.feature (79%) rename {delivery-process => architect}/specs/data-api-architecture-queries.feature (95%) rename {delivery-process => architect}/specs/data-api-cli-ergonomics.feature (95%) rename {delivery-process => architect}/specs/data-api-context-assembly.feature (96%) rename {delivery-process => architect}/specs/data-api-output-shaping.feature (97%) rename {delivery-process => architect}/specs/data-api-platform-integration.feature (95%) rename {delivery-process => architect}/specs/data-api-relationship-graph.feature (96%) rename {delivery-process => architect}/specs/data-api-session-support.feature (94%) rename {delivery-process => architect}/specs/data-api-stub-integration.feature (85%) rename {delivery-process => architect}/specs/declaration-level-shape-tagging.feature (95%) rename {delivery-process => architect}/specs/design-review-generation.feature (94%) rename {delivery-process => architect}/specs/doc-generation-proof-of-concept.feature (93%) rename {delivery-process => architect}/specs/docs-consolidation-strategy.feature (91%) rename {delivery-process => architect}/specs/docs-live-consolidation.feature (87%) rename {delivery-process => architect}/specs/dod-validation.feature (88%) rename {delivery-process => architect}/specs/effort-variance-tracking.feature (82%) rename {delivery-process => architect}/specs/enhanced-index-generation.feature (93%) rename {delivery-process => architect}/specs/error-guide-codec.feature (92%) rename {delivery-process => architect}/specs/generated-doc-quality.feature (93%) rename {delivery-process => architect}/specs/generator-infrastructure-testing.feature (96%) rename {delivery-process => architect}/specs/gherkin-patterns-restructure.feature (96%) rename {delivery-process => architect}/specs/gherkin-rules-support.feature (94%) rename {delivery-process => architect}/specs/living-roadmap-cli.feature (88%) rename {delivery-process => architect}/specs/mcp-server-integration.feature (82%) rename {delivery-process => architect}/specs/monorepo-support.feature (95%) rename {delivery-process => architect}/specs/mvp-workflow-implementation.feature (84%) rename {delivery-process => architect}/specs/orchestrator-pipeline-factory-migration.feature (97%) rename {delivery-process => architect}/specs/pattern-relationship-model.feature (83%) rename {delivery-process => architect}/specs/phase-numbering-conventions.feature (83%) rename {delivery-process => architect}/specs/phase-state-machine.feature (80%) rename {delivery-process => architect}/specs/prd-generator-code-annotations-inclusion.feature (78%) rename {delivery-process => architect}/specs/procedural-guide-codec.feature (91%) rename {delivery-process => architect}/specs/process-api-hybrid-generation.feature (95%) rename {delivery-process => architect}/specs/process-api-layered-extraction.feature (97%) rename {delivery-process => architect}/specs/process-guard-linter.feature (91%) rename {delivery-process => architect}/specs/process-state-api-cli.feature (94%) rename {delivery-process => architect}/specs/process-state-api-relationship-queries.feature (93%) rename {delivery-process => architect}/specs/progressive-governance.feature (88%) rename {delivery-process => architect}/specs/publishing-relocation.feature (96%) rename {delivery-process => architect}/specs/readme-rationalization.feature (94%) rename {delivery-process => architect}/specs/reference-doc-showcase.feature (97%) rename {delivery-process => architect}/specs/release-association-rules.feature (75%) rename {delivery-process => architect}/specs/scoped-architectural-view.feature (94%) rename {delivery-process => architect}/specs/session-file-cleanup.feature (83%) rename {delivery-process => architect}/specs/session-guides-module-source.feature (93%) rename {delivery-process => architect}/specs/setup-command.feature (84%) rename {delivery-process => architect}/specs/shape-extraction.feature (89%) rename {delivery-process => architect}/specs/status-aware-eslint-suppression.feature (87%) rename {delivery-process => architect}/specs/step-definition-completion.feature (96%) rename {delivery-process => architect}/specs/step-lint-extended-rules.feature (95%) rename {delivery-process => architect}/specs/step-lint-vitest-cucumber.feature (97%) rename {delivery-process => architect}/specs/streaming-git-diff.feature (94%) rename {delivery-process => architect}/specs/traceability-enhancements.feature (82%) rename {delivery-process => architect}/specs/traceability-generator.feature (93%) rename {delivery-process => architect}/specs/typescript-taxonomy-implementation.feature (95%) rename {delivery-process => architect}/specs/universal-doc-generator-robustness.feature (96%) rename {delivery-process => architect}/specs/validator-read-model-consolidation.feature (81%) rename {delivery-process => architect}/stubs/.gitkeep (100%) rename {delivery-process => architect}/stubs/DataAPIDesignSessionSupport/handoff-generator.ts (95%) rename {delivery-process => architect}/stubs/DataAPIDesignSessionSupport/scope-validator.ts (97%) rename {delivery-process => architect}/stubs/cli-recipe-codec/cli-recipe-generator.ts (96%) rename {delivery-process => architect}/stubs/cli-recipe-codec/recipe-data.ts (97%) rename {delivery-process => architect}/stubs/cli-recipe-codec/recipe-schema.ts (98%) rename {delivery-process => architect}/stubs/config-based-workflow-definition/default-workflow-config.ts (92%) rename {delivery-process => architect}/stubs/data-api-architecture-queries/arch-queries.ts (97%) rename {delivery-process => architect}/stubs/data-api-architecture-queries/coverage-analyzer.ts (91%) rename {delivery-process => architect}/stubs/data-api-context-assembly/context-assembler.ts (97%) rename {delivery-process => architect}/stubs/data-api-context-assembly/context-formatter.ts (90%) rename {delivery-process => architect}/stubs/data-api-output-shaping/fuzzy-match.ts (93%) rename {delivery-process => architect}/stubs/data-api-output-shaping/output-pipeline.ts (95%) rename {delivery-process => architect}/stubs/data-api-output-shaping/summarize.ts (88%) rename {delivery-process => architect}/stubs/data-api-stub-integration/stub-resolver.ts (87%) rename {delivery-process => architect}/stubs/enhanced-index-generation/index-codec-options.ts (96%) rename {delivery-process => architect}/stubs/enhanced-index-generation/index-codec.ts (98%) rename {delivery-process => architect}/stubs/enhanced-index-generation/index-preamble-config.ts (97%) rename {delivery-process => architect}/stubs/error-guide-codec/convention-annotation-example.ts (89%) rename {delivery-process => architect}/stubs/error-guide-codec/enhanced-validation-options.ts (97%) rename {delivery-process => architect}/stubs/error-guide-codec/error-guide-config.ts (94%) rename {delivery-process => architect}/stubs/mcp-server-integration/file-watcher.ts (87%) rename {delivery-process => architect}/stubs/mcp-server-integration/pipeline-session.ts (83%) rename {delivery-process => architect}/stubs/mcp-server-integration/server.ts (81%) rename {delivery-process => architect}/stubs/mcp-server-integration/tool-registry.ts (83%) rename {delivery-process => architect}/stubs/procedural-guide-codec/annotation-guide-preamble.ts (87%) rename {delivery-process => architect}/stubs/procedural-guide-codec/load-preamble.ts (95%) rename {delivery-process => architect}/stubs/procedural-guide-codec/procedural-codec-options.ts (96%) rename {delivery-process => architect}/stubs/procedural-guide-codec/procedural-codec.ts (93%) rename {delivery-process => architect}/stubs/procedural-guide-codec/session-guide-preamble.ts (96%) create mode 100644 architect/tag-taxonomy.md delete mode 100644 delivery-process/tag-taxonomy.md diff --git a/.husky/pre-commit b/.husky/pre-commit index 215439e2..6b16be9b 100755 --- a/.husky/pre-commit +++ b/.husky/pre-commit @@ -1,3 +1,3 @@ pnpm lint-staged pnpm typecheck -pnpm lint:process --staged +pnpm architect:guard --staged diff --git a/.mcp.json b/.mcp.json index 218eade2..33be4c0f 100644 --- a/.mcp.json +++ b/.mcp.json @@ -1,6 +1,6 @@ { "mcpServers": { - "delivery-process": { + "architect": { "command": "npx", "args": ["tsx", "src/cli/mcp-server.ts", "--watch"] } diff --git a/AGENTS.md b/AGENTS.md index 94a557dd..b7467108 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -4,23 +4,23 @@ This file helps future Codex sessions ramp up quickly in this repository. ## Project Identity -- Package: `@libar-dev/delivery-process` +- Package: `@libar-dev/architect` - Purpose: context engineering toolkit that extracts patterns from TypeScript + Gherkin into a queryable delivery state, generated docs, and workflow enforcement. - Core principle: code/spec annotations are the source of truth; generated docs are projections. ## Where To Read First -1. Manual docs index: `/Users/darkomijic/dev-projects/delivery-process/docs/INDEX.md` -2. Config entry point: `/Users/darkomijic/dev-projects/delivery-process/delivery-process.config.ts` -3. Live generated area index: `/Users/darkomijic/dev-projects/delivery-process/docs-live/PRODUCT-AREAS.md` +1. Manual docs index: `/Users/darkomijic/dev-projects/architect/docs/INDEX.md` +2. Config entry point: `/Users/darkomijic/dev-projects/architect/architect.config.ts` +3. Live generated area index: `/Users/darkomijic/dev-projects/architect/docs-live/PRODUCT-AREAS.md` 4. Key generated area docs: - - `/Users/darkomijic/dev-projects/delivery-process/docs-live/product-areas/ANNOTATION.md` - - `/Users/darkomijic/dev-projects/delivery-process/docs-live/product-areas/CONFIGURATION.md` - - `/Users/darkomijic/dev-projects/delivery-process/docs-live/product-areas/CORE-TYPES.md` - - `/Users/darkomijic/dev-projects/delivery-process/docs-live/product-areas/DATA-API.md` - - `/Users/darkomijic/dev-projects/delivery-process/docs-live/product-areas/GENERATION.md` - - `/Users/darkomijic/dev-projects/delivery-process/docs-live/product-areas/PROCESS.md` - - `/Users/darkomijic/dev-projects/delivery-process/docs-live/product-areas/VALIDATION.md` + - `/Users/darkomijic/dev-projects/architect/docs-live/product-areas/ANNOTATION.md` + - `/Users/darkomijic/dev-projects/architect/docs-live/product-areas/CONFIGURATION.md` + - `/Users/darkomijic/dev-projects/architect/docs-live/product-areas/CORE-TYPES.md` + - `/Users/darkomijic/dev-projects/architect/docs-live/product-areas/DATA-API.md` + - `/Users/darkomijic/dev-projects/architect/docs-live/product-areas/GENERATION.md` + - `/Users/darkomijic/dev-projects/architect/docs-live/product-areas/PROCESS.md` + - `/Users/darkomijic/dev-projects/architect/docs-live/product-areas/VALIDATION.md` ## Onboarding Context (Tutorial WIP) @@ -30,56 +30,56 @@ This file helps future Codex sessions ramp up quickly in this repository. - Important known alignment points from tutorial review: - `process-api overview` includes the Data API helper section in output (not always shown in article snippets). - Current `generate-docs --list-generators` output does not include `product-area-docs`. - - `generate-docs` accepts both repeated `-g` flags and comma-separated generator lists. + - `architect-generate` accepts both repeated `-g` flags and comma-separated generator lists. - Shape-derived entries can affect counts and `stubs` output (shape patterns appear as separate entries). - - `arch context` groups only patterns carrying explicit `@libar-docs-arch-context`. + - `arch context` groups only patterns carrying explicit `@architect-arch-context`. ## Consumer Repo Setup Conventions When guiding users in external repos, pick command style based on config format: -- If the repo uses `delivery-process.config.js` (or no config), package binaries are fine: +- If the repo uses `architect.config.js` (or no config), package binaries are fine: ```bash npx generate-docs --help -npx process-api --help +npx architect --help npx lint-patterns --help -npx lint-process --help +npx architect-guard --help npx validate-patterns --help ``` -- If the repo uses `delivery-process.config.ts`, use `tsx`-based wrappers (or switch to `.js` config). +- If the repo uses `architect.config.ts`, use `tsx`-based wrappers (or switch to `.js` config). - Reason: plain Node execution may fail to import `.ts` config files in some environments. -Use `delivery-process.config.ts` or `.js` as the main integration contract and keep scripts thin wrappers around package CLIs. +Use `architect.config.ts` or `.js` as the main integration contract and keep scripts thin wrappers around package CLIs. ## Architecture Snapshot - Pipeline: `Config -> Scanner -> Extractor -> Transformer -> Codec`. - Central read model: `MasterDataset` (consumed by docs generation, Data API, and validators). -- Preset in this repo config: `libar-generic` (`@libar-docs-*` tags). +- Preset in this repo config: `libar-generic` (`@architect-*` tags). - Source ownership invariant: - TypeScript owns runtime relationships (`uses`, `used-by`, category-like tags). - Gherkin owns planning/process metadata (`depends-on`, quarter, team, phase, deliverables). ## Repository Map -- Source code: `/Users/darkomijic/dev-projects/delivery-process/src` +- Source code: `/Users/darkomijic/dev-projects/architect/src` - Feature specs (roadmap/process/decisions/releases): - - `/Users/darkomijic/dev-projects/delivery-process/delivery-process/specs` - - `/Users/darkomijic/dev-projects/delivery-process/delivery-process/decisions` - - `/Users/darkomijic/dev-projects/delivery-process/delivery-process/releases` -- Design stubs (non-compiled on purpose): `/Users/darkomijic/dev-projects/delivery-process/delivery-process/stubs` + - `/Users/darkomijic/dev-projects/architect/architect/specs` + - `/Users/darkomijic/dev-projects/architect/architect/decisions` + - `/Users/darkomijic/dev-projects/architect/architect/releases` +- Design stubs (non-compiled on purpose): `/Users/darkomijic/dev-projects/architect/architect/stubs` - Tests: - - Feature files: `/Users/darkomijic/dev-projects/delivery-process/tests/features` - - Step definitions: `/Users/darkomijic/dev-projects/delivery-process/tests/steps` + - Feature files: `/Users/darkomijic/dev-projects/architect/tests/features` + - Step definitions: `/Users/darkomijic/dev-projects/architect/tests/steps` ## Session Workflow (Project Convention) Session types and expected outcomes: 1. Planning: create/update roadmap `.feature` spec (status typically `roadmap`). -2. Design: produce decision specs and/or stubs in `delivery-process/stubs/` (no implementation). +2. Design: produce decision specs and/or stubs in `architect/stubs/` (no implementation). 3. Implementation: transition `roadmap -> active -> completed` while implementing deliverables. FSM/protection conventions: @@ -93,20 +93,20 @@ FSM/protection conventions: Use the CLI instead of broad file exploration whenever possible: ```bash -pnpm process:query -- overview -pnpm process:query -- scope-validate implement -pnpm process:query -- context --session implement -pnpm process:query -- dep-tree -pnpm process:query -- files --related +pnpm architect:query -- overview +pnpm architect:query -- scope-validate implement +pnpm architect:query -- context --session implement +pnpm architect:query -- dep-tree +pnpm architect:query -- files --related ``` Useful discovery commands: ```bash -pnpm process:query -- list --status roadmap --names-only -pnpm process:query -- arch blocking -pnpm process:query -- stubs --unresolved -pnpm process:query -- unannotated --path src +pnpm architect:query -- list --status roadmap --names-only +pnpm architect:query -- arch blocking +pnpm architect:query -- stubs --unresolved +pnpm architect:query -- unannotated --path src ``` ## Build, Test, Validation Commands @@ -125,7 +125,7 @@ Process/quality checks: ```bash pnpm lint:steps pnpm lint-patterns -pnpm lint:process +pnpm architect:guard pnpm validate:patterns pnpm validate:dod pnpm validate:all @@ -169,11 +169,11 @@ Do not assume undocumented generator names are available without checking. ## Practical Start Checklist For New Sessions -1. Read `docs/INDEX.md` and `delivery-process.config.ts`. -2. Run `pnpm process:query -- overview`. +1. Read `docs/INDEX.md` and `architect.config.ts`. +2. Run `pnpm architect:query -- overview`. 3. If working on a specific pattern, run: - - `pnpm process:query -- scope-validate implement` - - `pnpm process:query -- context --session ` + - `pnpm architect:query -- scope-validate implement` + - `pnpm architect:query -- context --session ` 4. Make minimal source changes. 5. Run targeted tests + relevant lint/validation. 6. Regenerate docs if source annotations/specs/config changed. @@ -187,11 +187,11 @@ If implementing one, design for existing-repo adoption first: - Add a new bin command (example: `delivery-process-init`) so users can run `npx delivery-process-init`. 2. Wizard responsibilities - Detect package manager and module mode (`type: module`). - - Scaffold `delivery-process.config.ts` with chosen preset and discovered source globs. - - Offer optional npm scripts for `process-api`, docs generation, and validation commands. - - Optionally scaffold starter folders (`delivery-process/specs`, `delivery-process/stubs`) and sample spec/stub templates. + - Scaffold `architect.config.ts` with chosen preset and discovered source globs. + - Offer optional npm scripts for `architect`, docs generation, and validation commands. + - Optionally scaffold starter folders (`architect/specs`, `architect/stubs`) and sample spec/stub templates. 3. Safety requirements - Dry-run mode and explicit overwrite confirmations. - - Never silently overwrite existing `delivery-process.config.ts` or user scripts. + - Never silently overwrite existing `architect.config.ts` or user scripts. 4. Success criteria - User can run `process-api overview` and `generate-docs --list-generators` immediately after setup. diff --git a/CHANGELOG.md b/CHANGELOG.md index 11fda3e4..3d1a7ba0 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -27,5 +27,5 @@ First npm-published pre-release for monorepo validation. - `@libar-dev/modular-claude-md` moved from dependencies to devDependencies - Package size trimmed (removed self-referential docs from tarball) -[Unreleased]: https://github.com/libar-dev/delivery-process/compare/v1.0.0-pre.0...HEAD -[1.0.0-pre.0]: https://github.com/libar-dev/delivery-process/releases/tag/v1.0.0-pre.0 +[Unreleased]: https://github.com/libar-dev/architect/compare/v1.0.0-pre.0...HEAD +[1.0.0-pre.0]: https://github.com/libar-dev/architect/releases/tag/v1.0.0-pre.0 diff --git a/CLAUDE.md b/CLAUDE.md index 1869d8c2..e02dd6df 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,4 +1,4 @@ -# @libar-dev/delivery-process +# @libar-dev/architect > **Code-first documentation and delivery process toolkit** @@ -55,12 +55,12 @@ The API returns structured, current data using 5-10x less context than file read #### PR / Session Start (run these FIRST) -| Step | Command | What You Get | -| ---- | ---------------------------------------------------------- | ------------------------------------------- | -| 1 | `pnpm process:query -- overview` | Project health, active phases, blockers | -| 2 | `pnpm process:query -- scope-validate ` | Pre-flight: FSM violations, missing deps | -| 3 | `pnpm process:query -- context --session ` | Curated context bundle for the session | -| 4 | `pnpm process:query -- files --related` | File reading list with implementation paths | +| Step | Command | What You Get | +| ---- | ------------------------------------------------------------ | ------------------------------------------- | +| 1 | `pnpm architect:query -- overview` | Project health, active phases, blockers | +| 2 | `pnpm architect:query -- scope-validate ` | Pre-flight: FSM violations, missing deps | +| 3 | `pnpm architect:query -- context --session ` | Curated context bundle for the session | +| 4 | `pnpm architect:query -- files --related` | File reading list with implementation paths | Session types: `planning` (minimal), `design` (full: stubs + deps + deliverables), `implement` (focused: deliverables + FSM + tests). @@ -71,11 +71,11 @@ Session types: `planning` (minimal), `design` (full: stubs + deps + deliverables | Find code structure | `arch context [name]` / `arch layer [name]` | Structured by annotations, not file paths | | Find dependencies | `dep-tree ` | Shows status of each dependency | | Find business rules | `rules --pattern ` | Extracted from Gherkin Rule: blocks | -| Find unannotated files | `unannotated --path ` | Catches missing @libar-docs markers | +| Find unannotated files | `unannotated --path ` | Catches missing @architect markers | | Check FSM state | `query getProtectionInfo ` | Protection level + allowed actions | | Check valid transitions | `query getValidTransitionsFrom ` | Valid next states from current status | | Tag inventory | `tags` | Counts per tag and value across all sources | -| Annotation coverage | `arch coverage` | Files with/without @libar-docs annotations | +| Annotation coverage | `arch coverage` | Files with/without @architect annotations | #### Why Annotations Beat Grep @@ -84,9 +84,9 @@ Session types: `planning` (minimal), `design` (full: stubs + deps + deliverables - **Feed generation**: Annotations produce generated docs; grep results are ephemeral - **Discoverable**: `unannotated --path` finds gaps; grep doesn't know what's missing -**When adding new code:** Add `@libar-docs` annotations and relationship tags (`@libar-docs-depends-on`, `@libar-docs-uses`) so future sessions can discover the code via API queries instead of grep. +**When adding new code:** Add `@architect` annotations and relationship tags (`@architect-depends-on`, `@architect-uses`) so future sessions can discover the code via API queries instead of grep. -Full CLI reference: `pnpm process:query -- --help` +Full CLI reference: `pnpm architect:query -- --help` --- @@ -113,9 +113,9 @@ pnpm validate:all # All validations including anti-patterns and DoD pnpm docs:all # Generate all doc types # Data API (see Context Gathering Protocol above) -pnpm process:query -- --help # All subcommands and options -pnpm process:query -- context --session design # Session context bundle -pnpm process:query -- overview # Project health summary +pnpm architect:query -- --help # All subcommands and options +pnpm architect:query -- context --session design # Session context bundle +pnpm architect:query -- overview # Project health summary ``` --- @@ -126,7 +126,7 @@ pnpm process:query -- overview # Project health summa Query delivery process state directly from the terminal. **Use this instead of reading generated markdown or launching explore agents** — targeted queries use 5-10x less context. -**Run `pnpm process:query -- --help` for the full command reference**, including workflow recipes, session types, architecture queries, output modifiers, and available API methods. +**Run `pnpm architect:query -- --help` for the full command reference**, including workflow recipes, session types, architecture queries, output modifiers, and available API methods. See the **Context Gathering Protocol** section above for mandatory session start commands and query recipes. @@ -139,18 +139,18 @@ See the **Context Gathering Protocol** section above for mandatory session start ### MCP Server — Native AI Context Tools -When the MCP server is running, **use `dp_*` tools instead of CLI commands** (`pnpm process:query --`). The MCP server keeps the MasterDataset in memory — tool calls dispatch in sub-milliseconds vs 2-5 seconds for CLI subprocess invocations. All 25 tools wrap the same ProcessStateAPI methods available via CLI. +When the MCP server is running, **use `architect_*` tools instead of CLI commands** (`pnpm architect:query --`). The MCP server keeps the MasterDataset in memory — tool calls dispatch in sub-milliseconds vs 2-5 seconds for CLI subprocess invocations. All 25 tools wrap the same ProcessStateAPI methods available via CLI. #### Session Start (MCP Protocol) Use these tools at the start of every PR or implementation session, in order: -| Step | MCP Tool | What You Get | CLI Equivalent | -| ---- | ------------------- | ------------------------------------------- | ------------------------------------------------- | -| 1 | `dp_overview` | Project health, active phases, blockers | `pnpm process:query -- overview` | -| 2 | `dp_scope_validate` | Pre-flight: FSM violations, missing deps | `pnpm process:query -- scope-validate

` | -| 3 | `dp_context` | Curated context bundle for the session | `pnpm process:query -- context

--session ` | -| 4 | `dp_files` | File reading list with implementation paths | `pnpm process:query -- files

--related` | +| Step | MCP Tool | What You Get | CLI Equivalent | +| ---- | -------------------------- | ------------------------------------------- | --------------------------------------------------- | +| 1 | `architect_overview` | Project health, active phases, blockers | `pnpm architect:query -- overview` | +| 2 | `architect_scope_validate` | Pre-flight: FSM violations, missing deps | `pnpm architect:query -- scope-validate

` | +| 3 | `architect_context` | Curated context bundle for the session | `pnpm architect:query -- context

--session ` | +| 4 | `architect_files` | File reading list with implementation paths | `pnpm architect:query -- files

--related` | Steps 1-2 can run in parallel (no dependencies between them). @@ -158,61 +158,61 @@ Steps 1-2 can run in parallel (no dependencies between them). **Session-Aware Tools** — text output, use for workflow: -| Tool | Input | Description | -| ------------------- | ------------------- | ---------------------------------------------- | -| `dp_overview` | _(none)_ | Progress %, active phases, blocking chains | -| `dp_context` | `name`, `session?` | Curated context (planning/design/implement) | -| `dp_files` | `name` | Ordered file list with roles | -| `dp_dep_tree` | `name`, `maxDepth?` | Dependency chain with status per dep | -| `dp_scope_validate` | `name`, `session` | PASS/BLOCKED/WARN pre-flight verdict | -| `dp_handoff` | `name`, `session?` | Session-end state for multi-session continuity | +| Tool | Input | Description | +| -------------------------- | ------------------- | ---------------------------------------------- | +| `architect_overview` | _(none)_ | Progress %, active phases, blocking chains | +| `architect_context` | `name`, `session?` | Curated context (planning/design/implement) | +| `architect_files` | `name` | Ordered file list with roles | +| `architect_dep_tree` | `name`, `maxDepth?` | Dependency chain with status per dep | +| `architect_scope_validate` | `name`, `session` | PASS/BLOCKED/WARN pre-flight verdict | +| `architect_handoff` | `name`, `session?` | Session-end state for multi-session continuity | **Data Query Tools** — JSON output, use for structured lookups: -| Tool | Input | Description | -| -------------- | -------------------------------------------------------- | -------------------------------------------------- | -| `dp_status` | _(none)_ | Pattern counts by status, completion % | -| `dp_pattern` | `name` | Full metadata: deliverables, relationships, shapes | -| `dp_list` | `status?`, `phase?`, `category?`, `namesOnly?`, `count?` | Filtered pattern listing | -| `dp_search` | `query` | Fuzzy name search with similarity scores | -| `dp_rules` | `pattern?`, `onlyInvariants?` | Business rules from Gherkin Rule: blocks | -| `dp_tags` | _(none)_ | Tag usage counts across all sources | -| `dp_sources` | _(none)_ | File inventory by type (TS, Gherkin, stubs) | -| `dp_stubs` | `unresolved?` | Design stubs with resolution status | -| `dp_decisions` | `name?` | AD-N/DD-N design decisions from stubs | +| Tool | Input | Description | +| --------------------- | -------------------------------------------------------- | -------------------------------------------------- | +| `architect_status` | _(none)_ | Pattern counts by status, completion % | +| `architect_pattern` | `name` | Full metadata: deliverables, relationships, shapes | +| `architect_list` | `status?`, `phase?`, `category?`, `namesOnly?`, `count?` | Filtered pattern listing | +| `architect_search` | `query` | Fuzzy name search with similarity scores | +| `architect_rules` | `pattern?`, `onlyInvariants?` | Business rules from Gherkin Rule: blocks | +| `architect_tags` | _(none)_ | Tag usage counts across all sources | +| `architect_sources` | _(none)_ | File inventory by type (TS, Gherkin, stubs) | +| `architect_stubs` | `unresolved?` | Design stubs with resolution status | +| `architect_decisions` | `name?` | AD-N/DD-N design decisions from stubs | **Architecture Tools** — JSON output, use for dependency and structure analysis: -| Tool | Input | Description | -| ---------------------- | -------- | ------------------------------------------- | -| `dp_arch_context` | `name?` | Bounded contexts with member patterns | -| `dp_arch_layer` | `name?` | Architecture layers with member patterns | -| `dp_arch_neighborhood` | `name` | Uses, used-by, same-context peers | -| `dp_arch_blocking` | _(none)_ | Patterns blocked by incomplete dependencies | -| `dp_arch_dangling` | _(none)_ | Broken references to nonexistent patterns | -| `dp_arch_coverage` | `path?` | Annotation coverage % and unused taxonomy | -| `dp_unannotated` | `path?` | Files missing @libar-docs annotations | +| Tool | Input | Description | +| ----------------------------- | -------- | ------------------------------------------- | +| `architect_arch_context` | `name?` | Bounded contexts with member patterns | +| `architect_arch_layer` | `name?` | Architecture layers with member patterns | +| `architect_arch_neighborhood` | `name` | Uses, used-by, same-context peers | +| `architect_arch_blocking` | _(none)_ | Patterns blocked by incomplete dependencies | +| `architect_arch_dangling` | _(none)_ | Broken references to nonexistent patterns | +| `architect_arch_coverage` | `path?` | Annotation coverage % and unused taxonomy | +| `architect_unannotated` | `path?` | Files missing @architect annotations | **Server Management:** -| Tool | Description | -| ------------ | ------------------------------------------------------ | -| `dp_rebuild` | Force dataset rebuild from current source files | -| `dp_config` | Show source globs, base dir, build time, pattern count | -| `dp_help` | List all available tools with descriptions | +| Tool | Description | +| ------------------- | ------------------------------------------------------ | +| `architect_rebuild` | Force dataset rebuild from current source files | +| `architect_config` | Show source globs, base dir, build time, pattern count | +| `architect_help` | List all available tools with descriptions | #### Common Recipes -| Goal | Tools | -| ---------------------------------- | ------------------------------------------------------------------ | -| What patterns are blocking? | `dp_arch_blocking` | -| Understand a pattern before coding | `dp_context` (name, session) + `dp_scope_validate` (name, session) | -| Find business rules for a feature | `dp_rules` with `pattern` filter | -| Check annotation gaps | `dp_arch_coverage` or `dp_unannotated` | -| Explore a bounded context | `dp_arch_context` with name | -| Find what depends on a pattern | `dp_arch_neighborhood` with name | -| List all roadmap patterns | `dp_list` with `status: "roadmap"` | -| Search by partial name | `dp_search` with query | +| Goal | Tools | +| ---------------------------------- | -------------------------------------------------------------------------------- | +| What patterns are blocking? | `architect_arch_blocking` | +| Understand a pattern before coding | `architect_context` (name, session) + `architect_scope_validate` (name, session) | +| Find business rules for a feature | `architect_rules` with `pattern` filter | +| Check annotation gaps | `architect_arch_coverage` or `architect_unannotated` | +| Explore a bounded context | `architect_arch_context` with name | +| Find what depends on a pattern | `architect_arch_neighborhood` with name | +| List all roadmap patterns | `architect_list` with `status: "roadmap"` | +| Search by partial name | `architect_search` with query | #### Configuration @@ -221,9 +221,9 @@ The MCP server is configured via `.mcp.json` in the project root: ```json { "mcpServers": { - "delivery-process": { + "architect": { "command": "npx", - "args": ["dp-mcp-server", "--watch"] + "args": ["architect-mcp", "--watch"] } } } @@ -234,10 +234,10 @@ For monorepo setups with explicit source globs: ```json { "mcpServers": { - "delivery-process": { + "architect": { "command": "npx", "args": [ - "dp-mcp-server", + "architect-mcp", "--watch", "--input", "packages/core/src/**/*.ts", @@ -251,14 +251,14 @@ For monorepo setups with explicit source globs: } ``` -The `--watch` flag enables auto-rebuild when `.ts` or `.feature` files change (500ms debounce). Without it, use `dp_rebuild` after annotation changes. +The `--watch` flag enables auto-rebuild when `.ts` or `.feature` files change (500ms debounce). Without it, use `architect_rebuild` after annotation changes. #### Tips -- `dp_rules` without a `pattern` filter returns a compact summary (totals + rule names + per-area counts) — unfiltered output is capped to prevent context overflow. -- `dp_pattern` returns full metadata (~66KB for completed patterns) — prefer `dp_context` with a session type for interactive sessions. -- `dp_search` uses fuzzy matching — partial names work (e.g., "MCP" matches all MCP-related patterns). -- `dp_list` filters compose: `status` + `phase` + `category` narrow results cumulatively. +- `architect_rules` without a `pattern` filter returns a compact summary (totals + rule names + per-area counts) — unfiltered output is capped to prevent context overflow. +- `architect_pattern` returns full metadata (~66KB for completed patterns) — prefer `architect_context` with a session type for interactive sessions. +- `architect_search` uses fuzzy matching — partial names work (e.g., "MCP" matches all MCP-related patterns). +- `architect_list` filters compose: `status` + `phase` + `category` narrow results cumulatively. - Session-aware tools return formatted text (like CLI output). Data and architecture tools return JSON. --- @@ -272,7 +272,7 @@ CONFIG → SCANNER → EXTRACTOR → TRANSFORMER → CODEC (files) (patterns) (MasterDataset) (Markdown) ``` -1. **Scanner** (`src/scanner/`): File discovery, AST parsing, opt-in detection via `@libar-docs` marker +1. **Scanner** (`src/scanner/`): File discovery, AST parsing, opt-in detection via `@architect` marker 2. **Extractor** (`src/extractor/`): Pattern extraction from TypeScript JSDoc and Gherkin tags 3. **Transformer** (`src/generators/pipeline/`): Builds MasterDataset with pre-computed views 4. **Codec** (`src/renderable/`): Zod 4 codecs transform MasterDataset → RenderableDocument → Markdown @@ -286,11 +286,11 @@ CONFIG → SCANNER → EXTRACTOR → TRANSFORMER → CODEC - **Pipeline Factory**: Shared `buildMasterDataset()` in `src/generators/pipeline/build-pipeline.ts` — all consumers (orchestrator, process-api, validate-patterns) call this instead of wiring inline pipelines. Per-consumer behavior via `PipelineOptions`. - **Single Read Model** (ADR-006): MasterDataset is the sole read model. No consumer re-derives data from raw scanner/extractor output. Anti-patterns: Parallel Pipeline, Lossy Local Type, Re-derived Relationship. -**Live module inventory:** `pnpm process:query -- arch context` and `pnpm process:query -- arch layer` +**Live module inventory:** `pnpm architect:query -- arch context` and `pnpm architect:query -- arch layer` ### Decision Specs -Architecture and process decisions are recorded as annotated Gherkin specs in `delivery-process/decisions/`: +Architecture and process decisions are recorded as annotated Gherkin specs in `architect/decisions/`: | Spec | Key Decision | | ------- | -------------------------------------------------------------------------- | @@ -301,7 +301,7 @@ Architecture and process decisions are recorded as annotated Gherkin specs in `d | ADR-006 | Single read model — MasterDataset is the sole read model for all consumers | | PDR-001 | Session workflow commands — Process Data API CLI design decisions | -Query decisions: `pnpm process:query -- decisions ` +Query decisions: `pnpm architect:query -- decisions ` --- @@ -580,7 +580,7 @@ console.log(JSON.stringify(doc.sections, null, 2)); **Invariant:** A design session makes architectural decisions and creates code stubs with interfaces. It must not produce implementation code. Context gathering via the Process Data API must precede any explore agent usage. -**Rationale:** Design sessions resolve ambiguity before implementation begins. Code stubs in delivery-process/stubs/ live outside src/ to avoid TypeScript compilation and ESLint issues, making them zero-risk artifacts. +**Rationale:** Design sessions resolve ambiguity before implementation begins. Code stubs in architect/stubs/ live outside src/ to avoid TypeScript compilation and ESLint issues, making them zero-risk artifacts. | Use Design Session | Skip Design Session | | -------------------------- | ------------------- | @@ -615,11 +615,11 @@ console.log(JSON.stringify(doc.sections, null, 2)); | session-scope (warning) | Modified file outside session scope | Add to scope OR use --ignore-session | | session-excluded | Modified excluded pattern during session | Remove from exclusion OR override | -| Situation | Solution | Example | -| ---------------------------- | --------------------- | -------------------------------------- | -| Fix bug in completed spec | Add unlock reason tag | libar-docs-unlock-reason:Fix-typo | -| Modify outside session scope | Use ignore flag | lint-process --staged --ignore-session | -| CI treats warnings as errors | Use strict flag | lint-process --all --strict | +| Situation | Solution | Example | +| ---------------------------- | --------------------- | ----------------------------------------- | +| Fix bug in completed spec | Add unlock reason tag | libar-docs-unlock-reason:Fix-typo | +| Modify outside session scope | Use ignore flag | architect-guard --staged --ignore-session | +| CI treats warnings as errors | Use strict flag | architect-guard --all --strict | #### Handoff captures session-end state for continuity @@ -629,9 +629,9 @@ console.log(JSON.stringify(doc.sections, null, 2)); #### ClaudeModuleGeneration is the generation mechanism -**Invariant:** Phase 39 depends on ClaudeModuleGeneration (Phase 25). Adding `@libar-docs-claude-module` and `@libar-docs-claude-section:workflow` tags to this spec will cause ClaudeModuleGeneration to produce `_claude-md/workflow/` output files. The hand-written `_claude-md/workflow/` files are deleted after successful verified generation. +**Invariant:** Phase 39 depends on ClaudeModuleGeneration (Phase 25). Adding `@architect-claude-module` and `@architect-claude-section:workflow` tags to this spec will cause ClaudeModuleGeneration to produce `_claude-md/workflow/` output files. The hand-written `_claude-md/workflow/` files are deleted after successful verified generation. -**Rationale:** The annotation work (Rule blocks in this spec) is immediately useful — queryable via `pnpm process:query -- rules`. Generation deliverables cannot complete until Phase 25 ships the ClaudeModuleCodec. This sequencing is intentional: the annotation investment has standalone value regardless of whether the codec exists yet. +**Rationale:** The annotation work (Rule blocks in this spec) is immediately useful — queryable via `pnpm architect:query -- rules`. Generation deliverables cannot complete until Phase 25 ships the ClaudeModuleCodec. This sequencing is intentional: the annotation investment has standalone value regardless of whether the codec exists yet. --- @@ -641,23 +641,23 @@ console.log(JSON.stringify(doc.sections, null, 2)); Process Guard validates delivery workflow changes at commit time using a Decider pattern. -Query validation rules: `pnpm process:query -- rules --pattern ProcessGuard` -Query protection levels: `pnpm process:query -- query getProtectionInfo ` +Query validation rules: `pnpm architect:query -- rules --pattern ProcessGuard` +Query protection levels: `pnpm architect:query -- query getProtectionInfo ` #### CLI Usage ```bash # Pre-commit (default mode) -lint-process --staged +architect-guard --staged # CI pipeline with strict mode -lint-process --all --strict +architect-guard --all --strict # Debug: show derived process state -lint-process --staged --show-state +architect-guard --staged --show-state # Override session scope checking -lint-process --staged --ignore-session +architect-guard --staged --ignore-session ``` #### Exit Codes @@ -673,12 +673,12 @@ Enforces dual-source architecture ownership between TypeScript and Gherkin files #### Tag Location Constraints -| Tag | Correct Location | Wrong Location | Why | -| ------------------------ | ---------------- | -------------- | ---------------------------------- | -| `@libar-docs-uses` | TypeScript | Feature files | TS owns runtime dependencies | -| `@libar-docs-depends-on` | Feature files | TypeScript | Gherkin owns planning dependencies | -| `@libar-docs-quarter` | Feature files | TypeScript | Gherkin owns timeline metadata | -| `@libar-docs-team` | Feature files | TypeScript | Gherkin owns ownership metadata | +| Tag | Correct Location | Wrong Location | Why | +| ----------------------- | ---------------- | -------------- | ---------------------------------- | +| `@architect-uses` | TypeScript | Feature files | TS owns runtime dependencies | +| `@architect-depends-on` | Feature files | TypeScript | Gherkin owns planning dependencies | +| `@architect-quarter` | Feature files | TypeScript | Gherkin owns timeline metadata | +| `@architect-team` | Feature files | TypeScript | Gherkin owns ownership metadata | #### DoD Validation @@ -698,10 +698,10 @@ Run: `pnpm validate:all` for full validation including anti-patterns and DoD. #### Roadmap Spec Structure ```gherkin -@libar-docs -@libar-docs-pattern:ProcessGuardLinter -@libar-docs-status:roadmap -@libar-docs-phase:99 +@architect +@architect-pattern:ProcessGuardLinter +@architect-status:roadmap +@architect-phase:99 Feature: Process Guard Linter **Problem:** @@ -724,7 +724,7 @@ Feature: Process Guard Linter | Value-First | `**Business Value:**`, `**How It Works:**` | TDD-style specs | | Context/Approach | `**Context:**`, `**Approach:**` | Technical patterns | -Tag inventory: `pnpm process:query -- tags` (counts per tag and value across all sources). +Tag inventory: `pnpm architect:query -- tags` (counts per tag and value across all sources). #### Rule Block Structure (Mandatory) @@ -772,7 +772,7 @@ Rule: Reservations use atomic claim See `src/reservations/reserve.ts` for API. ``` -Code stubs live in `delivery-process/stubs/{pattern-name}/` — annotated TypeScript with `throw new Error("not yet implemented")`. +Code stubs live in `architect/stubs/{pattern-name}/` — annotated TypeScript with `throw new Error("not yet implemented")`. #### Forbidden in Feature Descriptions @@ -787,9 +787,9 @@ Code stubs live in `delivery-process/stubs/{pattern-name}/` — annotated TypeSc **Tag values cannot contain spaces.** Use hyphens instead: -| Invalid | Valid | -| -------------------------------- | ------------------------------- | -| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | -| `@libar-docs-pattern:My Pattern` | `@libar-docs-pattern:MyPattern` | +| Invalid | Valid | +| ------------------------------- | ------------------------------ | +| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | +| `@architect-pattern:My Pattern` | `@architect-pattern:MyPattern` | --- diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9065816c..18730a18 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,4 +1,4 @@ -# Contributing to @libar-dev/delivery-process +# Contributing to @libar-dev/architect We welcome contributions! This guide covers how to get started. @@ -69,7 +69,7 @@ These run automatically — no manual setup needed after `pnpm install`. ## Reporting Issues -- Use [GitHub Issues](https://github.com/libar-dev/delivery-process/issues) +- Use [GitHub Issues](https://github.com/libar-dev/architect/issues) - For security vulnerabilities, see [SECURITY.md](SECURITY.md) ## Code of Conduct diff --git a/LICENSE b/LICENSE index 71521c03..c5064c1e 100644 --- a/LICENSE +++ b/LICENSE @@ -1,3 +1,7 @@ +This MIT license applies to all files in this repository EXCEPT those in the +src/mcp/ directory, which are licensed under the Business Source License 1.1 +(see LICENSE-MCP). + MIT License Copyright (c) 2024-2026 libar-dev diff --git a/LICENSE-MCP b/LICENSE-MCP new file mode 100644 index 00000000..2dedbea1 --- /dev/null +++ b/LICENSE-MCP @@ -0,0 +1,62 @@ +Business Source License 1.1 + +Parameters + +Licensor: EBIZ d.o.o. +Licensed Work: The files in the src/mcp/ directory of the Architect + software. The Licensed Work is (c) 2026 EBIZ d.o.o. +Additional Use Grant: You may use the Licensed Work for internal development + purposes, including using the MCP server tools for + querying project data. You may not redistribute the + Licensed Work as part of a competing commercial product + that provides MCP-based project context tools. +Change Date: 2030-03-14 +Change License: MIT License + +For information about alternative licensing arrangements for the Licensed Work, +please contact licensing@libar.ai. + +Notice + +Business Source License 1.1 + +Terms + +The Licensor hereby grants you the right to copy, modify, create derivative +works, redistribute, and make non-production use of the Licensed Work. The +Licensor may make an Additional Use Grant, above, permitting limited production +use. + +Effective on the Change Date, or the fourth anniversary of the first publicly +available distribution of a specific version of the Licensed Work under this +License, whichever comes first, the Licensor hereby grants you rights under the +terms of the Change License, and the rights granted in the paragraph above +terminate. + +If your use of the Licensed Work does not comply with the requirements currently +in effect as described in this License, you must purchase a commercial license +from the Licensor, its affiliated entities, or authorized resellers, or you must +refrain from using the Licensed Work. + +All copies of the original and modified Licensed Work, and derivative works of +the Licensed Work, are subject to this License. This License applies separately +for each version of the Licensed Work and the Change Date may vary for each +version of the Licensed Work released by Licensor. + +You must conspicuously display this License on each original or modified copy of +the Licensed Work. If you receive the Licensed Work in original or modified form +from a third party, the terms and conditions set forth in this License apply to +your use of that work. + +Any use of the Licensed Work in violation of this License will automatically +terminate your rights under this License for the current and all other versions +of the Licensed Work. + +This License does not grant you any right in any trademark or logo of Licensor +or its affiliates (provided that you may use a trademark or logo of Licensor as +expressly required by this License). + +TO THE EXTENT PERMITTED BY APPLICABLE LAW, THE LICENSED WORK IS PROVIDED ON AN +"AS IS" BASIS. LICENSOR HEREBY DISCLAIMS ALL WARRANTIES AND CONDITIONS, EXPRESS +OR IMPLIED, INCLUDING (WITHOUT LIMITATION) WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, AND TITLE. diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 8491e633..c700a5b4 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -1,6 +1,6 @@ # Maintainer Guide -This guide covers how to publish `@libar-dev/delivery-process` to npm. +This guide covers how to publish `@libar-dev/architect` to npm. ## Prerequisites @@ -12,10 +12,10 @@ This guide covers how to publish `@libar-dev/delivery-process` to npm. We use semantic versioning with pre-release tags: -| Tag | Purpose | Install Command | -| -------- | ------------------------ | --------------------------------------- | -| `latest` | Stable releases | `npm i @libar-dev/delivery-process` | -| `pre` | Pre-releases (1.0.0-pre) | `npm i @libar-dev/delivery-process@pre` | +| Tag | Purpose | Install Command | +| -------- | ------------------------ | -------------------------------- | +| `latest` | Stable releases | `npm i @libar-dev/architect` | +| `pre` | Pre-releases (1.0.0-pre) | `npm i @libar-dev/architect@pre` | ## Publishing Workflow @@ -50,7 +50,7 @@ npm publish --tag pre --access public 1. Remove `"tag": "pre"` from `publishConfig` (or change to `"tag": "latest"`) 2. Verify with `npm publish --dry-run --access public` (should show tag `latest`, not `pre`) -If you skip this step, stable versions will be published under the `pre` dist-tag and users running `npm install @libar-dev/delivery-process` won't get them. +If you skip this step, stable versions will be published under the `pre` dist-tag and users running `npm install @libar-dev/architect` won't get them. ```bash # Patch release (1.0.0 → 1.0.1) @@ -114,15 +114,15 @@ After publishing, verify the package: ```bash # Check npm registry -npm view @libar-dev/delivery-process +npm view @libar-dev/architect # Check dist-tags -npm view @libar-dev/delivery-process dist-tags +npm view @libar-dev/architect dist-tags # Install in a test project mkdir /tmp/test-install && cd /tmp/test-install npm init -y -npm install @libar-dev/delivery-process@pre +npm install @libar-dev/architect@pre ``` ## Troubleshooting @@ -140,5 +140,5 @@ npm can take a few minutes to propagate. If still not found: ```bash npm cache clean --force -npm view @libar-dev/delivery-process +npm view @libar-dev/architect ``` diff --git a/README.md b/README.md index 8d99a708..81bb3d02 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,13 @@ -# @libar-dev/delivery-process +# @libar-dev/architect **Context engineering for AI-assisted codebases.** Turn TypeScript annotations and Gherkin specs into a **structured, queryable delivery state** — living documentation, architecture graphs, and FSM-enforced workflows that AI agents consume without hallucinating. -[![npm version](https://img.shields.io/npm/v/@libar-dev/delivery-process.svg)](https://www.npmjs.com/package/@libar-dev/delivery-process) -[![Build Status](https://github.com/libar-dev/delivery-process/workflows/CI/badge.svg)](https://github.com/libar-dev/delivery-process/actions) +[![npm version](https://img.shields.io/npm/v/@libar-dev/architect.svg)](https://www.npmjs.com/package/@libar-dev/architect) +[![Build Status](https://github.com/libar-dev/architect/workflows/CI/badge.svg)](https://github.com/libar-dev/architect/actions) [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT) -[![Node.js Version](https://img.shields.io/node/v/@libar-dev/delivery-process.svg)](https://nodejs.org/) +[![Node.js Version](https://img.shields.io/node/v/@libar-dev/architect.svg)](https://nodejs.org/) --- @@ -23,10 +23,10 @@ AI coding agents need architectural context to generate correct code. This packa ```bash # npm -npm install @libar-dev/delivery-process@pre +npm install @libar-dev/architect@pre # pnpm (recommended) -pnpm add @libar-dev/delivery-process@pre +pnpm add @libar-dev/architect@pre ``` **Requirements:** Node.js >= 18.0.0, ESM project (`"type": "module"` in package.json) @@ -50,7 +50,7 @@ export class UserAuthentication { } ``` -> Tag prefix is configurable. The `generic` preset uses `@docs-*` (shown above). The default `libar-generic` preset uses `@libar-docs-*`. See [docs/CONFIGURATION.md](docs/CONFIGURATION.md). +> Tag prefix is configurable. The `generic` preset uses `@docs-*` (shown above). The default `libar-generic` preset uses `@architect-*`. See [docs/CONFIGURATION.md](docs/CONFIGURATION.md). ### 3. Generate Documentation @@ -61,7 +61,7 @@ npx generate-docs -g patterns -i "src/**/*.ts" -o docs -f ### 4. Enforce Workflow (Pre-commit Hook) ```bash -npx lint-process --staged +npx architect-guard --staged ``` This validates FSM transitions and blocks invalid status changes. @@ -74,10 +74,10 @@ This validates FSM transitions and blocks invalid status changes. ```typescript /** - * @libar-docs - * @libar-docs-pattern TransformDataset - * @libar-docs-status completed - * @libar-docs-uses MasterDataset, ExtractedPattern, TagRegistry + * @architect + * @architect-pattern TransformDataset + * @architect-status completed + * @architect-uses MasterDataset, ExtractedPattern, TagRegistry */ export function transformToMasterDataset(input: TransformInput): MasterDataset { // ... @@ -113,14 +113,14 @@ All output goes to [`docs-live/`](docs-live/INDEX.md) — 57+ auto-generated fil ## CLI Commands -| Command | Purpose | Docs | -| ------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------- | -| `generate-docs` | Generate documentation from annotated sources | `generate-docs --help` | -| `process-api` | Query delivery state for AI coding sessions | [Process API Reference](docs-live/reference/PROCESS-API-REFERENCE.md) | -| `lint-patterns` | Validate annotation quality (missing tags, etc.) | [Validation Rules](docs-live/VALIDATION-RULES.md) | -| `lint-process` | Validate delivery workflow FSM transitions | [Process Guard Reference](docs-live/reference/PROCESS-GUARD-REFERENCE.md) | -| `lint-steps` | Validate vitest-cucumber feature/step compatibility | [Validation Rules](docs-live/VALIDATION-RULES.md) | -| `validate-patterns` | Cross-source validation with Definition of Done checks | [Validation Rules](docs-live/VALIDATION-RULES.md) | +| Command | Purpose | Docs | +| ------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------- | +| `architect-generate` | Generate documentation from annotated sources | `generate-docs --help` | +| `architect` | Query delivery state for AI coding sessions | [Process API Reference](docs-live/reference/PROCESS-API-REFERENCE.md) | +| `architect-lint-patterns` | Validate annotation quality (missing tags, etc.) | [Validation Rules](docs-live/VALIDATION-RULES.md) | +| `architect-guard` | Validate delivery workflow FSM transitions | [Process Guard Reference](docs-live/reference/PROCESS-GUARD-REFERENCE.md) | +| `architect-lint-steps` | Validate vitest-cucumber feature/step compatibility | [Validation Rules](docs-live/VALIDATION-RULES.md) | +| `architect-validate` | Cross-source validation with Definition of Done checks | [Validation Rules](docs-live/VALIDATION-RULES.md) | --- diff --git a/SECURITY.md b/SECURITY.md index 9a6b8121..2dd914e4 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -11,7 +11,7 @@ If you discover a security vulnerability, please report it responsibly: 1. **Do NOT open a public issue** -2. Use [GitHub's private vulnerability reporting](https://github.com/libar-dev/delivery-process/security/advisories/new) +2. Use [GitHub's private vulnerability reporting](https://github.com/libar-dev/architect/security/advisories/new) 3. Or email: security@libar.dev We will acknowledge receipt within 48 hours and provide an initial assessment within 7 days. diff --git a/_claude-md/api/annotation-system.md b/_claude-md/api/annotation-system.md index 6a30416f..6dad9928 100644 --- a/_claude-md/api/annotation-system.md +++ b/_claude-md/api/annotation-system.md @@ -3,20 +3,20 @@ Files must opt-in with a marker to be scanned: ```typescript -/** @libar-docs */ +/** @architect */ /** - * @libar-docs-pattern PatternName - * @libar-docs-status completed - * @libar-docs-core - * @libar-docs-uses OtherPattern + * @architect-pattern PatternName + * @architect-status completed + * @architect-core + * @architect-uses OtherPattern * * ## Description in markdown */ export class MyClass { ... } ``` -**Note:** Both TypeScript files and Gherkin feature files require the `@libar-docs` opt-in marker. For TypeScript, use a JSDoc comment `/** @libar-docs */`. For Gherkin, add the `@libar-docs` tag at the feature level. +**Note:** Both TypeScript files and Gherkin feature files require the `@architect` opt-in marker. For TypeScript, use a JSDoc comment `/** @architect */`. For Gherkin, add the `@architect` tag at the feature level. #### Key Tags @@ -37,14 +37,14 @@ export class MyClass { ... } | `arch-context` | value | Bounded context grouping (free-form): e.g. `orders`, `inventory`, `agent` — omit for cross-cutting | | `arch-layer` | enum | Architecture layer: `domain`, `application`, `infrastructure` | -**Category tags** are flags (no value): `@libar-docs-core`, `@libar-docs-api`, `@libar-docs-infra`, `@libar-docs-domain`, etc. +**Category tags** are flags (no value): `@architect-core`, `@architect-api`, `@architect-infra`, `@architect-domain`, etc. #### CLI Commands -| Command | Purpose | -| ----------------------- | ---------------------------------------------------------- | -| `generate-docs` | Generate documentation from annotated sources | -| `lint-patterns` | Validate annotation quality (missing tags, invalid status) | -| `lint-process` | FSM validation for delivery process | -| `validate-patterns` | Cross-source validation with DoD checks | -| `generate-tag-taxonomy` | Generate tag reference from TypeScript | +| Command | Purpose | +| ------------------------- | ---------------------------------------------------------- | +| `architect-generate` | Generate documentation from annotated sources | +| `architect-lint-patterns` | Validate annotation quality (missing tags, invalid status) | +| `architect-guard` | FSM validation for delivery process | +| `architect-validate` | Cross-source validation with DoD checks | +| `architect-taxonomy` | Generate tag reference from TypeScript | diff --git a/_claude-md/api/data-api-cli.md b/_claude-md/api/data-api-cli.md index a9b501a8..2639b38b 100644 --- a/_claude-md/api/data-api-cli.md +++ b/_claude-md/api/data-api-cli.md @@ -2,7 +2,7 @@ Query delivery process state directly from the terminal. **Use this instead of reading generated markdown or launching explore agents** — targeted queries use 5-10x less context. -**Run `pnpm process:query -- --help` for the full command reference**, including workflow recipes, session types, architecture queries, output modifiers, and available API methods. +**Run `pnpm architect:query -- --help` for the full command reference**, including workflow recipes, session types, architecture queries, output modifiers, and available API methods. See the **Context Gathering Protocol** section above for mandatory session start commands and query recipes. diff --git a/_claude-md/api/dual-source.md b/_claude-md/api/dual-source.md index 556d6dfb..74b7dead 100644 --- a/_claude-md/api/dual-source.md +++ b/_claude-md/api/dual-source.md @@ -7,20 +7,20 @@ Patterns can be defined in TypeScript, Feature files, or both. Each source owns | Use Case | Source | Why | | ------------------------- | ------------ | ----------------------------------------- | | Retroactive documentation | TypeScript | Code existed before delivery process | -| Rich relationships | TypeScript | `@libar-docs-uses`, `@libar-docs-used-by` | +| Rich relationships | TypeScript | `@architect-uses`, `@architect-used-by` | | Phase/release tracking | Feature file | Milestone planning | | Acceptance criteria | Feature file | BDD scenarios | | New patterns | Both | Feature for roadmap, TypeScript for graph | #### Category Flags (libar-generic preset) -| Flag | Domain | -| ------------------- | -------------- | -| `@libar-docs-core` | Core patterns | -| `@libar-docs-api` | Public APIs | -| `@libar-docs-infra` | Infrastructure | +| Flag | Domain | +| ------------------ | -------------- | +| `@architect-core` | Core patterns | +| `@architect-api` | Public APIs | +| `@architect-infra` | Infrastructure | -**Note:** The `@libar-docs` opt-in marker is NOT a category—add explicit category tags for proper categorization. +**Note:** The `@architect` opt-in marker is NOT a category—add explicit category tags for proper categorization. #### Dual-Source Merging @@ -34,6 +34,6 @@ When pattern exists in both TypeScript AND feature file: | Phase/release | Feature file takes precedence | | Description | TypeScript markdown description | -**Warning:** If TypeScript file is missing `@libar-docs-status`, the pattern data is **ignored** and not merged with feature file. +**Warning:** If TypeScript file is missing `@architect-status`, the pattern data is **ignored** and not merged with feature file. **Implementation:** `mergePatterns()` in `src/generators/pipeline/merge-patterns.ts`. Conflict strategy is per-consumer: `fatal` (orchestrator/process-api) or `concatenate` (validator). diff --git a/_claude-md/api/mcp-server.md b/_claude-md/api/mcp-server.md index fa7d26d8..906d293e 100644 --- a/_claude-md/api/mcp-server.md +++ b/_claude-md/api/mcp-server.md @@ -1,17 +1,17 @@ ### MCP Server — Native AI Context Tools -When the MCP server is running, **use `dp_*` tools instead of CLI commands** (`pnpm process:query --`). The MCP server keeps the MasterDataset in memory — tool calls dispatch in sub-milliseconds vs 2-5 seconds for CLI subprocess invocations. All 25 tools wrap the same ProcessStateAPI methods available via CLI. +When the MCP server is running, **use `architect_*` tools instead of CLI commands** (`pnpm architect:query --`). The MCP server keeps the MasterDataset in memory — tool calls dispatch in sub-milliseconds vs 2-5 seconds for CLI subprocess invocations. All 25 tools wrap the same ProcessStateAPI methods available via CLI. #### Session Start (MCP Protocol) Use these tools at the start of every PR or implementation session, in order: -| Step | MCP Tool | What You Get | CLI Equivalent | -| ---- | ------------------- | ------------------------------------------- | ------------------------------------------------- | -| 1 | `dp_overview` | Project health, active phases, blockers | `pnpm process:query -- overview` | -| 2 | `dp_scope_validate` | Pre-flight: FSM violations, missing deps | `pnpm process:query -- scope-validate

` | -| 3 | `dp_context` | Curated context bundle for the session | `pnpm process:query -- context

--session ` | -| 4 | `dp_files` | File reading list with implementation paths | `pnpm process:query -- files

--related` | +| Step | MCP Tool | What You Get | CLI Equivalent | +| ---- | -------------------------- | ------------------------------------------- | --------------------------------------------------- | +| 1 | `architect_overview` | Project health, active phases, blockers | `pnpm architect:query -- overview` | +| 2 | `architect_scope_validate` | Pre-flight: FSM violations, missing deps | `pnpm architect:query -- scope-validate

` | +| 3 | `architect_context` | Curated context bundle for the session | `pnpm architect:query -- context

--session ` | +| 4 | `architect_files` | File reading list with implementation paths | `pnpm architect:query -- files

--related` | Steps 1-2 can run in parallel (no dependencies between them). @@ -19,61 +19,61 @@ Steps 1-2 can run in parallel (no dependencies between them). **Session-Aware Tools** — text output, use for workflow: -| Tool | Input | Description | -| ------------------- | ------------------- | ---------------------------------------------- | -| `dp_overview` | _(none)_ | Progress %, active phases, blocking chains | -| `dp_context` | `name`, `session?` | Curated context (planning/design/implement) | -| `dp_files` | `name` | Ordered file list with roles | -| `dp_dep_tree` | `name`, `maxDepth?` | Dependency chain with status per dep | -| `dp_scope_validate` | `name`, `session` | PASS/BLOCKED/WARN pre-flight verdict | -| `dp_handoff` | `name`, `session?` | Session-end state for multi-session continuity | +| Tool | Input | Description | +| -------------------------- | ------------------- | ---------------------------------------------- | +| `architect_overview` | _(none)_ | Progress %, active phases, blocking chains | +| `architect_context` | `name`, `session?` | Curated context (planning/design/implement) | +| `architect_files` | `name` | Ordered file list with roles | +| `architect_dep_tree` | `name`, `maxDepth?` | Dependency chain with status per dep | +| `architect_scope_validate` | `name`, `session` | PASS/BLOCKED/WARN pre-flight verdict | +| `architect_handoff` | `name`, `session?` | Session-end state for multi-session continuity | **Data Query Tools** — JSON output, use for structured lookups: -| Tool | Input | Description | -| -------------- | -------------------------------------------------------- | -------------------------------------------------- | -| `dp_status` | _(none)_ | Pattern counts by status, completion % | -| `dp_pattern` | `name` | Full metadata: deliverables, relationships, shapes | -| `dp_list` | `status?`, `phase?`, `category?`, `namesOnly?`, `count?` | Filtered pattern listing | -| `dp_search` | `query` | Fuzzy name search with similarity scores | -| `dp_rules` | `pattern?`, `onlyInvariants?` | Business rules from Gherkin Rule: blocks | -| `dp_tags` | _(none)_ | Tag usage counts across all sources | -| `dp_sources` | _(none)_ | File inventory by type (TS, Gherkin, stubs) | -| `dp_stubs` | `unresolved?` | Design stubs with resolution status | -| `dp_decisions` | `name?` | AD-N/DD-N design decisions from stubs | +| Tool | Input | Description | +| --------------------- | -------------------------------------------------------- | -------------------------------------------------- | +| `architect_status` | _(none)_ | Pattern counts by status, completion % | +| `architect_pattern` | `name` | Full metadata: deliverables, relationships, shapes | +| `architect_list` | `status?`, `phase?`, `category?`, `namesOnly?`, `count?` | Filtered pattern listing | +| `architect_search` | `query` | Fuzzy name search with similarity scores | +| `architect_rules` | `pattern?`, `onlyInvariants?` | Business rules from Gherkin Rule: blocks | +| `architect_tags` | _(none)_ | Tag usage counts across all sources | +| `architect_sources` | _(none)_ | File inventory by type (TS, Gherkin, stubs) | +| `architect_stubs` | `unresolved?` | Design stubs with resolution status | +| `architect_decisions` | `name?` | AD-N/DD-N design decisions from stubs | **Architecture Tools** — JSON output, use for dependency and structure analysis: -| Tool | Input | Description | -| ---------------------- | -------- | ------------------------------------------- | -| `dp_arch_context` | `name?` | Bounded contexts with member patterns | -| `dp_arch_layer` | `name?` | Architecture layers with member patterns | -| `dp_arch_neighborhood` | `name` | Uses, used-by, same-context peers | -| `dp_arch_blocking` | _(none)_ | Patterns blocked by incomplete dependencies | -| `dp_arch_dangling` | _(none)_ | Broken references to nonexistent patterns | -| `dp_arch_coverage` | `path?` | Annotation coverage % and unused taxonomy | -| `dp_unannotated` | `path?` | Files missing @libar-docs annotations | +| Tool | Input | Description | +| ----------------------------- | -------- | ------------------------------------------- | +| `architect_arch_context` | `name?` | Bounded contexts with member patterns | +| `architect_arch_layer` | `name?` | Architecture layers with member patterns | +| `architect_arch_neighborhood` | `name` | Uses, used-by, same-context peers | +| `architect_arch_blocking` | _(none)_ | Patterns blocked by incomplete dependencies | +| `architect_arch_dangling` | _(none)_ | Broken references to nonexistent patterns | +| `architect_arch_coverage` | `path?` | Annotation coverage % and unused taxonomy | +| `architect_unannotated` | `path?` | Files missing @architect annotations | **Server Management:** -| Tool | Description | -| ------------ | ------------------------------------------------------ | -| `dp_rebuild` | Force dataset rebuild from current source files | -| `dp_config` | Show source globs, base dir, build time, pattern count | -| `dp_help` | List all available tools with descriptions | +| Tool | Description | +| ------------------- | ------------------------------------------------------ | +| `architect_rebuild` | Force dataset rebuild from current source files | +| `architect_config` | Show source globs, base dir, build time, pattern count | +| `architect_help` | List all available tools with descriptions | #### Common Recipes -| Goal | Tools | -| ---------------------------------- | ------------------------------------------------------------------ | -| What patterns are blocking? | `dp_arch_blocking` | -| Understand a pattern before coding | `dp_context` (name, session) + `dp_scope_validate` (name, session) | -| Find business rules for a feature | `dp_rules` with `pattern` filter | -| Check annotation gaps | `dp_arch_coverage` or `dp_unannotated` | -| Explore a bounded context | `dp_arch_context` with name | -| Find what depends on a pattern | `dp_arch_neighborhood` with name | -| List all roadmap patterns | `dp_list` with `status: "roadmap"` | -| Search by partial name | `dp_search` with query | +| Goal | Tools | +| ---------------------------------- | -------------------------------------------------------------------------------- | +| What patterns are blocking? | `architect_arch_blocking` | +| Understand a pattern before coding | `architect_context` (name, session) + `architect_scope_validate` (name, session) | +| Find business rules for a feature | `architect_rules` with `pattern` filter | +| Check annotation gaps | `architect_arch_coverage` or `architect_unannotated` | +| Explore a bounded context | `architect_arch_context` with name | +| Find what depends on a pattern | `architect_arch_neighborhood` with name | +| List all roadmap patterns | `architect_list` with `status: "roadmap"` | +| Search by partial name | `architect_search` with query | #### Configuration @@ -82,9 +82,9 @@ The MCP server is configured via `.mcp.json` in the project root: ```json { "mcpServers": { - "delivery-process": { + "architect": { "command": "npx", - "args": ["dp-mcp-server", "--watch"] + "args": ["architect-mcp", "--watch"] } } } @@ -95,10 +95,10 @@ For monorepo setups with explicit source globs: ```json { "mcpServers": { - "delivery-process": { + "architect": { "command": "npx", "args": [ - "dp-mcp-server", + "architect-mcp", "--watch", "--input", "packages/core/src/**/*.ts", @@ -112,12 +112,12 @@ For monorepo setups with explicit source globs: } ``` -The `--watch` flag enables auto-rebuild when `.ts` or `.feature` files change (500ms debounce). Without it, use `dp_rebuild` after annotation changes. +The `--watch` flag enables auto-rebuild when `.ts` or `.feature` files change (500ms debounce). Without it, use `architect_rebuild` after annotation changes. #### Tips -- `dp_rules` without a `pattern` filter returns a compact summary (totals + rule names + per-area counts) — unfiltered output is capped to prevent context overflow. -- `dp_pattern` returns full metadata (~66KB for completed patterns) — prefer `dp_context` with a session type for interactive sessions. -- `dp_search` uses fuzzy matching — partial names work (e.g., "MCP" matches all MCP-related patterns). -- `dp_list` filters compose: `status` + `phase` + `category` narrow results cumulatively. +- `architect_rules` without a `pattern` filter returns a compact summary (totals + rule names + per-area counts) — unfiltered output is capped to prevent context overflow. +- `architect_pattern` returns full metadata (~66KB for completed patterns) — prefer `architect_context` with a session type for interactive sessions. +- `architect_search` uses fuzzy matching — partial names work (e.g., "MCP" matches all MCP-related patterns). +- `architect_list` filters compose: `status` + `phase` + `category` narrow results cumulatively. - Session-aware tools return formatted text (like CLI output). Data and architecture tools return JSON. diff --git a/_claude-md/authoring/feature-content.md b/_claude-md/authoring/feature-content.md index 5e0e0aa3..63f03be3 100644 --- a/_claude-md/authoring/feature-content.md +++ b/_claude-md/authoring/feature-content.md @@ -18,7 +18,7 @@ Rule: Reservations use atomic claim See `src/reservations/reserve.ts` for API. ``` -Code stubs live in `delivery-process/stubs/{pattern-name}/` — annotated TypeScript with `throw new Error("not yet implemented")`. +Code stubs live in `architect/stubs/{pattern-name}/` — annotated TypeScript with `throw new Error("not yet implemented")`. #### Forbidden in Feature Descriptions @@ -33,7 +33,7 @@ Code stubs live in `delivery-process/stubs/{pattern-name}/` — annotated TypeSc **Tag values cannot contain spaces.** Use hyphens instead: -| Invalid | Valid | -| -------------------------------- | ------------------------------- | -| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | -| `@libar-docs-pattern:My Pattern` | `@libar-docs-pattern:MyPattern` | +| Invalid | Valid | +| ------------------------------- | ------------------------------ | +| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | +| `@architect-pattern:My Pattern` | `@architect-pattern:MyPattern` | diff --git a/_claude-md/authoring/gherkin-patterns.md b/_claude-md/authoring/gherkin-patterns.md index 8e5bdbb8..2b423728 100644 --- a/_claude-md/authoring/gherkin-patterns.md +++ b/_claude-md/authoring/gherkin-patterns.md @@ -3,10 +3,10 @@ #### Roadmap Spec Structure ```gherkin -@libar-docs -@libar-docs-pattern:ProcessGuardLinter -@libar-docs-status:roadmap -@libar-docs-phase:99 +@architect +@architect-pattern:ProcessGuardLinter +@architect-status:roadmap +@architect-phase:99 Feature: Process Guard Linter **Problem:** @@ -29,7 +29,7 @@ Feature: Process Guard Linter | Value-First | `**Business Value:**`, `**How It Works:**` | TDD-style specs | | Context/Approach | `**Context:**`, `**Approach:**` | Technical patterns | -Tag inventory: `pnpm process:query -- tags` (counts per tag and value across all sources). +Tag inventory: `pnpm architect:query -- tags` (counts per tag and value across all sources). #### Rule Block Structure (Mandatory) diff --git a/_claude-md/core/architecture.md b/_claude-md/core/architecture.md index 1d0dfcee..36d3bbd0 100644 --- a/_claude-md/core/architecture.md +++ b/_claude-md/core/architecture.md @@ -5,7 +5,7 @@ CONFIG → SCANNER → EXTRACTOR → TRANSFORMER → CODEC (files) (patterns) (MasterDataset) (Markdown) ``` -1. **Scanner** (`src/scanner/`): File discovery, AST parsing, opt-in detection via `@libar-docs` marker +1. **Scanner** (`src/scanner/`): File discovery, AST parsing, opt-in detection via `@architect` marker 2. **Extractor** (`src/extractor/`): Pattern extraction from TypeScript JSDoc and Gherkin tags 3. **Transformer** (`src/generators/pipeline/`): Builds MasterDataset with pre-computed views 4. **Codec** (`src/renderable/`): Zod 4 codecs transform MasterDataset → RenderableDocument → Markdown @@ -19,11 +19,11 @@ CONFIG → SCANNER → EXTRACTOR → TRANSFORMER → CODEC - **Pipeline Factory**: Shared `buildMasterDataset()` in `src/generators/pipeline/build-pipeline.ts` — all consumers (orchestrator, process-api, validate-patterns) call this instead of wiring inline pipelines. Per-consumer behavior via `PipelineOptions`. - **Single Read Model** (ADR-006): MasterDataset is the sole read model. No consumer re-derives data from raw scanner/extractor output. Anti-patterns: Parallel Pipeline, Lossy Local Type, Re-derived Relationship. -**Live module inventory:** `pnpm process:query -- arch context` and `pnpm process:query -- arch layer` +**Live module inventory:** `pnpm architect:query -- arch context` and `pnpm architect:query -- arch layer` ### Decision Specs -Architecture and process decisions are recorded as annotated Gherkin specs in `delivery-process/decisions/`: +Architecture and process decisions are recorded as annotated Gherkin specs in `architect/decisions/`: | Spec | Key Decision | | ------- | -------------------------------------------------------------------------- | @@ -34,4 +34,4 @@ Architecture and process decisions are recorded as annotated Gherkin specs in `d | ADR-006 | Single read model — MasterDataset is the sole read model for all consumers | | PDR-001 | Session workflow commands — Process Data API CLI design decisions | -Query decisions: `pnpm process:query -- decisions ` +Query decisions: `pnpm architect:query -- decisions ` diff --git a/_claude-md/core/common-commands.md b/_claude-md/core/common-commands.md index f5ac8092..ccf70908 100644 --- a/_claude-md/core/common-commands.md +++ b/_claude-md/core/common-commands.md @@ -19,7 +19,7 @@ pnpm validate:all # All validations including anti-patterns and DoD pnpm docs:all # Generate all doc types # Data API (see Context Gathering Protocol above) -pnpm process:query -- --help # All subcommands and options -pnpm process:query -- context --session design # Session context bundle -pnpm process:query -- overview # Project health summary +pnpm architect:query -- --help # All subcommands and options +pnpm architect:query -- context --session design # Session context bundle +pnpm architect:query -- overview # Project health summary ``` diff --git a/_claude-md/core/context-protocol.md b/_claude-md/core/context-protocol.md index bf06292a..c3e07ea5 100644 --- a/_claude-md/core/context-protocol.md +++ b/_claude-md/core/context-protocol.md @@ -6,12 +6,12 @@ The API returns structured, current data using 5-10x less context than file read #### PR / Session Start (run these FIRST) -| Step | Command | What You Get | -| ---- | ---------------------------------------------------------- | ------------------------------------------- | -| 1 | `pnpm process:query -- overview` | Project health, active phases, blockers | -| 2 | `pnpm process:query -- scope-validate ` | Pre-flight: FSM violations, missing deps | -| 3 | `pnpm process:query -- context --session ` | Curated context bundle for the session | -| 4 | `pnpm process:query -- files --related` | File reading list with implementation paths | +| Step | Command | What You Get | +| ---- | ------------------------------------------------------------ | ------------------------------------------- | +| 1 | `pnpm architect:query -- overview` | Project health, active phases, blockers | +| 2 | `pnpm architect:query -- scope-validate ` | Pre-flight: FSM violations, missing deps | +| 3 | `pnpm architect:query -- context --session ` | Curated context bundle for the session | +| 4 | `pnpm architect:query -- files --related` | File reading list with implementation paths | Session types: `planning` (minimal), `design` (full: stubs + deps + deliverables), `implement` (focused: deliverables + FSM + tests). @@ -22,11 +22,11 @@ Session types: `planning` (minimal), `design` (full: stubs + deps + deliverables | Find code structure | `arch context [name]` / `arch layer [name]` | Structured by annotations, not file paths | | Find dependencies | `dep-tree ` | Shows status of each dependency | | Find business rules | `rules --pattern ` | Extracted from Gherkin Rule: blocks | -| Find unannotated files | `unannotated --path

` | Catches missing @libar-docs markers | +| Find unannotated files | `unannotated --path ` | Catches missing @architect markers | | Check FSM state | `query getProtectionInfo ` | Protection level + allowed actions | | Check valid transitions | `query getValidTransitionsFrom ` | Valid next states from current status | | Tag inventory | `tags` | Counts per tag and value across all sources | -| Annotation coverage | `arch coverage` | Files with/without @libar-docs annotations | +| Annotation coverage | `arch coverage` | Files with/without @architect annotations | #### Why Annotations Beat Grep @@ -35,6 +35,6 @@ Session types: `planning` (minimal), `design` (full: stubs + deps + deliverables - **Feed generation**: Annotations produce generated docs; grep results are ephemeral - **Discoverable**: `unannotated --path` finds gaps; grep doesn't know what's missing -**When adding new code:** Add `@libar-docs` annotations and relationship tags (`@libar-docs-depends-on`, `@libar-docs-uses`) so future sessions can discover the code via API queries instead of grep. +**When adding new code:** Add `@architect` annotations and relationship tags (`@architect-depends-on`, `@architect-uses`) so future sessions can discover the code via API queries instead of grep. -Full CLI reference: `pnpm process:query -- --help` +Full CLI reference: `pnpm architect:query -- --help` diff --git a/_claude-md/generated/doc-generation-proof-of-concept.md b/_claude-md/generated/doc-generation-proof-of-concept.md index b9245ee0..87928441 100644 --- a/_claude-md/generated/doc-generation-proof-of-concept.md +++ b/_claude-md/generated/doc-generation-proof-of-concept.md @@ -35,7 +35,7 @@ **What We Have:** - The delivery-process package already has the required ingredients: + The Architect package already has the required ingredients: - Pattern extraction from TypeScript JSDoc and Gherkin tags - Rich content support (DocStrings, tables, code blocks in features) - Multi-source aggregation via tag taxonomy @@ -118,77 +118,77 @@ ### Protection Levels -| spec | intent | -| --- | --- | +| spec | intent | +| --------------------------- | ------ | | mvp-workflow-implementation | modify | -| short-form-tag-migration | review | +| short-form-tag-migration | review | -| spec | -| --- | +| spec | +| --------------------------- | | mvp-workflow-implementation | -| Deliverable | Status | -| --- | --- | -| Task A | Done | -| Task B | Pending | +| Deliverable | Status | +| ----------- | ------- | +| Task A | Done | +| Task B | Pending | -| Deliverable | Status | -| --- | --- | -| Task A | Pending | +| Deliverable | Status | +| ----------- | ------- | +| Task A | Pending | -| Section | Content | -| --- | --- | -| Active Session | Session ID and status, or "none" | -| Scoped Specs | List of specs in scope | +| Section | Content | +| --------------- | ---------------------------------- | +| Active Session | Session ID and status, or "none" | +| Scoped Specs | List of specs in scope | | Protected Specs | Specs with active/completed status | -| Tag | Format | Purpose | -| --- | --- | --- | -| session-id | value | Unique session identifier | -| session-status | enum | Session lifecycle: draft, active, closed | -| session-scope | flag | Marks file as session definition | +| Tag | Format | Purpose | +| -------------- | ------ | ---------------------------------------- | +| session-id | value | Unique session identifier | +| session-status | enum | Session lifecycle: draft, active, closed | +| session-scope | flag | Marks file as session definition | -| Tag | Format | Purpose | -| --- | --- | --- | +| Tag | Format | Purpose | +| ------------- | ------------ | ---------------------------------- | | unlock-reason | quoted-value | Required to modify protected files | -| locked-by | value | Session ID that locked the file | +| locked-by | value | Session ID that locked the file | ### Valid Transitions -| spec | intent | -| --- | --- | +| spec | intent | +| --------------------------- | ------ | | mvp-workflow-implementation | modify | -| short-form-tag-migration | review | +| short-form-tag-migration | review | -| spec | -| --- | +| spec | +| --------------------------- | | mvp-workflow-implementation | -| Deliverable | Status | -| --- | --- | -| Task A | Done | -| Task B | Pending | +| Deliverable | Status | +| ----------- | ------- | +| Task A | Done | +| Task B | Pending | -| Deliverable | Status | -| --- | --- | -| Task A | Pending | +| Deliverable | Status | +| ----------- | ------- | +| Task A | Pending | -| Section | Content | -| --- | --- | -| Active Session | Session ID and status, or "none" | -| Scoped Specs | List of specs in scope | +| Section | Content | +| --------------- | ---------------------------------- | +| Active Session | Session ID and status, or "none" | +| Scoped Specs | List of specs in scope | | Protected Specs | Specs with active/completed status | -| Tag | Format | Purpose | -| --- | --- | --- | -| session-id | value | Unique session identifier | -| session-status | enum | Session lifecycle: draft, active, closed | -| session-scope | flag | Marks file as session definition | +| Tag | Format | Purpose | +| -------------- | ------ | ---------------------------------------- | +| session-id | value | Unique session identifier | +| session-status | enum | Session lifecycle: draft, active, closed | +| session-scope | flag | Marks file as session definition | -| Tag | Format | Purpose | -| --- | --- | --- | +| Tag | Format | Purpose | +| ------------- | ------------ | ---------------------------------- | | unlock-reason | quoted-value | Required to modify protected files | -| locked-by | value | Session ID that locked the file | +| locked-by | value | Session ID that locked the file | ### API Types @@ -204,14 +204,14 @@ ### Error Messages -| Error Code | -|---| -| completed-protection | +| Error Code | +| ------------------------- | +| completed-protection | | invalid-status-transition | -| scope-creep | -| deliverable-removed | -| session-scope | -| session-excluded | +| scope-creep | +| deliverable-removed | +| session-scope | +| session-excluded | ### Pre-commit Setup @@ -221,44 +221,44 @@ generate-docs --decisions 'specs/**/*.feature' --features 'tests/**/*.feature' - ```json { - "scripts": { - "lint:process": "lint-process --staged", - "lint:process:ci": "lint-process --all --strict" - } - } + "scripts": { + "lint:process": "architect-guard --staged", + "lint:process:ci": "architect-guard --all --strict" + } +} ``` ```typescript import { - deriveProcessState, - detectStagedChanges, - validateChanges, - hasErrors, - summarizeResult, - } from '@libar-dev/delivery-process/lint'; - - // 1. Derive state from annotations - const state = (await deriveProcessState({ baseDir: '.' })).value; - - // 2. Detect changes - const changes = detectStagedChanges('.').value; - - // 3. Validate - const { result } = validateChanges({ - state, - changes, - options: { strict: false, ignoreSession: false }, - }); - - // 4. Handle results - if (hasErrors(result)) { - console.log(summarizeResult(result)); - process.exit(1); - } + deriveProcessState, + detectStagedChanges, + validateChanges, + hasErrors, + summarizeResult, +} from '@libar-dev/architect/lint'; + +// 1. Derive state from annotations +const state = (await deriveProcessState({ baseDir: '.' })).value; + +// 2. Detect changes +const changes = detectStagedChanges('.').value; + +// 3. Validate +const { result } = validateChanges({ + state, + changes, + options: { strict: false, ignoreSession: false }, +}); + +// 4. Handle results +if (hasErrors(result)) { + console.log(summarizeResult(result)); + process.exit(1); +} ``` ```bash -npx lint-process --staged +npx architect-guard --staged ``` ```javascript @@ -277,28 +277,28 @@ npx lint-process --staged ```typescript // specs/stubs/shape-extractor.ts - /** - * @libar-docs - * @libar-docs-pattern ShapeExtractorStub - * @libar-docs-status roadmap - * - * ## Shape Extractor - Design Stub - * - * API design for extracting TypeScript types from source files. - */ - - export interface ExtractedShape { - name: string; - kind: 'interface' | 'type' | 'enum' | 'function'; - sourceText: string; - } - - export function extractShapes( - sourceCode: string, - shapeNames: string[] - ): Map { - throw new Error('ShapeExtractor not yet implemented - roadmap pattern'); - } +/** + * @architect + * @architect-pattern ShapeExtractorStub + * @architect-status roadmap + * + * ## Shape Extractor - Design Stub + * + * API design for extracting TypeScript types from source files. + */ + +export interface ExtractedShape { + name: string; + kind: 'interface' | 'type' | 'enum' | 'function'; + sourceText: string; +} + +export function extractShapes( + sourceCode: string, + shapeNames: string[] +): Map { + throw new Error('ShapeExtractor not yet implemented - roadmap pattern'); +} ``` ### Programmatic API @@ -309,44 +309,44 @@ generate-docs --decisions 'specs/**/*.feature' --features 'tests/**/*.feature' - ```json { - "scripts": { - "lint:process": "lint-process --staged", - "lint:process:ci": "lint-process --all --strict" - } - } + "scripts": { + "lint:process": "architect-guard --staged", + "lint:process:ci": "architect-guard --all --strict" + } +} ``` ```typescript import { - deriveProcessState, - detectStagedChanges, - validateChanges, - hasErrors, - summarizeResult, - } from '@libar-dev/delivery-process/lint'; - - // 1. Derive state from annotations - const state = (await deriveProcessState({ baseDir: '.' })).value; - - // 2. Detect changes - const changes = detectStagedChanges('.').value; - - // 3. Validate - const { result } = validateChanges({ - state, - changes, - options: { strict: false, ignoreSession: false }, - }); - - // 4. Handle results - if (hasErrors(result)) { - console.log(summarizeResult(result)); - process.exit(1); - } + deriveProcessState, + detectStagedChanges, + validateChanges, + hasErrors, + summarizeResult, +} from '@libar-dev/architect/lint'; + +// 1. Derive state from annotations +const state = (await deriveProcessState({ baseDir: '.' })).value; + +// 2. Detect changes +const changes = detectStagedChanges('.').value; + +// 3. Validate +const { result } = validateChanges({ + state, + changes, + options: { strict: false, ignoreSession: false }, +}); + +// 4. Handle results +if (hasErrors(result)) { + console.log(summarizeResult(result)); + process.exit(1); +} ``` ```bash -npx lint-process --staged +npx architect-guard --staged ``` ```javascript @@ -365,26 +365,26 @@ npx lint-process --staged ```typescript // specs/stubs/shape-extractor.ts - /** - * @libar-docs - * @libar-docs-pattern ShapeExtractorStub - * @libar-docs-status roadmap - * - * ## Shape Extractor - Design Stub - * - * API design for extracting TypeScript types from source files. - */ - - export interface ExtractedShape { - name: string; - kind: 'interface' | 'type' | 'enum' | 'function'; - sourceText: string; - } - - export function extractShapes( - sourceCode: string, - shapeNames: string[] - ): Map { - throw new Error('ShapeExtractor not yet implemented - roadmap pattern'); - } +/** + * @architect + * @architect-pattern ShapeExtractorStub + * @architect-status roadmap + * + * ## Shape Extractor - Design Stub + * + * API design for extracting TypeScript types from source files. + */ + +export interface ExtractedShape { + name: string; + kind: 'interface' | 'type' | 'enum' | 'function'; + sourceText: string; +} + +export function extractShapes( + sourceCode: string, + shapeNames: string[] +): Map { + throw new Error('ShapeExtractor not yet implemented - roadmap pattern'); +} ``` diff --git a/_claude-md/guides/product-area-enrichment.md b/_claude-md/guides/product-area-enrichment.md index 7c877d91..8e7f4f62 100644 --- a/_claude-md/guides/product-area-enrichment.md +++ b/_claude-md/guides/product-area-enrichment.md @@ -9,27 +9,27 @@ Workflow for adding live Mermaid diagrams, enriched intros, and API Types sectio ```bash # 1. Find unannotated TS files in the product area's source directory -pnpm process:query -- unannotated --path src/ +pnpm architect:query -- unannotated --path src/ # 2. Check if product area has arch-context mappings -# Empty [] means use @libar-docs-include tags instead +# Empty [] means use @architect-include tags instead grep -A5 ':' src/renderable/codecs/reference.ts | head -10 # 3. List patterns in the product area -pnpm process:query -- list --product-area --names-only +pnpm architect:query -- list --product-area --names-only ``` #### Step-by-Step Workflow -| Step | Action | Why | -| ---- | ------------------------------------------------------------------------ | -------------------------------------------- | -| 1 | Add `@libar-docs` to unannotated TS files | Scanner ignores files without opt-in marker | -| 2 | Add `@libar-docs-include:` to all feature files | Enables diagram scoping via `include` filter | -| 3 | Add `@libar-docs-depends-on` to feature files | Creates relationship edges in diagrams | -| 4 | Add `@libar-docs-shape` + `@libar-docs-include` to key type declarations | Populates API Types section | -| 5 | Add `@libar-docs-product-area:` to TS file annotations | Routes TS patterns to product area | -| 6 | Update `PRODUCT_AREA_META` in `reference.ts` (~line 237) | Enriched intro, invariants, `diagramScopes` | -| 7 | `pnpm build && pnpm test && pnpm docs:product-areas` | Verify end-to-end | +| Step | Action | Why | +| ---- | ---------------------------------------------------------------------- | -------------------------------------------- | +| 1 | Add `@architect` to unannotated TS files | Scanner ignores files without opt-in marker | +| 2 | Add `@architect-include:` to all feature files | Enables diagram scoping via `include` filter | +| 3 | Add `@architect-depends-on` to feature files | Creates relationship edges in diagrams | +| 4 | Add `@architect-shape` + `@architect-include` to key type declarations | Populates API Types section | +| 5 | Add `@architect-product-area:` to TS file annotations | Routes TS patterns to product area | +| 6 | Update `PRODUCT_AREA_META` in `reference.ts` (~line 237) | Enriched intro, invariants, `diagramScopes` | +| 7 | `pnpm build && pnpm test && pnpm docs:product-areas` | Verify end-to-end | #### PRODUCT_AREA_META Entry Structure @@ -53,32 +53,32 @@ AreaName: { Filters are OR'd — a pattern matching ANY filter appears in the diagram: -| Filter | Source Tag | Best For | -| ---------------------- | ------------------------------- | ------------------------------------------------ | -| `include: ['scope']` | `@libar-docs-include:scope` | Areas with empty `PRODUCT_AREA_ARCH_CONTEXT_MAP` | -| `archContext: ['ctx']` | `@libar-docs-arch-context:ctx` | Areas with existing arch-context mappings | -| `patterns: ['Name']` | Direct pattern name list | Small, curated diagrams | -| `archLayer: 'domain'` | `@libar-docs-arch-layer:domain` | Layer-filtered views | +| Filter | Source Tag | Best For | +| ---------------------- | ------------------------------ | ------------------------------------------------ | +| `include: ['scope']` | `@architect-include:scope` | Areas with empty `PRODUCT_AREA_ARCH_CONTEXT_MAP` | +| `archContext: ['ctx']` | `@architect-arch-context:ctx` | Areas with existing arch-context mappings | +| `patterns: ['Name']` | Direct pattern name list | Small, curated diagrams | +| `archLayer: 'domain'` | `@architect-arch-layer:domain` | Layer-filtered views | #### Common Pitfalls -| Pitfall | Symptom | Fix | -| ------------------------------------------ | -------------------------------------------------- | ----------------------------------------------------- | -| TS file missing `@libar-docs` marker | Shapes not extracted, pattern absent from registry | Add file-level `@libar-docs` annotation block | -| Empty `PRODUCT_AREA_ARCH_CONTEXT_MAP` | No diagrams render | Use `include` filter in `diagramScopes` | -| No relationship tags on patterns | Diagrams show isolated nodes (no edges) | Add `@libar-docs-depends-on` to feature files | -| TS pattern name collides with Gherkin | Duplicate pattern error | Use different name + `@libar-docs-implements` to link | -| Declaration merging (`type X` + `const X`) | Shape for type alias not extracted | Fixed — `findDeclarations` returns arrays per name | -| Generic arrows in `.ts` with `jsx: true` | Parse error on `(val: T) =>` | Fixed — `jsx` flag now based on file extension | +| Pitfall | Symptom | Fix | +| ------------------------------------------ | -------------------------------------------------- | ---------------------------------------------------- | +| TS file missing `@architect` marker | Shapes not extracted, pattern absent from registry | Add file-level `@architect` annotation block | +| Empty `PRODUCT_AREA_ARCH_CONTEXT_MAP` | No diagrams render | Use `include` filter in `diagramScopes` | +| No relationship tags on patterns | Diagrams show isolated nodes (no edges) | Add `@architect-depends-on` to feature files | +| TS pattern name collides with Gherkin | Duplicate pattern error | Use different name + `@architect-implements` to link | +| Declaration merging (`type X` + `const X`) | Shape for type alias not extracted | Fixed — `findDeclarations` returns arrays per name | +| Generic arrows in `.ts` with `jsx: true` | Parse error on `(val: T) =>` | Fixed — `jsx` flag now based on file extension | #### Shape Extraction Prerequisites For a shape to appear in the API Types section: -1. **File must have `@libar-docs`** opt-in marker (file-level JSDoc) -2. **File must have `@libar-docs-product-area:`** to route to product area -3. **Declaration must have `@libar-docs-shape`** in its JSDoc (declaration-level) -4. **Declaration must have `@libar-docs-include:`** matching the `diagramScopes` filter +1. **File must have `@architect`** opt-in marker (file-level JSDoc) +2. **File must have `@architect-product-area:`** to route to product area +3. **Declaration must have `@architect-shape`** in its JSDoc (declaration-level) +4. **Declaration must have `@architect-include:`** matching the `diagramScopes` filter 5. **File must be `.ts`** (shape extraction uses typescript-estree parser) Shape extraction works on both exported and non-exported declarations. diff --git a/_claude-md/validation/anti-patterns.md b/_claude-md/validation/anti-patterns.md index b5ebacf6..f469a9b5 100644 --- a/_claude-md/validation/anti-patterns.md +++ b/_claude-md/validation/anti-patterns.md @@ -4,12 +4,12 @@ Enforces dual-source architecture ownership between TypeScript and Gherkin files #### Tag Location Constraints -| Tag | Correct Location | Wrong Location | Why | -| ------------------------ | ---------------- | -------------- | ---------------------------------- | -| `@libar-docs-uses` | TypeScript | Feature files | TS owns runtime dependencies | -| `@libar-docs-depends-on` | Feature files | TypeScript | Gherkin owns planning dependencies | -| `@libar-docs-quarter` | Feature files | TypeScript | Gherkin owns timeline metadata | -| `@libar-docs-team` | Feature files | TypeScript | Gherkin owns ownership metadata | +| Tag | Correct Location | Wrong Location | Why | +| ----------------------- | ---------------- | -------------- | ---------------------------------- | +| `@architect-uses` | TypeScript | Feature files | TS owns runtime dependencies | +| `@architect-depends-on` | Feature files | TypeScript | Gherkin owns planning dependencies | +| `@architect-quarter` | Feature files | TypeScript | Gherkin owns timeline metadata | +| `@architect-team` | Feature files | TypeScript | Gherkin owns ownership metadata | #### DoD Validation diff --git a/_claude-md/validation/process-guard.md b/_claude-md/validation/process-guard.md index 70d3c365..24f599ea 100644 --- a/_claude-md/validation/process-guard.md +++ b/_claude-md/validation/process-guard.md @@ -2,23 +2,23 @@ Process Guard validates delivery workflow changes at commit time using a Decider pattern. -Query validation rules: `pnpm process:query -- rules --pattern ProcessGuard` -Query protection levels: `pnpm process:query -- query getProtectionInfo ` +Query validation rules: `pnpm architect:query -- rules --pattern ProcessGuard` +Query protection levels: `pnpm architect:query -- query getProtectionInfo ` #### CLI Usage ```bash # Pre-commit (default mode) -lint-process --staged +architect-guard --staged # CI pipeline with strict mode -lint-process --all --strict +architect-guard --all --strict # Debug: show derived process state -lint-process --staged --show-state +architect-guard --staged --show-state # Override session scope checking -lint-process --staged --ignore-session +architect-guard --staged --ignore-session ``` #### Exit Codes diff --git a/_claude-md/workflow/session-workflows.md b/_claude-md/workflow/session-workflows.md index f8f8b4c6..f680d155 100644 --- a/_claude-md/workflow/session-workflows.md +++ b/_claude-md/workflow/session-workflows.md @@ -43,7 +43,7 @@ **Invariant:** A design session makes architectural decisions and creates code stubs with interfaces. It must not produce implementation code. Context gathering via the Process Data API must precede any explore agent usage. -**Rationale:** Design sessions resolve ambiguity before implementation begins. Code stubs in delivery-process/stubs/ live outside src/ to avoid TypeScript compilation and ESLint issues, making them zero-risk artifacts. +**Rationale:** Design sessions resolve ambiguity before implementation begins. Code stubs in architect/stubs/ live outside src/ to avoid TypeScript compilation and ESLint issues, making them zero-risk artifacts. | Use Design Session | Skip Design Session | | -------------------------- | ------------------- | @@ -78,11 +78,11 @@ | session-scope (warning) | Modified file outside session scope | Add to scope OR use --ignore-session | | session-excluded | Modified excluded pattern during session | Remove from exclusion OR override | -| Situation | Solution | Example | -| ---------------------------- | --------------------- | -------------------------------------- | -| Fix bug in completed spec | Add unlock reason tag | libar-docs-unlock-reason:Fix-typo | -| Modify outside session scope | Use ignore flag | lint-process --staged --ignore-session | -| CI treats warnings as errors | Use strict flag | lint-process --all --strict | +| Situation | Solution | Example | +| ---------------------------- | --------------------- | ----------------------------------------- | +| Fix bug in completed spec | Add unlock reason tag | libar-docs-unlock-reason:Fix-typo | +| Modify outside session scope | Use ignore flag | architect-guard --staged --ignore-session | +| CI treats warnings as errors | Use strict flag | architect-guard --all --strict | #### Handoff captures session-end state for continuity @@ -92,6 +92,6 @@ #### ClaudeModuleGeneration is the generation mechanism -**Invariant:** Phase 39 depends on ClaudeModuleGeneration (Phase 25). Adding `@libar-docs-claude-module` and `@libar-docs-claude-section:workflow` tags to this spec will cause ClaudeModuleGeneration to produce `_claude-md/workflow/` output files. The hand-written `_claude-md/workflow/` files are deleted after successful verified generation. +**Invariant:** Phase 39 depends on ClaudeModuleGeneration (Phase 25). Adding `@architect-claude-module` and `@architect-claude-section:workflow` tags to this spec will cause ClaudeModuleGeneration to produce `_claude-md/workflow/` output files. The hand-written `_claude-md/workflow/` files are deleted after successful verified generation. -**Rationale:** The annotation work (Rule blocks in this spec) is immediately useful — queryable via `pnpm process:query -- rules`. Generation deliverables cannot complete until Phase 25 ships the ClaudeModuleCodec. This sequencing is intentional: the annotation investment has standalone value regardless of whether the codec exists yet. +**Rationale:** The annotation work (Rule blocks in this spec) is immediately useful — queryable via `pnpm architect:query -- rules`. Generation deliverables cannot complete until Phase 25 ships the ClaudeModuleCodec. This sequencing is intentional: the annotation investment has standalone value regardless of whether the codec exists yet. diff --git a/delivery-process.config.ts b/architect.config.ts similarity index 95% rename from delivery-process.config.ts rename to architect.config.ts index bea50465..82b68f91 100644 --- a/delivery-process.config.ts +++ b/architect.config.ts @@ -2,12 +2,12 @@ * Delivery-process package configuration. * * Unified config replacing repeated CLI globs across 15+ package.json scripts. - * Uses @libar-docs- prefix with simplified 3-category taxonomy. + * Uses @architect- prefix with simplified 3-category taxonomy. * * Categories: - * - @libar-docs-core: Core patterns and utilities - * - @libar-docs-api: Public API exports - * - @libar-docs-infra: Infrastructure and configuration + * - @architect-core: Core patterns and utilities + * - @architect-api: Public API exports + * - @architect-infra: Infrastructure and configuration */ import { defineConfig } from './src/config/define-config.js'; import { createProductAreaConfigs } from './src/generators/built-in/reference-generators.js'; @@ -79,11 +79,11 @@ export default defineConfig({ preset: 'libar-generic', sources: { typescript: ['src/**/*.ts'], - stubs: ['delivery-process/stubs/**/*.ts'], + stubs: ['architect/stubs/**/*.ts'], features: [ - 'delivery-process/specs/*.feature', - 'delivery-process/decisions/*.feature', - 'delivery-process/releases/*.feature', + 'architect/specs/*.feature', + 'architect/decisions/*.feature', + 'architect/releases/*.feature', 'tests/features/**/*.feature', ], }, @@ -234,17 +234,17 @@ export default defineConfig({ outputDirectory: 'docs-live', }, changelog: { - additionalFeatures: ['delivery-process/decisions/*.feature'], + additionalFeatures: ['architect/decisions/*.feature'], outputDirectory: 'docs-live', }, architecture: { outputDirectory: 'docs-live', }, 'doc-from-decision': { - replaceFeatures: ['delivery-process/decisions/*.feature'], + replaceFeatures: ['architect/decisions/*.feature'], }, 'reference-docs': { - additionalFeatures: ['delivery-process/decisions/*.feature'], + additionalFeatures: ['architect/decisions/*.feature'], outputDirectory: 'docs-live', }, 'product-area-docs': { diff --git a/delivery-process/decisions/adr-001-taxonomy-canonical-values.feature b/architect/decisions/adr-001-taxonomy-canonical-values.feature similarity index 90% rename from delivery-process/decisions/adr-001-taxonomy-canonical-values.feature rename to architect/decisions/adr-001-taxonomy-canonical-values.feature index 1cac056c..b178d870 100644 --- a/delivery-process/decisions/adr-001-taxonomy-canonical-values.feature +++ b/architect/decisions/adr-001-taxonomy-canonical-values.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-adr:001 -@libar-docs-adr-status:accepted -@libar-docs-adr-category:process -@libar-docs-pattern:ADR001TaxonomyCanonicalValues -@libar-docs-status:roadmap -@libar-docs-product-area:Process -@libar-docs-convention:taxonomy-rules -@libar-docs-include:reference-sample,process-workflow +@architect +@architect-adr:001 +@architect-adr-status:accepted +@architect-adr-category:process +@architect-pattern:ADR001TaxonomyCanonicalValues +@architect-status:roadmap +@architect-product-area:Process +@architect-convention:taxonomy-rules +@architect-include:reference-sample,process-workflow Feature: ADR-001 - Taxonomy Canonical Values and Process Constants **Context:** @@ -34,10 +34,10 @@ Feature: ADR-001 - Taxonomy Canonical Values and Process Constants Background: Deliverables Given the following deliverables: | Deliverable | Status | Location | - | Decision spec | complete | delivery-process/decisions/adr-001 | + | Decision spec | complete | architect/decisions/adr-001 | | Migrate executable spec product-area tags | complete | tests/features/**/*.feature | - | Migrate tier 1 spec product-area tags | complete | delivery-process/specs/*.feature | - | Fix adr-category on existing decisions | pending | delivery-process/decisions/*.feature | + | Migrate tier 1 spec product-area tags | complete | architect/specs/*.feature | + | Fix adr-category on existing decisions | pending | architect/decisions/*.feature | # =========================================================================== # RULE 1: Product Area Canonical Values @@ -112,7 +112,7 @@ Feature: ADR-001 - Taxonomy Canonical Values and Process Constants | deferred | roadmap | Resume planning | Completed is a terminal state. Modifications require - `@libar-docs-unlock-reason` escape hatch. + `@architect-unlock-reason` escape hatch. # =========================================================================== # RULE 5: Tag Format Types @@ -126,12 +126,12 @@ Feature: ADR-001 - Taxonomy Canonical Values and Process Constants **Verified by:** Canonical values are enforced | Format | Parsing | Example | - | flag | Boolean presence, no value | @libar-docs-core | - | value | Simple string | @libar-docs-pattern MyPattern | - | enum | Constrained to predefined list | @libar-docs-status completed | - | csv | Comma-separated values | @libar-docs-uses A, B, C | - | number | Numeric value | @libar-docs-phase 15 | - | quoted-value | Preserves spaces | @libar-docs-brief:'Multi word' | + | flag | Boolean presence, no value | @architect-core | + | value | Simple string | @architect-pattern MyPattern | + | enum | Constrained to predefined list | @architect-status completed | + | csv | Comma-separated values | @architect-uses A, B, C | + | number | Numeric value | @architect-phase 15 | + | quoted-value | Preserves spaces | @architect-brief:'Multi word' | # =========================================================================== # RULE 6: Source Ownership diff --git a/delivery-process/decisions/adr-002-gherkin-only-testing.feature b/architect/decisions/adr-002-gherkin-only-testing.feature similarity index 83% rename from delivery-process/decisions/adr-002-gherkin-only-testing.feature rename to architect/decisions/adr-002-gherkin-only-testing.feature index d4347288..3c816fef 100644 --- a/delivery-process/decisions/adr-002-gherkin-only-testing.feature +++ b/architect/decisions/adr-002-gherkin-only-testing.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-adr:002 -@libar-docs-adr-status:accepted -@libar-docs-adr-category:testing -@libar-docs-pattern:ADR002GherkinOnlyTesting -@libar-docs-status:completed -@libar-docs-unlock-reason:Add-process-workflow-include-tag -@libar-docs-completed:2026-01-07 -@libar-docs-product-area:Process -@libar-docs-include:process-workflow +@architect +@architect-adr:002 +@architect-adr-status:accepted +@architect-adr-category:testing +@architect-pattern:ADR002GherkinOnlyTesting +@architect-status:completed +@architect-unlock-reason:Add-process-workflow-include-tag +@architect-completed:2026-01-07 +@architect-product-area:Process +@architect-include:process-workflow Feature: ADR-002 - Gherkin-Only Testing Policy **Context:** @@ -16,7 +16,7 @@ Feature: ADR-002 - Gherkin-Only Testing Policy This undermined the core thesis that Gherkin IS sufficient for all testing. **Decision:** - Enforce strict Gherkin-only testing for the delivery-process package: + Enforce strict Gherkin-only testing for the Architect package: - All tests must be `.feature` files with step definitions - No new `.test.ts` files - Edge cases use Scenario Outline with Examples tables @@ -54,7 +54,7 @@ Feature: ADR-002 - Gherkin-Only Testing Policy | Tests | .test.ts (hidden from docs) | .feature (visible in docs) | | Business rules | Manually maintained | Extracted from Rule blocks | | Acceptance criteria | Implicit in test code | Explicit @acceptance-criteria tags | - | Traceability | Manual cross-referencing | @libar-docs-implements links | + | Traceability | Manual cross-referencing | @architect-implements links | # =========================================================================== # ACCEPTANCE CRITERIA @@ -62,7 +62,7 @@ Feature: ADR-002 - Gherkin-Only Testing Policy @acceptance-criteria Scenario: Gherkin-only policy enforced - Given the delivery-process package + Given the Architect package When checking for .test.ts files in tests/ Then only step definition files (.steps.ts) are allowed And all test logic is in .feature files diff --git a/delivery-process/decisions/adr-003-source-first-pattern-architecture.feature b/architect/decisions/adr-003-source-first-pattern-architecture.feature similarity index 86% rename from delivery-process/decisions/adr-003-source-first-pattern-architecture.feature rename to architect/decisions/adr-003-source-first-pattern-architecture.feature index 27f8aa88..6b42a0bd 100644 --- a/delivery-process/decisions/adr-003-source-first-pattern-architecture.feature +++ b/architect/decisions/adr-003-source-first-pattern-architecture.feature @@ -1,17 +1,17 @@ -@libar-docs -@libar-docs-adr:003 -@libar-docs-adr-status:accepted -@libar-docs-adr-category:process -@libar-docs-pattern:ADR003SourceFirstPatternArchitecture -@libar-docs-status:roadmap -@libar-docs-product-area:Process -@libar-docs-include:process-workflow -@libar-docs-depends-on:ADR001TaxonomyCanonicalValues +@architect +@architect-adr:003 +@architect-adr-status:accepted +@architect-adr-category:process +@architect-pattern:ADR003SourceFirstPatternArchitecture +@architect-status:roadmap +@architect-product-area:Process +@architect-include:process-workflow +@architect-depends-on:ADR001TaxonomyCanonicalValues Feature: ADR-003 - Source-First Pattern Architecture **Context:** The original annotation architecture assumed pattern definitions live - in tier 1 feature specs, with TypeScript code limited to `@libar-docs-implements`. + in tier 1 feature specs, with TypeScript code limited to `@architect-implements`. At scale this creates three problems: tier 1 specs become stale after implementation (only 39% of 44 specs have traceability to executable specs), retroactive annotation of existing code triggers merge conflicts, and duplicated Rules/Scenarios in tier 1 @@ -38,7 +38,7 @@ Feature: ADR-003 - Source-First Pattern Architecture Background: Deliverables Given the following deliverables: | Deliverable | Status | Location | - | Decision spec | in-progress | delivery-process/decisions/adr-003 | + | Decision spec | in-progress | architect/decisions/adr-003 | | Update CLAUDE.md annotation ownership | pending | CLAUDE.md | | Update monorepo source-annotations.md | pending | monorepo _claude-md/ | | Reframe tag-duplication anti-pattern | pending | src/validation/anti-patterns.ts | @@ -49,7 +49,7 @@ Feature: ADR-003 - Source-First Pattern Architecture Rule: TypeScript source owns pattern identity - **Invariant:** A pattern is defined by `@libar-docs-pattern` in a TypeScript + **Invariant:** A pattern is defined by `@architect-pattern` in a TypeScript file — either a stub (pre-implementation) or source code (post-implementation). **Rationale:** If pattern identity lives in tier 1 specs, it becomes stale after implementation and diverges from the code that actually realizes the pattern. **Verified by:** TypeScript source is canonical pattern definition @@ -57,7 +57,7 @@ Feature: ADR-003 - Source-First Pattern Architecture **Pattern Definition Lifecycle:** | Phase | Location | Status | - | Design | `delivery-process/stubs/pattern-name/` | roadmap | + | Design | `architect/stubs/pattern-name/` | roadmap | | Implementation | `src/path/to/module.ts` | active | | Completed | `src/path/to/module.ts` | completed | @@ -106,15 +106,15 @@ Feature: ADR-003 - Source-First Pattern Architecture Rule: Implements is UML Realization (many-to-one) - **Invariant:** `@libar-docs-implements` declares a realization relationship. + **Invariant:** `@architect-implements` declares a realization relationship. Multiple files can implement the same pattern. One file can implement multiple patterns (CSV format). **Rationale:** Without many-to-one realization, cross-cutting patterns that span multiple files cannot be traced back to a single canonical definition. **Verified by:** TypeScript source is canonical pattern definition | Relationship | Tag | Cardinality | - | Definition | `@libar-docs-pattern` | Exactly one per pattern | - | Realization | `@libar-docs-implements` | Many-to-one | + | Definition | `@architect-pattern` | Exactly one per pattern | + | Realization | `@architect-implements` | Many-to-one | # =========================================================================== # RULE 5: Single-Definition Constraint @@ -122,7 +122,7 @@ Feature: ADR-003 - Source-First Pattern Architecture Rule: Single-definition constraint - **Invariant:** `@libar-docs-pattern:X` may appear in exactly one file + **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. @@ -142,8 +142,8 @@ Feature: ADR-003 - Source-First Pattern Architecture Rule: Reverse links preferred over forward links - **Invariant:** `@libar-docs-implements` (reverse: "I verify this pattern") - is the primary traceability mechanism. `@libar-docs-executable-specs` + **Invariant:** `@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. **Rationale:** 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. **Verified by:** TypeScript source is canonical pattern definition @@ -158,7 +158,7 @@ Feature: ADR-003 - Source-First Pattern Architecture @acceptance-criteria Scenario: TypeScript source is canonical pattern definition - Given a pattern defined in a TypeScript file with @libar-docs-pattern - When an executable spec references it with @libar-docs-implements + Given a pattern defined in a TypeScript file with @architect-pattern + When an executable spec references it with @architect-implements Then the TypeScript file owns the pattern identity And the executable spec owns behavior verification diff --git a/delivery-process/decisions/adr-005-codec-based-markdown-rendering.feature b/architect/decisions/adr-005-codec-based-markdown-rendering.feature similarity index 97% rename from delivery-process/decisions/adr-005-codec-based-markdown-rendering.feature rename to architect/decisions/adr-005-codec-based-markdown-rendering.feature index 484570ac..19ff6074 100644 --- a/delivery-process/decisions/adr-005-codec-based-markdown-rendering.feature +++ b/architect/decisions/adr-005-codec-based-markdown-rendering.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-adr:005 -@libar-docs-adr-status:accepted -@libar-docs-adr-category:architecture -@libar-docs-pattern:ADR005CodecBasedMarkdownRendering -@libar-docs-status:completed -@libar-docs-completed:2025-12-15 -@libar-docs-product-area:Generation -@libar-docs-include:reference-sample +@architect +@architect-adr:005 +@architect-adr-status:accepted +@architect-adr-category:architecture +@architect-pattern:ADR005CodecBasedMarkdownRendering +@architect-status:completed +@architect-completed:2025-12-15 +@architect-product-area:Generation +@architect-include:reference-sample Feature: ADR-005 - Codec-Based Markdown Rendering **Context:** diff --git a/delivery-process/decisions/adr-006-single-read-model-architecture.feature b/architect/decisions/adr-006-single-read-model-architecture.feature similarity index 93% rename from delivery-process/decisions/adr-006-single-read-model-architecture.feature rename to architect/decisions/adr-006-single-read-model-architecture.feature index 80440398..f878bed4 100644 --- a/delivery-process/decisions/adr-006-single-read-model-architecture.feature +++ b/architect/decisions/adr-006-single-read-model-architecture.feature @@ -1,17 +1,17 @@ -@libar-docs -@libar-docs-adr:006 -@libar-docs-adr-status:roadmap -@libar-docs-adr-category:architecture -@libar-docs-pattern:ADR006SingleReadModelArchitecture -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-include:process-workflow,codec-transformation -@libar-docs-depends-on:ADR005CodecBasedMarkdownRendering -@libar-docs-unlock-reason:Add-Verified-by-sections-and-acceptance-criteria +@architect +@architect-adr:006 +@architect-adr-status:roadmap +@architect-adr-category:architecture +@architect-pattern:ADR006SingleReadModelArchitecture +@architect-status:completed +@architect-product-area:Generation +@architect-include:process-workflow,codec-transformation +@architect-depends-on:ADR005CodecBasedMarkdownRendering +@architect-unlock-reason:Add-Verified-by-sections-and-acceptance-criteria Feature: ADR-006 - Single Read Model Architecture **Context:** - The delivery-process package applies event sourcing to itself: git is + 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 — produced by a single-pass O(n) transformer with pre-computed views diff --git a/delivery-process/decisions/pdr-001-session-workflow-commands.feature b/architect/decisions/pdr-001-session-workflow-commands.feature similarity index 96% rename from delivery-process/decisions/pdr-001-session-workflow-commands.feature rename to architect/decisions/pdr-001-session-workflow-commands.feature index 5a8e3d33..023f0c07 100644 --- a/delivery-process/decisions/pdr-001-session-workflow-commands.feature +++ b/architect/decisions/pdr-001-session-workflow-commands.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-adr:004 -@libar-docs-adr-status:accepted -@libar-docs-adr-category:architecture -@libar-docs-pattern:PDR001SessionWorkflowCommands -@libar-docs-status:roadmap -@libar-docs-product-area:DataAPI -@libar-docs-depends-on:DataAPIDesignSessionSupport +@architect +@architect-adr:004 +@architect-adr-status:accepted +@architect-adr-category:architecture +@architect-pattern:PDR001SessionWorkflowCommands +@architect-status:roadmap +@architect-product-area:DataAPI +@architect-depends-on:DataAPIDesignSessionSupport Feature: PDR-001 - Session Workflow Commands Design Decisions **Context:** diff --git a/delivery-process/design-reviews/mcp-server-integration.md b/architect/design-reviews/mcp-server-integration.md similarity index 89% rename from delivery-process/design-reviews/mcp-server-integration.md rename to architect/design-reviews/mcp-server-integration.md index 4cad352a..2c240c4d 100644 --- a/delivery-process/design-reviews/mcp-server-integration.md +++ b/architect/design-reviews/mcp-server-integration.md @@ -7,7 +7,7 @@ **Pattern:** MCPServerIntegration | **Phase:** Phase 46 | **Status:** active | **Orchestrator:** mcp-server | **Steps:** 5 | **Participants:** 4 -**Source:** `delivery-process/specs/mcp-server-integration.feature` +**Source:** `architect/specs/mcp-server-integration.feature` --- @@ -28,7 +28,7 @@ Description markers: `**Input:**` and `**Output:**` in Rule descriptions define ## Sequence Diagram — Runtime Interaction Flow -Generated from: `@libar-docs-sequence-step`, `@libar-docs-sequence-module`, `@libar-docs-sequence-error`, `**Input:**`/`**Output:**` markers, and `@libar-docs-sequence-orchestrator` on the Feature. +Generated from: `@architect-sequence-step`, `@architect-sequence-module`, `@architect-sequence-error`, `**Input:**`/`**Output:**` markers, and `@architect-sequence-orchestrator` on the Feature. ```mermaid sequenceDiagram @@ -50,7 +50,7 @@ sequenceDiagram mcp_server->>mcp_server: exit(1) end - Note over mcp_server: Rule 2 — Every CLI subcommand is registered as an MCP tool with a JSON Schema describing its input parameters. Tool names use snake_case with a "dp_" prefix to avoid collisions with other MCP servers. + Note over mcp_server: Rule 2 — Every CLI subcommand is registered as an MCP tool with a JSON Schema describing its input parameters. Tool names use snake_case with a "architect_" prefix to avoid collisions with other MCP servers. mcp_server->>+tool_registry: PipelineSession tool_registry-->>-mcp_server: RegisteredTools @@ -60,7 +60,7 @@ sequenceDiagram mcp_server->>mcp_server: exit(1) end - Note over mcp_server: Rule 3 — The pipeline runs exactly once during server initialization. All subsequent tool calls read from in-memory MasterDataset. A manual rebuild can be triggered via a "dp_rebuild" tool, and overlapping rebuild requests coalesce so the final in-memory session reflects the newest completed build. + Note over mcp_server: Rule 3 — The pipeline runs exactly once during server initialization. All subsequent tool calls read from in-memory MasterDataset. A manual rebuild can be triggered via a "architect_rebuild" tool, and overlapping rebuild requests coalesce so the final in-memory session reflects the newest completed build. mcp_server->>+pipeline_session: ToolCallRequest pipeline_session-->>-mcp_server: ToolCallResult @@ -80,7 +80,7 @@ sequenceDiagram mcp_server->>mcp_server: exit(1) end - Note over mcp_server: Rule 5 — The server works with .mcp.json (Claude Code), claude_desktop_config.json (Claude Desktop), and any MCP client. It accepts —input, —features, —base-dir args, auto-detects delivery-process.config.ts, and reports the package version accurately through the CLI. + Note over mcp_server: Rule 5 — The server works with .mcp.json (Claude Code), claude_desktop_config.json (Claude Desktop), and any MCP client. It accepts —input, —features, —base-dir args, auto-detects architect.config.ts, and reports the package version accurately through the CLI. mcp_server->>+mcp_server: CLIArgs mcp_server-->>-mcp_server: McpServerOptions @@ -96,7 +96,7 @@ sequenceDiagram ## Component Diagram — Types and Data Flow -Generated from: `@libar-docs-sequence-module` (nodes), `**Input:**`/`**Output:**` (edges and type shapes), deliverables table (locations), and `sequence-step` (grouping). +Generated from: `@architect-sequence-module` (nodes), `**Input:**`/`**Output:**` (edges and type shapes), deliverables table (locations), and `sequence-step` (grouping). ```mermaid graph LR @@ -126,7 +126,7 @@ graph LR subgraph types["Key Types"] PipelineSession{{"PipelineSession\n-----------\ndataset\napi\nregistry\nbaseDir\nsourceGlobs\nbuildTimeMs"}} - RegisteredTools{{"RegisteredTools\n-----------\n25 tools with dp_ prefix\nZod input schemas\nhandler functions"}} + RegisteredTools{{"RegisteredTools\n-----------\n25 tools with architect_ prefix\nZod input schemas\nhandler functions"}} ToolCallResult{{"ToolCallResult\n-----------\ncontent\nisError"}} McpServerOptions{{"McpServerOptions\n-----------\nparsed options merged with config defaults"}} end diff --git a/delivery-process/design-reviews/setup-command.md b/architect/design-reviews/setup-command.md similarity index 89% rename from delivery-process/design-reviews/setup-command.md rename to architect/design-reviews/setup-command.md index e03eeeb0..d2b4fed8 100644 --- a/delivery-process/design-reviews/setup-command.md +++ b/architect/design-reviews/setup-command.md @@ -7,7 +7,7 @@ **Pattern:** SetupCommand | **Phase:** Phase 45 | **Status:** roadmap | **Orchestrator:** init-cli | **Steps:** 6 | **Participants:** 8 -**Source:** `delivery-process/specs/setup-command.feature` +**Source:** `architect/specs/setup-command.feature` --- @@ -28,7 +28,7 @@ Description markers: `**Input:**` and `**Output:**` in Rule descriptions define ## Sequence Diagram — Runtime Interaction Flow -Generated from: `@libar-docs-sequence-step`, `@libar-docs-sequence-module`, `@libar-docs-sequence-error`, `**Input:**`/`**Output:**` markers, and `@libar-docs-sequence-orchestrator` on the Feature. +Generated from: `@architect-sequence-step`, `@architect-sequence-module`, `@architect-sequence-error`, `**Input:**`/`**Output:**` markers, and `@architect-sequence-orchestrator` on the Feature. ```mermaid sequenceDiagram @@ -44,7 +44,7 @@ sequenceDiagram User->>init_cli: invoke - Note over init_cli: Rule 1 — The init command reads the target directory for package.json, tsconfig.json, delivery-process.config.ts (or .js), and monorepo markers before prompting or generating any files. Detection results determine which steps are skipped. + Note over init_cli: Rule 1 — The init command reads the target directory for package.json, tsconfig.json, architect.config.ts (or .js), and monorepo markers before prompting or generating any files. Detection results determine which steps are skipped. init_cli->>+detect_context: targetDir: string detect_context-->>-init_cli: ProjectContext @@ -64,10 +64,10 @@ sequenceDiagram init_cli->>init_cli: exit(1) end - Note over init_cli: Rule 3 — The generated delivery-process.config.ts (or .js) imports defineConfig from the correct path, uses the selected preset, and includes configured source globs. An existing config file is never overwritten without confirmation. + Note over init_cli: Rule 3 — The generated architect.config.ts (or .js) imports defineConfig from the correct path, uses the selected preset, and includes configured source globs. An existing config file is never overwritten without confirmation. init_cli->>+generate_config: InitConfig - generate_config-->>-init_cli: delivery-process.config.ts written to targetDir + generate_config-->>-init_cli: architect.config.ts written to targetDir alt Existing config file is not overwritten without confirmation init_cli-->>User: error @@ -102,7 +102,7 @@ sequenceDiagram ## Component Diagram — Types and Data Flow -Generated from: `@libar-docs-sequence-module` (nodes), `**Input:**`/`**Output:**` (edges and type shapes), deliverables table (locations), and `sequence-step` (grouping). +Generated from: `@architect-sequence-module` (nodes), `**Input:**`/`**Output:**` (edges and type shapes), deliverables table (locations), and `sequence-step` (grouping). ```mermaid graph LR diff --git a/delivery-process/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature b/architect/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature similarity index 96% rename from delivery-process/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature rename to architect/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature index 17057000..930807b5 100644 --- a/delivery-process/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature +++ b/architect/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature @@ -16,7 +16,7 @@ Feature: Workflow Configuration, Process Instance, and FSM Extensibility When different presets need different default phases (e.g., 3-phase generic vs 6-phase USDP), the inline constant in workflow-loader.ts is insufficient. - Workflow becomes a field on `DeliveryProcessConfig`, like categories. + Workflow becomes a field on `ArchitectConfig`, like categories. **Option A: Preset-level default (recommended)** @@ -115,11 +115,11 @@ Feature: Workflow Configuration, Process Instance, and FSM Extensibility This ideation artifact is an experiment in that direction: | Property | Value | - | Lives in | delivery-process/ideations/ (not specs/, not decisions/) | + | Lives in | architect/ideations/ (not specs/, not decisions/) | | Format | Gherkin-structured but not executable | | FSM status | Not tracked (ideation precedes roadmap) | | Lifecycle | Active while useful, trimmed as specs consume content | **Open question:** Should ideation artifacts be scannable by the extractor? - Selective opt-in via `@libar-docs` tag matches the existing architecture — + Selective opt-in via `@architect` tag matches the existing architecture — most stay invisible, the ones worth surfacing get a tag. diff --git a/delivery-process/ideations/2026-02-16-process-api-layered-extraction-findings.feature b/architect/ideations/2026-02-16-process-api-layered-extraction-findings.feature similarity index 100% rename from delivery-process/ideations/2026-02-16-process-api-layered-extraction-findings.feature rename to architect/ideations/2026-02-16-process-api-layered-extraction-findings.feature diff --git a/delivery-process/releases/v1.0.0.feature b/architect/releases/v1.0.0.feature similarity index 74% rename from delivery-process/releases/v1.0.0.feature rename to architect/releases/v1.0.0.feature index 3d918725..c03539fc 100644 --- a/delivery-process/releases/v1.0.0.feature +++ b/architect/releases/v1.0.0.feature @@ -1,15 +1,15 @@ -@libar-docs -@libar-docs-release:v1.0.0 -@libar-docs-status:active -@libar-docs-product-area:DeliveryProcess +@architect +@architect-release:v1.0.0 +@architect-status:active +@architect-product-area:DeliveryProcess Feature: v1.0.0 - Package Extraction Release - First independent release of @libar-dev/delivery-process as a + First independent release of @libar-dev/architect as a standalone package. **Summary - TODO - releases should have minimal content and primarily serve to "instantiate" release/phase annotations:** - This release marks the extraction of delivery-process from the + This release marks the extraction of Architect from the convex-event-sourcing monorepo into an independent package ready for standalone publication. @@ -19,7 +19,7 @@ Feature: v1.0.0 - Package Extraction Release - TypeScript-sourced taxonomy with Zod validation (no JSON dependencies) - FSM-enforced workflow (roadmap → active → completed) - Process Guard linter for file protection - - Configurable tag prefix support (`@libar-docs-*` or custom) + - Configurable tag prefix support (`@architect-*` or custom) - Self-documentation infrastructure (dog-fooding) - 11 section renderers and pluggable generator architecture - Gherkin scanner for dual-source extraction (code + feature files) @@ -37,4 +37,4 @@ Feature: v1.0.0 - Package Extraction Release **Migration Notes:** Consumers previously importing from the monorepo should update their - package.json to reference `@libar-dev/delivery-process@1.0.0`. + package.json to reference `@libar-dev/architect@1.0.0`. diff --git a/delivery-process/releases/vNEXT.feature b/architect/releases/vNEXT.feature similarity index 55% rename from delivery-process/releases/vNEXT.feature rename to architect/releases/vNEXT.feature index 8b860efc..dddfe6ec 100644 --- a/delivery-process/releases/vNEXT.feature +++ b/architect/releases/vNEXT.feature @@ -1,15 +1,15 @@ -@libar-docs -@libar-docs-release:vNEXT -@libar-docs-status:active -@libar-docs-product-area:DeliveryProcess +@architect +@architect-release:vNEXT +@architect-status:active +@architect-product-area:DeliveryProcess Feature: vNEXT - Unreleased Package Work - Staging area for delivery-process package work not yet assigned + Staging area for Architect package work not yet assigned to a release version. **Purpose:** - Deliverables tagged with @libar-docs-release:vNEXT are tracked here + Deliverables tagged with @architect-release:vNEXT are tracked here until a release is cut. When cutting a release: 1. Determine version number based on changes (major/minor/patch) @@ -19,4 +19,4 @@ Feature: vNEXT - Unreleased Package Work **Current Work:** - See deliverables tagged with @libar-docs-release:vNEXT in the codebase. + See deliverables tagged with @architect-release:vNEXT in the codebase. diff --git a/delivery-process/specs/architecture-delta.feature b/architect/specs/architecture-delta.feature similarity index 88% rename from delivery-process/specs/architecture-delta.feature rename to architect/specs/architecture-delta.feature index 5618ce27..5ae4e788 100644 --- a/delivery-process/specs/architecture-delta.feature +++ b/architect/specs/architecture-delta.feature @@ -1,12 +1,12 @@ @opportunity-5 -@libar-docs -@libar-docs-pattern:ArchitectureDelta -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-effort:2d -@libar-docs-product-area:Generation -@libar-docs-business-value:document-release-changes-automatically -@libar-docs-priority:medium +@architect +@architect-pattern:ArchitectureDelta +@architect-status:roadmap +@architect-phase:100 +@architect-effort:2d +@architect-product-area:Generation +@architect-business-value:document-release-changes-automatically +@architect-priority:medium Feature: Architecture Delta Generation - ADRs as Release Notes **Problem:** @@ -23,7 +23,7 @@ Feature: Architecture Delta Generation - ADRs as Release Notes - Breaking changes (with migration notes) Uses git tags to determine release boundaries. - Uses @libar-docs-decision, @libar-docs-replaces annotations. + Uses @architect-decision, @architect-replaces annotations. Implements Convergence Opportunity 5: Architecture Change Control. diff --git a/delivery-process/specs/architecture-diagram-advanced.feature b/architect/specs/architecture-diagram-advanced.feature similarity index 94% rename from delivery-process/specs/architecture-diagram-advanced.feature rename to architect/specs/architecture-diagram-advanced.feature index e3cba038..9cdd5560 100644 --- a/delivery-process/specs/architecture-diagram-advanced.feature +++ b/architect/specs/architecture-diagram-advanced.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:ArchitectureDiagramAdvanced -@libar-docs-status:completed -@libar-docs-unlock-reason:Retroactive-completion -@libar-docs-phase:23 -@libar-docs-effort:1w -@libar-docs-product-area:Generation -@libar-docs-executable-specs:tests/features/behavior/architecture-diagrams +@architect +@architect-pattern:ArchitectureDiagramAdvanced +@architect-status:completed +@architect-unlock-reason:Retroactive-completion +@architect-phase:23 +@architect-effort:1w +@architect-product-area:Generation +@architect-executable-specs:tests/features/behavior/architecture-diagrams Feature: Architecture Diagram Generation - Advanced **Problem:** Core diagram generation (see ArchitectureDiagramCore) produces @@ -15,7 +15,7 @@ Feature: Architecture Diagram Generation - Advanced diagrams showing runtime interaction flows between components. **Solution:** Extend the architecture diagram system with advanced capabilities: - - Layered diagrams that group patterns by `@libar-docs-arch-layer` (domain, application, infrastructure) + - Layered diagrams that group patterns by `@architect-arch-layer` (domain, application, infrastructure) - Generator registry integration for CLI-driven generation via `pnpm docs:architecture` - Sequence diagram support for modeling runtime interactions between components @@ -97,7 +97,7 @@ Feature: Architecture Diagram Generation - Advanced **Invariant:** An "architecture" generator must be registered with the generator registry to enable `pnpm docs:architecture` via the existing `generate-docs.js` CLI. - **Rationale:** The delivery-process uses a generator registry pattern. New + **Rationale:** The Architect uses a generator registry pattern. New generators register with the orchestrator rather than creating separate CLI commands. **Verified by:** Generator is registered, Generator produces component diagram, diff --git a/delivery-process/specs/architecture-diagram-core.feature b/architect/specs/architecture-diagram-core.feature similarity index 90% rename from delivery-process/specs/architecture-diagram-core.feature rename to architect/specs/architecture-diagram-core.feature index a5aa7b31..7f95180d 100644 --- a/delivery-process/specs/architecture-diagram-core.feature +++ b/architect/specs/architecture-diagram-core.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:ArchitectureDiagramCore -@libar-docs-status:completed -@libar-docs-unlock-reason:Retroactive-completion -@libar-docs-phase:23 -@libar-docs-effort:1w -@libar-docs-product-area:Generation -@libar-docs-executable-specs:tests/features/behavior/architecture-diagrams +@architect +@architect-pattern:ArchitectureDiagramCore +@architect-status:completed +@architect-unlock-reason:Retroactive-completion +@architect-phase:23 +@architect-effort:1w +@architect-product-area:Generation +@architect-executable-specs:tests/features/behavior/architecture-diagrams Feature: Architecture Diagram Generation - Core **Problem:** Architecture documentation requires manually maintaining mermaid diagrams @@ -14,9 +14,9 @@ Feature: Architecture Diagram Generation - Core **Solution:** Generate architecture diagrams automatically from source code annotations using dedicated `arch-*` tags for precise control. Three tags classify components: - - `@libar-docs-arch-role` - Component type (preset-configurable: service, handler, repository, etc.) - - `@libar-docs-arch-context` - Bounded context for subgraph grouping - - `@libar-docs-arch-layer` - Architectural layer (domain, application, infrastructure) + - `@architect-arch-role` - Component type (preset-configurable: service, handler, repository, etc.) + - `@architect-arch-context` - Bounded context for subgraph grouping + - `@architect-arch-layer` - Architectural layer (domain, application, infrastructure) **Why It Matters:** | Benefit | How | @@ -101,10 +101,10 @@ Feature: Architecture Diagram Generation - Core Given TypeScript source with annotation: """typescript /** - * @libar-docs - * @libar-docs-pattern MyProjection - * @libar-docs-status completed - * @libar-docs-arch-role projection + * @architect + * @architect-pattern MyProjection + * @architect-status completed + * @architect-arch-role projection */ """ When the AST parser extracts metadata @@ -115,10 +115,10 @@ Feature: Architecture Diagram Generation - Core Given TypeScript source with annotation: """typescript /** - * @libar-docs - * @libar-docs-pattern OrderHandler - * @libar-docs-status completed - * @libar-docs-arch-context orders + * @architect + * @architect-pattern OrderHandler + * @architect-status completed + * @architect-arch-context orders */ """ When the AST parser extracts metadata @@ -129,10 +129,10 @@ Feature: Architecture Diagram Generation - Core Given TypeScript source with annotation: """typescript /** - * @libar-docs - * @libar-docs-pattern MyInfra - * @libar-docs-status completed - * @libar-docs-arch-layer infrastructure + * @architect + * @architect-pattern MyInfra + * @architect-status completed + * @architect-arch-layer infrastructure */ """ When the AST parser extracts metadata @@ -143,12 +143,12 @@ Feature: Architecture Diagram Generation - Core Given TypeScript source with annotation: """typescript /** - * @libar-docs - * @libar-docs-pattern OrderCommandHandlers - * @libar-docs-status completed - * @libar-docs-arch-role command-handler - * @libar-docs-arch-context orders - * @libar-docs-arch-layer application + * @architect + * @architect-pattern OrderCommandHandlers + * @architect-status completed + * @architect-arch-role command-handler + * @architect-arch-context orders + * @architect-arch-layer application */ """ When the AST parser extracts metadata @@ -161,9 +161,9 @@ Feature: Architecture Diagram Generation - Core Given TypeScript source with annotation: """typescript /** - * @libar-docs - * @libar-docs-pattern NoArchTags - * @libar-docs-status completed + * @architect + * @architect-pattern NoArchTags + * @architect-status completed */ """ When the AST parser extracts metadata diff --git a/delivery-process/specs/architecture-doc-refactoring.feature b/architect/specs/architecture-doc-refactoring.feature similarity index 96% rename from delivery-process/specs/architecture-doc-refactoring.feature rename to architect/specs/architecture-doc-refactoring.feature index be714ed3..5d148e43 100644 --- a/delivery-process/specs/architecture-doc-refactoring.feature +++ b/architect/specs/architecture-doc-refactoring.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:ArchitectureDocRefactoring -@libar-docs-status:completed -@libar-docs-unlock-reason:Implement-test-coverage-and-fix-spec-metadata -@libar-docs-phase:36 -@libar-docs-effort:2d -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocsConsolidationStrategy -@libar-docs-business-value:decomposes-1287-line-manual-architecture-doc-into-curated-overview-with-generated-references -@libar-docs-priority:high +@architect +@architect-pattern:ArchitectureDocRefactoring +@architect-status:completed +@architect-unlock-reason:Implement-test-coverage-and-fix-spec-metadata +@architect-phase:36 +@architect-effort:2d +@architect-product-area:Generation +@architect-depends-on:DocsConsolidationStrategy +@architect-business-value:decomposes-1287-line-manual-architecture-doc-into-curated-overview-with-generated-references +@architect-priority:high Feature: Architecture Document Refactoring **Problem:** @@ -54,7 +54,7 @@ Feature: Architecture Document Refactoring | Deliverable | Status | Location | Tests | Test Type | | Convention-tag codec-registry on 14 codec files | complete | src/renderable/codecs/*.ts | Yes | integration | | Machine-extractable JSDoc format for codecs | complete | src/renderable/codecs/*.ts | Yes | integration | - | Codec-registry reference config | complete | delivery-process.config.ts | Yes | integration | + | Codec-registry reference config | complete | architect.config.ts | Yes | integration | | Convention-extractor heading match bugfix | complete | src/renderable/codecs/convention-extractor.ts | Yes | unit | | Available Codecs section replaced with pointer | complete | docs/ARCHITECTURE.md | No | n/a | | Configuration Architecture to product area | complete | docs/ARCHITECTURE.md | Yes | integration | @@ -67,7 +67,7 @@ Feature: Architecture Document Refactoring Rule: Convention-tagged JSDoc produces machine-extractable codec documentation - **Invariant:** Every codec source file annotated with `@libar-docs-convention + **Invariant:** Every codec source file annotated with `@architect-convention codec-registry` must have structured JSDoc following the machine-extractable format. The convention extractor splits multi-codec files by `## Heading` into separate convention rules, each rendered as its own section in the generated @@ -101,7 +101,7 @@ Feature: Architecture Document Refactoring **Purpose:** Active development work in progress. **Output Files:** CURRENT-WORK.md """ - And the file is annotated with @libar-docs-convention codec-registry + And the file is annotated with @architect-convention codec-registry When the convention extractor processes the file Then three separate convention rules are produced And each rule has its own Purpose and Output Files @@ -121,7 +121,7 @@ Feature: Architecture Document Refactoring @acceptance-criteria @edge-case Scenario: Codec file without structured JSDoc produces fallback - Given a codec file with @libar-docs-convention codec-registry + Given a codec file with @architect-convention codec-registry But the JSDoc lacks structured headings When the convention extractor processes the file Then the entire JSDoc description is treated as a single convention rule @@ -221,7 +221,7 @@ Feature: Architecture Document Refactoring @acceptance-criteria @happy-path Scenario: Shape reference covers MasterDataset documentation Given the Unified Transformation section with MasterDataset schema - And TypeScript types tagged with @libar-docs-shape in the source + And TypeScript types tagged with @architect-shape in the source When a shapes reference doc config targets MasterDataset types Then the generated shapes section contains the same type definitions And the manual schema documentation can be replaced diff --git a/delivery-process/specs/business-rules-generator.feature b/architect/specs/business-rules-generator.feature similarity index 90% rename from delivery-process/specs/business-rules-generator.feature rename to architect/specs/business-rules-generator.feature index 43a6b755..c484ee75 100644 --- a/delivery-process/specs/business-rules-generator.feature +++ b/architect/specs/business-rules-generator.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:BusinessRulesGenerator -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-effort:3d -@libar-docs-product-area:Generation +@architect +@architect-pattern:BusinessRulesGenerator +@architect-status:roadmap +@architect-phase:100 +@architect-effort:3d +@architect-product-area:Generation Feature: Business Rules Generator - Extract Invariants and Rationale from Feature Files **Business Value:** Enable stakeholders to understand domain constraints without reading @@ -25,9 +25,9 @@ Feature: Business Rules Generator - Extract Invariants and Rationale from Featur Background: Deliverables Given the following deliverables: | Deliverable | Status | Location | Tests | Test Type | - | Business rules extractor | pending | @libar-dev/delivery-process/src/generators/business-rules/ | Yes | unit | - | Business rules renderer | pending | @libar-dev/delivery-process/src/generators/business-rules/ | Yes | unit | - | CLI integration | pending | @libar-dev/delivery-process/src/cli/generate-docs.ts | Yes | unit | + | Business rules extractor | pending | @libar-dev/architect/src/generators/business-rules/ | Yes | unit | + | Business rules renderer | pending | @libar-dev/architect/src/generators/business-rules/ | Yes | unit | + | CLI integration | pending | @libar-dev/architect/src/cli/generate-docs.ts | Yes | unit | | docs:business-rules script | pending | package.json | No | - | # =========================================================================== @@ -80,7 +80,7 @@ Feature: Business Rules Generator - Extract Invariants and Rationale from Featur Rule: Organizes rules by domain category and phase - **Invariant:** Rules are grouped first by domain category (from `@libar-docs-*` flags), + **Invariant:** Rules are grouped first by domain category (from `@architect-*` flags), then by phase number for temporal ordering. **Rationale:** Domain-organized documentation helps stakeholders find rules relevant @@ -92,9 +92,9 @@ Feature: Business Rules Generator - Extract Invariants and Rationale from Featur Scenario: Groups rules by domain category Given feature files with these domain tags: | Feature | Domain Tag | Rule | - | reservation-pattern.feature | @libar-docs-ddd | Reservations prevent race conditions | - | event-store.feature | @libar-docs-event-sourcing | Events are immutable | - | projection-categories.feature | @libar-docs-cqrs | Projections must declare category | + | reservation-pattern.feature | @architect-ddd | Reservations prevent race conditions | + | event-store.feature | @architect-event-sourcing | Events are immutable | + | projection-categories.feature | @architect-cqrs | Projections must declare category | When the business rules generator runs Then output should have section "## DDD Patterns" And output should have section "## Event Sourcing Patterns" diff --git a/delivery-process/specs/claude-module-generation.feature b/architect/specs/claude-module-generation.feature similarity index 94% rename from delivery-process/specs/claude-module-generation.feature rename to architect/specs/claude-module-generation.feature index 71c869e9..e7cef798 100644 --- a/delivery-process/specs/claude-module-generation.feature +++ b/architect/specs/claude-module-generation.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:ClaudeModuleGeneration -@libar-docs-status:completed -@libar-docs-unlock-reason:Skip-Feature-description-in-module-output -@libar-docs-phase:25 -@libar-docs-effort:1.5d -@libar-docs-product-area:Generation -@libar-docs-business-value:automated-claude-md-modules-from-source -@libar-docs-priority:high -@libar-docs-executable-specs:tests/features/behavior/claude-modules +@architect +@architect-pattern:ClaudeModuleGeneration +@architect-status:completed +@architect-unlock-reason:Skip-Feature-description-in-module-output +@architect-phase:25 +@architect-effort:1.5d +@architect-product-area:Generation +@architect-business-value:automated-claude-md-modules-from-source +@architect-priority:high +@architect-executable-specs:tests/features/behavior/claude-modules Feature: CLAUDE.md Module Generation from Source Annotations **Problem:** CLAUDE.md modules are hand-written markdown files that drift from source @@ -21,9 +21,9 @@ Feature: CLAUDE.md Module Generation from Source Annotations - Detailed documentation for `docs/` (human reference, progressive disclosure) Three tags control module generation: - - `@libar-docs-claude-module` - Module identifier (becomes filename) - - `@libar-docs-claude-section` - Target section directory in `_claude-md/` - - `@libar-docs-claude-tags` - Tags for variation filtering in modular-claude-md + - `@architect-claude-module` - Module identifier (becomes filename) + - `@architect-claude-section` - Target section directory in `_claude-md/` + - `@architect-claude-tags` - Tags for variation filtering in modular-claude-md **Why It Matters:** | Benefit | How | @@ -36,7 +36,7 @@ Feature: CLAUDE.md Module Generation from Source Annotations **Prototype Example:** The Process Guard behavior spec (`tests/features/validation/process-guard.feature`) - generates both `_claude-md/delivery-process/process-guard.md` and detailed docs. + generates both `_claude-md/architect/process-guard.md` and detailed docs. Background: Deliverables Given the following deliverables: @@ -112,8 +112,8 @@ Feature: CLAUDE.md Module Generation from Source Annotations Scenario: Extract claude-module from feature tags Given a feature file with tags: """gherkin - @libar-docs-claude-module:process-guard - @libar-docs-claude-section:delivery-process + @architect-claude-module:process-guard + @architect-claude-section:delivery-process Feature: Process Guard """ When the Gherkin extractor processes the file @@ -123,8 +123,8 @@ Feature: CLAUDE.md Module Generation from Source Annotations Scenario: Extract claude-section from feature tags Given a feature file with tags: """gherkin - @libar-docs-claude-module:fsm-validator - @libar-docs-claude-section:testing + @architect-claude-module:fsm-validator + @architect-claude-section:testing Feature: FSM Validator """ When the Gherkin extractor processes the file @@ -134,7 +134,7 @@ Feature: CLAUDE.md Module Generation from Source Annotations Scenario: Extract claude-tags as array Given a feature file with tags: """gherkin - @libar-docs-claude-tags:core-mandatory,delivery-process,platform-packages + @architect-claude-tags:core-mandatory,delivery-process,platform-packages Feature: Multi-tag Example """ When the Gherkin extractor processes the file @@ -300,7 +300,7 @@ Feature: CLAUDE.md Module Generation from Source Annotations | claude-section | delivery-process | And output directory is "_claude-md" When the generator runs - Then file should be written to "_claude-md/delivery-process/process-guard.md" + Then file should be written to "_claude-md/architect/process-guard.md" @acceptance-criteria @happy-path Scenario: Multiple modules generated from single run @@ -311,7 +311,7 @@ Feature: CLAUDE.md Module Generation from Source Annotations | LayerInference | layer-inference | testing | When the generator runs Then 3 module files should be created - And "_claude-md/delivery-process/process-guard.md" should exist + And "_claude-md/architect/process-guard.md" should exist And "_claude-md/testing/fsm-validator.md" should exist And "_claude-md/testing/layer-inference.md" should exist diff --git a/delivery-process/specs/cli-behavior-testing.feature b/architect/specs/cli-behavior-testing.feature similarity index 92% rename from delivery-process/specs/cli-behavior-testing.feature rename to architect/specs/cli-behavior-testing.feature index 52611936..9899562c 100644 --- a/delivery-process/specs/cli-behavior-testing.feature +++ b/architect/specs/cli-behavior-testing.feature @@ -1,14 +1,14 @@ -@libar-docs -@libar-docs-pattern:CliBehaviorTesting -@libar-docs-status:roadmap -@libar-docs-phase:101 -@libar-docs-effort:3d -@libar-docs-product-area:Process -@libar-docs-include:process-workflow -@libar-docs-depends-on:ADR002GherkinOnlyTesting -@libar-docs-business-value:ensure-cli-commands-work-correctly-with-all-argument-combinations -@libar-docs-priority:high -@libar-docs-executable-specs:tests/features/cli +@architect +@architect-pattern:CliBehaviorTesting +@architect-status:roadmap +@architect-phase:101 +@architect-effort:3d +@architect-product-area:Process +@architect-include:process-workflow +@architect-depends-on:ADR002GherkinOnlyTesting +@architect-business-value:ensure-cli-commands-work-correctly-with-all-argument-combinations +@architect-priority:high +@architect-executable-specs:tests/features/cli Feature: CLI Behavior Testing **Problem:** @@ -55,7 +55,7 @@ Feature: CLI Behavior Testing @acceptance-criteria @happy-path Scenario: Generate specific document type - Given TypeScript files with @libar-docs annotations + Given TypeScript files with @architect annotations And feature files with pattern metadata When running "generate-docs -g patterns -o docs" Then PATTERNS.md is created in docs directory @@ -98,14 +98,14 @@ Feature: CLI Behavior Testing @acceptance-criteria @happy-path Scenario: Lint passes for valid annotations - Given TypeScript files with complete @libar-docs annotations + Given TypeScript files with complete @architect annotations When running "lint-patterns -i 'src/**/*.ts'" Then exit code is 0 And output indicates "No violations found" @acceptance-criteria @validation Scenario: Lint fails for missing pattern name - Given TypeScript file with @libar-docs but no @libar-docs-pattern + Given TypeScript file with @architect but no @architect-pattern When running "lint-patterns -i 'src/**/*.ts'" Then exit code is 1 And output contains "missingPatternName" violation diff --git a/delivery-process/specs/cli-recipe-codec.feature b/architect/specs/cli-recipe-codec.feature similarity index 92% rename from delivery-process/specs/cli-recipe-codec.feature rename to architect/specs/cli-recipe-codec.feature index 5a62a1e8..c762977a 100644 --- a/delivery-process/specs/cli-recipe-codec.feature +++ b/architect/specs/cli-recipe-codec.feature @@ -1,14 +1,14 @@ -@libar-docs -@libar-docs-pattern:CliRecipeCodec -@libar-docs-status:completed -@libar-docs-unlock-reason:Initial-commit-with-all-deliverables-complete -@libar-docs-phase:35 -@libar-docs-effort:2w -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocsConsolidationStrategy -@libar-docs-depends-on:ProcessApiHybridGeneration -@libar-docs-business-value:replaces-460-lines-of-manual-PROCESS-API-md-prose-with-generated-recipe-and-narrative-content -@libar-docs-priority:medium +@architect +@architect-pattern:CliRecipeCodec +@architect-status:completed +@architect-unlock-reason:Initial-commit-with-all-deliverables-complete +@architect-phase:35 +@architect-effort:2w +@architect-product-area:Generation +@architect-depends-on:DocsConsolidationStrategy +@architect-depends-on:ProcessApiHybridGeneration +@architect-business-value:replaces-460-lines-of-manual-PROCESS-API-md-prose-with-generated-recipe-and-narrative-content +@architect-priority:medium Feature: CLI Recipe Codec **Problem:** @@ -52,7 +52,7 @@ Feature: CLI Recipe Codec | Finding | Impact | Resolution | | DD-1: Recipes need separate RecipeGroup[] field, not inline per-option | Recipes span multiple option groups (e.g., "Starting a Session" uses overview + scope-validate + context) | Added RecipeGroup[] and CommandNarrativeGroup[] as optional fields on CLISchema -- existing consumers unchanged | | DD-2: CLI_SCHEMA extension is additive with two new optional fields | ProcessApiReferenceGenerator and showHelp ignore unknown fields | recipes and commandNarratives fields added to CLISchema interface, not a separate extended type | - | DD-3: Preamble mechanism proven by ReferenceDocConfig and ErrorGuideCodec stubs | Why Use This (30 lines), Quick Start (32 lines), Session Types (12 lines) are editorial judgment | Generator accepts preamble SectionBlock[] via CliRecipeGeneratorConfig, configured in delivery-process.config.ts | + | DD-3: Preamble mechanism proven by ReferenceDocConfig and ErrorGuideCodec stubs | Why Use This (30 lines), Quick Start (32 lines), Session Types (12 lines) are editorial judgment | Generator accepts preamble SectionBlock[] via CliRecipeGeneratorConfig, configured in architect.config.ts | | DD-4: CommandNarrative type needed, not just CLIOptionGroup.description extension | Session Workflow has 6 commands each needing description + usage example + expected output | New CommandNarrative interface with command, description, usageExample, details, expectedOutput fields | | DD-5: Recipes grouped by task intent, not session type or command | Matches existing Common Recipes structure in PROCESS-API.md | 5 groups: Starting a Session, Finding Work, Investigating, Design Prep, Ending a Session | | Content audit: ~460 lines map to 3 schema locations + preamble | Zero information loss from manual to generated | recipes (42 lines), commandNarratives (287 lines), preamble (74 lines), kept in manual (70 lines) | @@ -61,17 +61,17 @@ Feature: CLI Recipe Codec **Design Stubs:** | Stub | Location | Key Decisions | - | Recipe schema types | delivery-process/stubs/cli-recipe-codec/recipe-schema.ts | DD-1 RecipeGroup/RecipeExample/RecipeStep, DD-4 CommandNarrative/CommandNarrativeGroup, CLISchema extension | - | Generator class | delivery-process/stubs/cli-recipe-codec/cli-recipe-generator.ts | DD-1 separate generator, DD-3 preamble config, DD-5 no claude-md output | - | Recipe data examples | delivery-process/stubs/cli-recipe-codec/recipe-data.ts | DD-2 schema data mapping, DD-4 narrative examples, preamble content examples | + | Recipe schema types | architect/stubs/cli-recipe-codec/recipe-schema.ts | DD-1 RecipeGroup/RecipeExample/RecipeStep, DD-4 CommandNarrative/CommandNarrativeGroup, CLISchema extension | + | Generator class | architect/stubs/cli-recipe-codec/cli-recipe-generator.ts | DD-1 separate generator, DD-3 preamble config, DD-5 no claude-md output | + | Recipe data examples | architect/stubs/cli-recipe-codec/recipe-data.ts | DD-2 schema data mapping, DD-4 narrative examples, preamble content examples | Background: Deliverables Given the following deliverables: | Deliverable | Status | Location | Tests | Test Type | | Extend CLI_SCHEMA with recipe definitions per command group | complete | src/cli/cli-schema.ts | Yes | unit | | Create CliRecipeGenerator producing PROCESS-API-RECIPES.md | complete | src/generators/built-in/cli-recipe-generator.ts | Yes | integration | - | Register generator in orchestrator config | complete | delivery-process.config.ts | Yes | integration | - | Preamble content for Why Use This and session decision tree | complete | delivery-process.config.ts | No | n/a | + | Register generator in orchestrator config | complete | architect.config.ts | Yes | integration | + | Preamble content for Why Use This and session decision tree | complete | architect.config.ts | No | n/a | | Replace PROCESS-API.md prose sections with pointers to generated files | complete | docs/PROCESS-API.md | No | n/a | | Behavior spec with scenarios for recipe generation | n/a | tests/features/behavior/cli/cli-recipe-generation.feature | Yes | acceptance | @@ -158,7 +158,7 @@ Feature: CLI Recipe Codec specifically "Why Use This" motivational prose, the Quick Start example with output, and the session type decision tree -- uses a preamble mechanism in the generator configuration. Preamble content is manually authored in - `delivery-process.config.ts` as structured section data and appears before all + `architect.config.ts` as structured section data and appears before all generated recipe content in the output file. **Rationale:** The "Why Use This" section explains the value proposition of the diff --git a/delivery-process/specs/codec-behavior-testing.feature b/architect/specs/codec-behavior-testing.feature similarity index 96% rename from delivery-process/specs/codec-behavior-testing.feature rename to architect/specs/codec-behavior-testing.feature index ece85cc6..030fed6f 100644 --- a/delivery-process/specs/codec-behavior-testing.feature +++ b/architect/specs/codec-behavior-testing.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:CodecBehaviorTesting -@libar-docs-status:roadmap -@libar-docs-phase:102 -@libar-docs-effort:5d -@libar-docs-product-area:Generation -@libar-docs-business-value:ensure-all-document-codecs-produce-correct-output -@libar-docs-priority:medium -@libar-docs-executable-specs:tests/features/behavior/codecs +@architect +@architect-pattern:CodecBehaviorTesting +@architect-status:roadmap +@architect-phase:102 +@architect-effort:5d +@architect-product-area:Generation +@architect-business-value:ensure-all-document-codecs-produce-correct-output +@architect-priority:medium +@architect-executable-specs:tests/features/behavior/codecs Feature: Codec Behavior Testing **Problem:** diff --git a/delivery-process/specs/codec-driven-reference-generation.feature b/architect/specs/codec-driven-reference-generation.feature similarity index 94% rename from delivery-process/specs/codec-driven-reference-generation.feature rename to architect/specs/codec-driven-reference-generation.feature index 720c0bd7..1cc76689 100644 --- a/delivery-process/specs/codec-driven-reference-generation.feature +++ b/architect/specs/codec-driven-reference-generation.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:CodecDrivenReferenceGeneration -@libar-docs-status:completed -@libar-docs-unlock-reason:Retroactive-spec-for-completed-work -@libar-docs-phase:27 -@libar-docs-effort:5d -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocGenerationProofOfConcept,ScopedArchitecturalView -@libar-docs-business-value:eliminates-per-document-recipe-features-with-config-driven-generation -@libar-docs-priority:high +@architect +@architect-pattern:CodecDrivenReferenceGeneration +@architect-status:completed +@architect-unlock-reason:Retroactive-spec-for-completed-work +@architect-phase:27 +@architect-effort:5d +@architect-product-area:Generation +@architect-depends-on:DocGenerationProofOfConcept,ScopedArchitecturalView +@architect-business-value:eliminates-per-document-recipe-features-with-config-driven-generation +@architect-priority:high Feature: Codec-Driven Reference Generation **Problem:** diff --git a/delivery-process/specs/config-based-workflow-definition.feature b/architect/specs/config-based-workflow-definition.feature similarity index 89% rename from delivery-process/specs/config-based-workflow-definition.feature rename to architect/specs/config-based-workflow-definition.feature index c8b91a38..99faf67d 100644 --- a/delivery-process/specs/config-based-workflow-definition.feature +++ b/architect/specs/config-based-workflow-definition.feature @@ -1,14 +1,14 @@ -@libar-docs -@libar-docs-pattern:ConfigBasedWorkflowDefinition -@libar-docs-status:completed -@libar-docs-unlock-reason:Add-missing-Invariant-Rationale-annotations -@libar-docs-phase:99 -@libar-docs-effort:2h -@libar-docs-product-area:Configuration -@libar-docs-include:reference-sample,process-workflow -@libar-docs-depends-on:MvpWorkflowImplementation -@libar-docs-business-value:eliminate-broken-workflow-loading -@libar-docs-priority:high +@architect +@architect-pattern:ConfigBasedWorkflowDefinition +@architect-status:completed +@architect-unlock-reason:Add-missing-Invariant-Rationale-annotations +@architect-phase:99 +@architect-effort:2h +@architect-product-area:Configuration +@architect-include:reference-sample,process-workflow +@architect-depends-on:MvpWorkflowImplementation +@architect-business-value:eliminate-broken-workflow-loading +@architect-priority:high Feature: Config-Based Workflow Definition **Problem:** @@ -56,8 +56,8 @@ Feature: Config-Based Workflow Definition | Update public API exports | complete | src/config/index.ts | | Remove async and try-catch in orchestrator | complete | src/generators/orchestrator.ts | | Remove async and try-catch in process-api | complete | src/cli/process-api.ts | - | Delete orphaned JSON file | n/a | delivery-process/6-phase-standard.json | - | Amend ADR-001 with phase definitions rule | complete | delivery-process/decisions/adr-001-taxonomy-canonical-values.feature | + | Delete orphaned JSON file | n/a | architect/6-phase-standard.json | + | Amend ADR-001 with phase definitions rule | complete | architect/decisions/adr-001-taxonomy-canonical-values.feature | # ============================================================================ # RULE 1: Default workflow is always available without file I/O @@ -90,7 +90,7 @@ Feature: Config-Based Workflow Definition @acceptance-criteria @happy-path Scenario: Default workflow loads without warning - Given the delivery-process package with no workflow JSON file + Given the Architect package with no workflow JSON file When the process-api runs an overview command Then no workflow warning appears in output And the overview displays progress, active phases, and blocking info @@ -157,15 +157,15 @@ Feature: Config-Based Workflow Definition **Verified by:** N/A - deferred until preset integration - Adding `workflow` as a field on `DeliveryProcessConfig` (presets) and - `DeliveryProcessProjectConfig` (project config) is a natural next step + Adding `workflow` as a field on `ArchitectConfig` (presets) and + `ArchitectProjectConfig` (project config) is a natural next step but NOT required for the MVP fix. The inline constant in `workflow-loader.ts` resolves the warning. Moving workflow into the preset/config system enables: - Different presets with different default phases (e.g., 3-phase generic) - - Per-project phase customization in delivery-process.config.ts + - Per-project phase customization in architect.config.ts - Phase definitions appearing in generated documentation See ideation artifact for design options: - delivery-process/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature + architect/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature diff --git a/delivery-process/specs/cross-cutting-document-inclusion.feature b/architect/specs/cross-cutting-document-inclusion.feature similarity index 94% rename from delivery-process/specs/cross-cutting-document-inclusion.feature rename to architect/specs/cross-cutting-document-inclusion.feature index cbb1c8d9..9ae77550 100644 --- a/delivery-process/specs/cross-cutting-document-inclusion.feature +++ b/architect/specs/cross-cutting-document-inclusion.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:CrossCuttingDocumentInclusion -@libar-docs-status:completed -@libar-docs-phase:32 -@libar-docs-effort:2d -@libar-docs-product-area:Generation -@libar-docs-depends-on:DeclarationLevelShapeTagging,ReferenceDocShowcase -@libar-docs-business-value:enables-universal-content-routing-to-any-generated-document -@libar-docs-priority:high +@architect +@architect-pattern:CrossCuttingDocumentInclusion +@architect-status:completed +@architect-phase:32 +@architect-effort:2d +@architect-product-area:Generation +@architect-depends-on:DeclarationLevelShapeTagging,ReferenceDocShowcase +@architect-business-value:enables-universal-content-routing-to-any-generated-document +@architect-priority:high Feature: Cross-Cutting Document Inclusion **Problem:** @@ -104,7 +104,7 @@ Feature: Cross-Cutting Document Inclusion | master-dataset.ts | Rename byArchView to byInclude in dataset schema | ~5 lines | | reference-generators.ts | Update built-in configs from archView to include | ~5 lines | | pattern-scanner.ts | Rename arch-view extraction to include | ~3 lines | - | delivery-process.config.ts | Update showcase config: rename archView, add includeTags | ~5 lines | + | architect.config.ts | Update showcase config: rename archView, add includeTags | ~5 lines | | Source files (~8 files) | Replace libar-docs-arch-view annotations with libar-docs-include | ~8 lines | **Integration with Existing Selectors:** @@ -139,7 +139,7 @@ Feature: Cross-Cutting Document Inclusion | Add includeTags to ReferenceDocConfig with inclusion pass | Complete | src/renderable/codecs/reference.ts | | Rename archView in dataset views and transform | Complete | src/generators/pipeline/transform-dataset.ts | | Update all source file annotations from arch-view to include | Complete | src/**/*.ts | - | Update configs: rename archView, add includeTags | Complete | delivery-process.config.ts | + | Update configs: rename archView, add includeTags | Complete | architect.config.ts | # =========================================================================== # RULE 1: Include Tag Routes Content @@ -169,10 +169,10 @@ Feature: Cross-Cutting Document Inclusion Scenario: Pattern with include tag appears in reference doc Given a pattern with tags: """ - @libar-docs - @libar-docs-pattern:MyCodec - @libar-docs-include:codec-system - @libar-docs-core + @architect + @architect-pattern:MyCodec + @architect-include:codec-system + @architect-core """ And a reference doc config with includeTags "codec-system" And behaviorCategories is empty @@ -183,9 +183,9 @@ Feature: Cross-Cutting Document Inclusion Scenario: CSV include routes pattern to multiple documents Given a pattern with tags: """ - @libar-docs - @libar-docs-pattern:SharedType - @libar-docs-include:codec-system,config-guide + @architect + @architect-pattern:SharedType + @architect-include:codec-system,config-guide """ And two reference doc configs: | Config | includeTags | @@ -286,8 +286,8 @@ Feature: Cross-Cutting Document Inclusion Given a TypeScript declaration: """typescript /** - * @libar-docs-shape - * @libar-docs-include reference-sample + * @architect-shape + * @architect-include reference-sample */ export interface CategoryDefinition { readonly tag: string; @@ -303,8 +303,8 @@ Feature: Cross-Cutting Document Inclusion Given a TypeScript declaration: """typescript /** - * @libar-docs-shape api-types - * @libar-docs-include reference-sample,codec-system + * @architect-shape api-types + * @architect-include reference-sample,codec-system */ export type SectionBlock = HeadingBlock | TableBlock; """ @@ -317,7 +317,7 @@ Feature: Cross-Cutting Document Inclusion Scenario: Shape without include but with matching group still works Given a TypeScript declaration: """typescript - /** @libar-docs-shape api-types */ + /** @architect-shape api-types */ export type RiskLevel = 'low' | 'medium' | 'high'; """ And a reference doc config with shapeSelectors group "api-types" @@ -350,9 +350,9 @@ Feature: Cross-Cutting Document Inclusion Scenario: Convention with include tag appears in reference doc Given a decision record with tags: """ - @libar-docs - @libar-docs-convention:fsm-rules - @libar-docs-include:reference-sample + @architect + @architect-convention:fsm-rules + @architect-include:reference-sample """ And a reference doc config with includeTags "reference-sample" And conventionTags is empty diff --git a/delivery-process/specs/cross-source-validation.feature b/architect/specs/cross-source-validation.feature similarity index 79% rename from delivery-process/specs/cross-source-validation.feature rename to architect/specs/cross-source-validation.feature index 7d029163..55d65b9e 100644 --- a/delivery-process/specs/cross-source-validation.feature +++ b/architect/specs/cross-source-validation.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:CrossSourceValidation -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-effort:4h -@libar-docs-product-area:Annotation -@libar-docs-business-value:detect-inconsistencies-between-typescript-and-gherkin-sources -@libar-docs-priority:high +@architect +@architect-pattern:CrossSourceValidation +@architect-status:roadmap +@architect-phase:100 +@architect-effort:4h +@architect-product-area:Annotation +@architect-business-value:detect-inconsistencies-between-typescript-and-gherkin-sources +@architect-priority:high Feature: Cross-Source Validation **Problem:** @@ -24,10 +24,10 @@ Feature: Cross-Source Validation Background: Deliverables Given the following deliverables: | Deliverable | Status | Tests | Location | - | Pattern name matcher | pending | Yes | @libar-dev/delivery-process/src/validation/ | - | Spec reference validator | pending | Yes | @libar-dev/delivery-process/src/validation/ | - | Circular dependency detector | pending | Yes | @libar-dev/delivery-process/src/validation/ | - | Orphan detector | pending | Yes | @libar-dev/delivery-process/src/validation/ | + | Pattern name matcher | pending | Yes | @libar-dev/architect/src/validation/ | + | Spec reference validator | pending | Yes | @libar-dev/architect/src/validation/ | + | Circular dependency detector | pending | Yes | @libar-dev/architect/src/validation/ | + | Orphan detector | pending | Yes | @libar-dev/architect/src/validation/ | Rule: Pattern names must be consistent across sources @@ -37,15 +37,15 @@ Feature: Cross-Source Validation @acceptance-criteria Scenario: Pattern name mismatch detected - Given TypeScript phase file with @libar-docs-pattern MyPattern - And feature file with @libar-docs-pattern:MyPatern (typo) + Given TypeScript phase file with @architect-pattern MyPattern + And feature file with @architect-pattern:MyPatern (typo) When validating pattern names Then warning suggests "Did you mean MyPattern? Found MyPatern" @acceptance-criteria Scenario: Pattern names match across sources - Given TypeScript phase file with @libar-docs-pattern SessionHandoffs - And feature file with @libar-docs-pattern:SessionHandoffs + Given TypeScript phase file with @architect-pattern SessionHandoffs + And feature file with @architect-pattern:SessionHandoffs When validating pattern names Then validation passes diff --git a/delivery-process/specs/data-api-architecture-queries.feature b/architect/specs/data-api-architecture-queries.feature similarity index 95% rename from delivery-process/specs/data-api-architecture-queries.feature rename to architect/specs/data-api-architecture-queries.feature index 65c2a9d4..a166333e 100644 --- a/delivery-process/specs/data-api-architecture-queries.feature +++ b/architect/specs/data-api-architecture-queries.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:DataAPIArchitectureQueries -@libar-docs-status:completed -@libar-docs-unlock-reason:Normalize-deliverable-status-taxonomy -@libar-docs-phase:25b -@libar-docs-product-area:DataAPI -@libar-docs-effort:2d -@libar-docs-priority:high -@libar-docs-depends-on:DataAPIOutputShaping -@libar-docs-business-value:deep-architecture-exploration-for-design-sessions +@architect +@architect-pattern:DataAPIArchitectureQueries +@architect-status:completed +@architect-unlock-reason:Normalize-deliverable-status-taxonomy +@architect-phase:25b +@architect-product-area:DataAPI +@architect-effort:2d +@architect-priority:high +@architect-depends-on:DataAPIOutputShaping +@architect-business-value:deep-architecture-exploration-for-design-sessions Feature: Data API Architecture Queries - Deep Architecture Exploration **Problem:** diff --git a/delivery-process/specs/data-api-cli-ergonomics.feature b/architect/specs/data-api-cli-ergonomics.feature similarity index 95% rename from delivery-process/specs/data-api-cli-ergonomics.feature rename to architect/specs/data-api-cli-ergonomics.feature index c0b1cdb8..90c52530 100644 --- a/delivery-process/specs/data-api-cli-ergonomics.feature +++ b/architect/specs/data-api-cli-ergonomics.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:DataAPICLIErgonomics -@libar-docs-status:completed -@libar-docs-unlock-reason:Final-deliverable-status-update -@libar-docs-phase:25d -@libar-docs-product-area:DataAPI -@libar-docs-effort:2d -@libar-docs-priority:medium -@libar-docs-business-value:fast-interactive-cli-for-repeated-queries +@architect +@architect-pattern:DataAPICLIErgonomics +@architect-status:completed +@architect-unlock-reason:Final-deliverable-status-update +@architect-phase:25d +@architect-product-area:DataAPI +@architect-effort:2d +@architect-priority:medium +@architect-business-value:fast-interactive-cli-for-repeated-queries Feature: Data API CLI Ergonomics - Performance and Interactive Mode **Problem:** diff --git a/delivery-process/specs/data-api-context-assembly.feature b/architect/specs/data-api-context-assembly.feature similarity index 96% rename from delivery-process/specs/data-api-context-assembly.feature rename to architect/specs/data-api-context-assembly.feature index 513a6825..60ed8bbf 100644 --- a/delivery-process/specs/data-api-context-assembly.feature +++ b/architect/specs/data-api-context-assembly.feature @@ -1,20 +1,20 @@ -@libar-docs -@libar-docs-pattern:DataAPIContextAssembly -@libar-docs-status:completed -@libar-docs-unlock-reason:Fix-deliverable-gate-description-preservation-tag-parsing -@libar-docs-phase:25b -@libar-docs-product-area:DataAPI -@libar-docs-effort:3d -@libar-docs-priority:high -@libar-docs-depends-on:DataAPIOutputShaping,DataAPIStubIntegration -@libar-docs-business-value:replace-explore-agents-with-one-command +@architect +@architect-pattern:DataAPIContextAssembly +@architect-status:completed +@architect-unlock-reason:Fix-deliverable-gate-description-preservation-tag-parsing +@architect-phase:25b +@architect-product-area:DataAPI +@architect-effort:3d +@architect-priority:high +@architect-depends-on:DataAPIOutputShaping,DataAPIStubIntegration +@architect-business-value:replace-explore-agents-with-one-command Feature: Data API Context Assembly - One-Command Session Context **Problem:** Starting a Claude Code design or implementation session requires assembling 30-100KB of curated, multi-source context from hundreds of annotated files. Today this requires either manual context compilation by the user or 5-10 - explore agents burning context and time. The delivery-process pipeline already + explore agents burning context and time. The Architect pipeline already has rich data (MasterDataset with archIndex, relationshipIndex, byPhase, byStatus views) but no command combines data from multiple indexes around a focal pattern into a compact, session-oriented context bundle. diff --git a/delivery-process/specs/data-api-output-shaping.feature b/architect/specs/data-api-output-shaping.feature similarity index 97% rename from delivery-process/specs/data-api-output-shaping.feature rename to architect/specs/data-api-output-shaping.feature index 2fb09a45..2aa75324 100644 --- a/delivery-process/specs/data-api-output-shaping.feature +++ b/architect/specs/data-api-output-shaping.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:DataAPIOutputShaping -@libar-docs-status:completed -@libar-docs-unlock-reason:All-8-deliverables-implemented-and-verified -@libar-docs-phase:25a -@libar-docs-product-area:DataAPI -@libar-docs-effort:4d -@libar-docs-priority:high -@libar-docs-business-value:compact-output-for-ai-agents +@architect +@architect-pattern:DataAPIOutputShaping +@architect-status:completed +@architect-unlock-reason:All-8-deliverables-implemented-and-verified +@architect-phase:25a +@architect-product-area:DataAPI +@architect-effort:4d +@architect-priority:high +@architect-business-value:compact-output-for-ai-agents Feature: Data API Output Shaping - Compact Output for AI Agents **Problem:** @@ -279,7 +279,7 @@ Feature: Data API Output Shaping - Compact Output for AI Agents @acceptance-criteria @happy-path Scenario: Config file provides default input paths - Given a delivery-process.config.ts exists with input and features paths + Given a architect.config.ts exists with input and features paths When running "process-api status" without --input or --features flags Then the pipeline uses paths from the config file And the output shows correct pattern counts diff --git a/delivery-process/specs/data-api-platform-integration.feature b/architect/specs/data-api-platform-integration.feature similarity index 95% rename from delivery-process/specs/data-api-platform-integration.feature rename to architect/specs/data-api-platform-integration.feature index ad7eefab..6fed359a 100644 --- a/delivery-process/specs/data-api-platform-integration.feature +++ b/architect/specs/data-api-platform-integration.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:DataAPIPlatformIntegration -@libar-docs-status:completed -@libar-docs-unlock-reason:Split-into-dedicated-specs -@libar-docs-phase:25d -@libar-docs-product-area:DataAPI -@libar-docs-effort:3d -@libar-docs-priority:medium -@libar-docs-business-value:native-claude-code-integration-and-monorepo-support +@architect +@architect-pattern:DataAPIPlatformIntegration +@architect-status:completed +@architect-unlock-reason:Split-into-dedicated-specs +@architect-phase:25d +@architect-product-area:DataAPI +@architect-effort:3d +@architect-priority:medium +@architect-business-value:native-claude-code-integration-and-monorepo-support Feature: Data API Platform Integration - MCP Server and Monorepo Support **Problem:** @@ -135,7 +135,7 @@ Feature: Data API Platform Integration - MCP Server and Monorepo Support @acceptance-criteria @edge-case Scenario: Context layer for bounded context with no annotations - Given a bounded context directory with no @libar-docs annotations + Given a bounded context directory with no @architect annotations When running "process-api generate-context-layer --context empty-context" Then the output indicates no patterns found in the context And the CLAUDE.md section contains a placeholder with discovery guidance @@ -210,7 +210,7 @@ Feature: Data API Platform Integration - MCP Server and Monorepo Support @acceptance-criteria @edge-case Scenario: Pre-commit on clean commit with no annotation changes - Given staged files contain no @libar-docs annotations + Given staged files contain no @architect annotations When the pre-commit hook runs Then validation passes without errors And no annotation warnings are emitted diff --git a/delivery-process/specs/data-api-relationship-graph.feature b/architect/specs/data-api-relationship-graph.feature similarity index 96% rename from delivery-process/specs/data-api-relationship-graph.feature rename to architect/specs/data-api-relationship-graph.feature index 818527f5..3ee8348a 100644 --- a/delivery-process/specs/data-api-relationship-graph.feature +++ b/architect/specs/data-api-relationship-graph.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:DataAPIRelationshipGraph -@libar-docs-status:roadmap -@libar-docs-phase:25c -@libar-docs-product-area:DataAPI -@libar-docs-effort:2d -@libar-docs-priority:medium -@libar-docs-business-value:deep-dependency-analysis-and-health-checks +@architect +@architect-pattern:DataAPIRelationshipGraph +@architect-status:roadmap +@architect-phase:25c +@architect-product-area:DataAPI +@architect-effort:2d +@architect-priority:medium +@architect-business-value:deep-dependency-analysis-and-health-checks Feature: Data API Relationship Graph - Deep Dependency Analysis **Problem:** diff --git a/delivery-process/specs/data-api-session-support.feature b/architect/specs/data-api-session-support.feature similarity index 94% rename from delivery-process/specs/data-api-session-support.feature rename to architect/specs/data-api-session-support.feature index 04018b77..f52265e8 100644 --- a/delivery-process/specs/data-api-session-support.feature +++ b/architect/specs/data-api-session-support.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:DataAPIDesignSessionSupport -@libar-docs-status:completed -@libar-docs-unlock-reason:Normalize-deliverable-status-taxonomy -@libar-docs-phase:25c -@libar-docs-product-area:DataAPI -@libar-docs-effort:1d -@libar-docs-priority:high -@libar-docs-business-value:automate-session-context-compilation -@libar-docs-depends-on:DataAPIContextAssembly,DataAPIStubIntegration +@architect +@architect-pattern:DataAPIDesignSessionSupport +@architect-status:completed +@architect-unlock-reason:Normalize-deliverable-status-taxonomy +@architect-phase:25c +@architect-product-area:DataAPI +@architect-effort:1d +@architect-priority:high +@architect-business-value:automate-session-context-compilation +@architect-depends-on:DataAPIContextAssembly,DataAPIStubIntegration Feature: Data API Design Session Support - Automated Session Workflows **Problem:** diff --git a/delivery-process/specs/data-api-stub-integration.feature b/architect/specs/data-api-stub-integration.feature similarity index 85% rename from delivery-process/specs/data-api-stub-integration.feature rename to architect/specs/data-api-stub-integration.feature index 5b4507f0..fc13db4e 100644 --- a/delivery-process/specs/data-api-stub-integration.feature +++ b/architect/specs/data-api-stub-integration.feature @@ -1,16 +1,16 @@ -@libar-docs -@libar-docs-pattern:DataAPIStubIntegration -@libar-docs-status:completed -@libar-docs-unlock-reason:Implementation-complete-all-deliverables-done -@libar-docs-phase:25a -@libar-docs-product-area:DataAPI -@libar-docs-effort:2d -@libar-docs-priority:high -@libar-docs-business-value:unlock-design-session-stub-metadata +@architect +@architect-pattern:DataAPIStubIntegration +@architect-status:completed +@architect-unlock-reason:Implementation-complete-all-deliverables-done +@architect-phase:25a +@architect-product-area:DataAPI +@architect-effort:2d +@architect-priority:high +@architect-business-value:unlock-design-session-stub-metadata Feature: Data API Stub Integration - Unlocking Design Session Data **Problem:** - Design sessions produce code stubs in `delivery-process/stubs/` with rich + Design sessions produce code stubs in `architect/stubs/` with rich metadata: `@target` (destination file path), `@since` (design session ID), `@see` (PDR references), and `AD-N` numbered decisions. But 14 of 22 stubs lack the libar-docs opt-in marker, making them invisible to the scanner pipeline. @@ -57,18 +57,18 @@ Feature: Data API Stub Integration - Unlocking Design Session Data Rule: All stubs are visible to the scanner pipeline - **Invariant:** Every stub file in `delivery-process/stubs/` has `@libar-docs` - opt-in and `@libar-docs-implements` linking it to its parent pattern. + **Invariant:** Every stub file in `architect/stubs/` has `@architect` + opt-in and `@architect-implements` linking it to its parent pattern. - **Rationale:** The scanner requires `@libar-docs` opt-in marker to include a + **Rationale:** The scanner requires `@architect` opt-in marker to include a file. Without it, stubs are invisible regardless of other annotations. The - `@libar-docs-implements` tag creates the bidirectional link: spec defines the - pattern (via `@libar-docs-pattern`), stub implements it. Per PDR-009, stubs - must NOT use `@libar-docs-pattern` -- that belongs to the feature file. + `@architect-implements` tag creates the bidirectional link: spec defines the + pattern (via `@architect-pattern`), stub implements it. Per PDR-009, stubs + must NOT use `@architect-pattern` -- that belongs to the feature file. **Boundary note:** Phase A (annotating stubs with libar-docs opt-in and libar-docs-implements tags) is consumer-side work done in each consuming repo. - Package.json scan paths (`-i 'delivery-process/stubs/**/*.ts'`) are already + Package.json scan paths (`-i 'architect/stubs/**/*.ts'`) are already pre-configured in 15 scripts. This spec covers Phase B: taxonomy tag registration (libar-docs-target, libar-docs-since) and CLI query subcommands. @@ -76,21 +76,21 @@ Feature: Data API Stub Integration - Unlocking Design Session Data @acceptance-criteria @happy-path Scenario: Annotated stubs are discoverable by the scanner - Given stub files with @libar-docs and @libar-docs-implements tags + Given stub files with @architect and @architect-implements tags When running the scanner pipeline with stubs input glob Then all annotated stubs appear in the MasterDataset And each stub has an implementsPatterns relationship @acceptance-criteria @happy-path Scenario: Stub target path is extracted as structured field - Given a stub with "@libar-docs-target:platform-core/src/agent/router.ts" + Given a stub with "@architect-target:platform-core/src/agent/router.ts" When the stub is scanned and extracted Then the pattern's targetPath field contains "platform-core/src/agent/router.ts" And the targetPath is available via ProcessStateAPI queries @acceptance-criteria @validation Scenario: Stub without libar-docs opt-in is invisible to scanner - Given a stub file without the @libar-docs marker + Given a stub file without the @architect marker When running the scanner pipeline with stubs input glob Then the stub does NOT appear in the MasterDataset And no error is raised for the missing marker @@ -107,15 +107,15 @@ Feature: Data API Stub Integration - Unlocking Design Session Data **Rationale:** Before implementation, agents need to know: which stubs exist for a pattern, where they should be moved to, and which have already been implemented. The stub-to-implementation resolver compares - `@libar-docs-target` paths against actual files to determine status. + `@architect-target` paths against actual files to determine status. **Output per stub:** | Field | Source | | Stub file | Pattern filePath | - | Target | @libar-docs-target value | + | Target | @architect-target value | | Implemented? | Target file exists? | - | Since | @libar-docs-since (design session ID) | - | Pattern | @libar-docs-implements value | + | Since | @architect-since (design session ID) | + | Pattern | @architect-implements value | **Verified by:** List all stubs, List stubs for pattern, Filter unresolved diff --git a/delivery-process/specs/declaration-level-shape-tagging.feature b/architect/specs/declaration-level-shape-tagging.feature similarity index 95% rename from delivery-process/specs/declaration-level-shape-tagging.feature rename to architect/specs/declaration-level-shape-tagging.feature index dad73f79..407ce754 100644 --- a/delivery-process/specs/declaration-level-shape-tagging.feature +++ b/architect/specs/declaration-level-shape-tagging.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:DeclarationLevelShapeTagging -@libar-docs-status:completed -@libar-docs-phase:31 -@libar-docs-effort:3d -@libar-docs-product-area:Annotation -@libar-docs-depends-on:ShapeExtraction,ReferenceDocShowcase -@libar-docs-business-value:enables-focused-shape-extraction-without-whole-file-dumping -@libar-docs-priority:high +@architect +@architect-pattern:DeclarationLevelShapeTagging +@architect-status:completed +@architect-phase:31 +@architect-effort:3d +@architect-product-area:Annotation +@architect-depends-on:ShapeExtraction,ReferenceDocShowcase +@architect-business-value:enables-focused-shape-extraction-without-whole-file-dumping +@architect-priority:high Feature: Declaration-Level Shape Tagging **Problem:** @@ -120,7 +120,7 @@ Feature: Declaration-Level Shape Tagging | doc-extractor.ts | Call discoverTaggedShapes() alongside processExtractShapesTag() | ~15 lines | | reference.ts | Add ShapeSelectorSchema + shapeSelectors to ReferenceDocConfig | ~20 lines | | shape-matcher.ts | Add filterShapesBySelectors() function | ~30 lines | - | delivery-process.config.ts | Update showcase config to use shapeSelectors | ~5 lines | + | architect.config.ts | Update showcase config to use shapeSelectors | ~5 lines | **Integration Wiring (doc-extractor.ts):** The existing shape extraction at doc-extractor.ts lines 167-178 handles @@ -159,7 +159,7 @@ Feature: Declaration-Level Shape Tagging | Wire tagged discovery into doc extractor | Complete | src/extractor/doc-extractor.ts | | ShapeSelector schema and shapeSelectors on ReferenceDocConfig | Complete | src/renderable/codecs/reference.ts | | Selector-based filtering in shape matcher | Complete | src/renderable/codecs/shape-matcher.ts | - | Showcase config using declaration-level shapes | Complete | delivery-process.config.ts | + | Showcase config using declaration-level shapes | Complete | architect.config.ts | Rule: Declarations opt in via libar-docs-shape tag @@ -186,7 +186,7 @@ Feature: Declaration-Level Shape Tagging Scenario: Tagged declaration is extracted as shape Given a TypeScript source file containing: """typescript - /** @libar-docs-shape */ + /** @architect-shape */ export interface RiskLevel { readonly name: string; readonly severity: number; @@ -214,7 +214,7 @@ Feature: Declaration-Level Shape Tagging Scenario: Group name is captured from tag value Given a TypeScript source file containing: """typescript - /** @libar-docs-shape api-types */ + /** @architect-shape api-types */ export type RiskLevel = 'low' | 'medium' | 'high' | 'critical'; """ When discoverTaggedShapes runs on the source @@ -225,7 +225,7 @@ Feature: Declaration-Level Shape Tagging Scenario: Bare tag works without group name Given a TypeScript source file containing: """typescript - /** @libar-docs-shape */ + /** @architect-shape */ export enum Priority { Low, Medium, High } """ When discoverTaggedShapes runs on the source @@ -236,7 +236,7 @@ Feature: Declaration-Level Shape Tagging Scenario: Non-exported tagged declaration is extracted Given a TypeScript source file containing: """typescript - /** @libar-docs-shape internal-types */ + /** @architect-shape internal-types */ interface InternalConfig { readonly maxRetries: number; } @@ -346,23 +346,23 @@ Feature: Declaration-Level Shape Tagging Scenario: All five declaration kinds are discoverable Given a TypeScript source file containing: """typescript - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export interface Config { readonly name: string; } - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export type Status = 'active' | 'inactive'; - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export enum Priority { Low, Medium, High } - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export function validate(input: string): boolean { return input.length > 0; } - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export const MAX_RETRIES: number = 3; """ When discoverTaggedShapes runs on the source @@ -374,7 +374,7 @@ Feature: Declaration-Level Shape Tagging Scenario: JSDoc with gap larger than MAX_JSDOC_LINE_DISTANCE is not matched Given a TypeScript source file containing: """typescript - /** @libar-docs-shape */ + /** @architect-shape */ // unrelated comment @@ -394,7 +394,7 @@ Feature: Declaration-Level Shape Tagging /** * Represents risk severity levels. * - * @libar-docs-shape risk-types + * @architect-shape risk-types * @see RiskCalculator */ export type RiskLevel = 'low' | 'medium' | 'high' | 'critical'; diff --git a/delivery-process/specs/design-review-generation.feature b/architect/specs/design-review-generation.feature similarity index 94% rename from delivery-process/specs/design-review-generation.feature rename to architect/specs/design-review-generation.feature index d4048854..21a688fc 100644 --- a/delivery-process/specs/design-review-generation.feature +++ b/architect/specs/design-review-generation.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:DesignReviewGeneration -@libar-docs-status:active -@libar-docs-phase:46 -@libar-docs-product-area:Generation -@libar-docs-effort:2d -@libar-docs-priority:high -@libar-docs-depends-on:MermaidDiagramUtils +@architect +@architect-pattern:DesignReviewGeneration +@architect-status:active +@architect-phase:46 +@architect-product-area:Generation +@architect-effort:2d +@architect-priority:high +@architect-depends-on:MermaidDiagramUtils Feature: Design Review Diagram Generation **Problem:** @@ -21,7 +21,7 @@ Feature: Design Review Diagram Generation diagrams. The pipeline fits into the existing codec/generator architecture: sequence data is pre-computed in a SequenceIndex view on MasterDataset, then a standalone DesignReviewCodec renders the diagrams and supporting tables. Output goes to - delivery-process/design-reviews/. + architect/design-reviews/. Background: Deliverables Given the following deliverables: @@ -33,7 +33,7 @@ Feature: Design Review Diagram Generation | DesignReviewCodec | complete | src/renderable/codecs/design-review.ts | | Design review generator | complete | src/generators/built-in/design-review-generator.ts | | Process API sequence subcommand | complete | src/cli/process-api.ts | - | Config wiring | complete | delivery-process.config.ts | + | Config wiring | complete | architect.config.ts | Rule: SequenceIndex pre-computes ordered steps from rule-level tags diff --git a/delivery-process/specs/doc-generation-proof-of-concept.feature b/architect/specs/doc-generation-proof-of-concept.feature similarity index 93% rename from delivery-process/specs/doc-generation-proof-of-concept.feature rename to architect/specs/doc-generation-proof-of-concept.feature index ac2b8679..db554365 100644 --- a/delivery-process/specs/doc-generation-proof-of-concept.feature +++ b/architect/specs/doc-generation-proof-of-concept.feature @@ -1,20 +1,20 @@ -@libar-docs -@libar-docs-adr:021 -@libar-docs-adr-status:superseded -@libar-docs-adr-category:documentation -@libar-docs-pattern:DocGenerationProofOfConcept -@libar-docs-status:completed -@libar-docs-unlock-reason:Fix-code-fence-formatting-per-PR-review -@libar-docs-phase:27 -@libar-docs-effort:2d -@libar-docs-product-area:Generation -@libar-docs-depends-on:ShapeExtraction -@libar-docs-business-value:eliminates-manual-documentation-maintenance -@libar-docs-priority:high +@architect +@architect-adr:021 +@architect-adr-status:superseded +@architect-adr-category:documentation +@architect-pattern:DocGenerationProofOfConcept +@architect-status:completed +@architect-unlock-reason:Fix-code-fence-formatting-per-PR-review +@architect-phase:27 +@architect-effort:2d +@architect-product-area:Generation +@architect-depends-on:ShapeExtraction +@architect-business-value:eliminates-manual-documentation-maintenance +@architect-priority:high Feature: ADR-021 - Documentation Generation from Annotated Sources **Status: SUPERSEDED** - This POC has been implemented. See: - - Convention-tagged decision records (ADR/PDR) with @libar-docs-convention tags + - Convention-tagged decision records (ADR/PDR) with @architect-convention tags - `docs-generated/ANNOTATION-GUIDE.md` - Comprehensive guide for fixing generated docs This decision establishes the pattern for generating technical documentation @@ -58,7 +58,7 @@ Feature: ADR-021 - Documentation Generation from Annotated Sources **What We Have:** - The delivery-process package already has the required ingredients: + The Architect package already has the required ingredients: - Pattern extraction from TypeScript JSDoc and Gherkin tags - Rich content support (DocStrings, tables, code blocks in features) - Multi-source aggregation via tag taxonomy @@ -177,8 +177,8 @@ Feature: ADR-021 - Documentation Generation from Annotated Sources | Intro & Context | THIS DECISION (Rule: Context above) | Decision rule description | | How It Works | THIS DECISION (Rule: Decision above) | Decision rule description | | Validation Rules | tests/features/validation/process-guard.feature | Rule blocks | - | Protection Levels | delivery-process/specs/process-guard-linter.feature | Scenario Outline Examples | - | Valid Transitions | delivery-process/specs/process-guard-linter.feature | Scenario Outline Examples | + | Protection Levels | architect/specs/process-guard-linter.feature | Scenario Outline Examples | + | Valid Transitions | architect/specs/process-guard-linter.feature | Scenario Outline Examples | | API Types | src/lint/process-guard/types.ts | @extract-shapes tag | | Decider API | src/lint/process-guard/decider.ts | @extract-shapes tag | | CLI Options | src/cli/lint-process.ts | JSDoc section | @@ -214,7 +214,7 @@ Feature: ADR-021 - Documentation Generation from Annotated Sources validateChanges, hasErrors, summarizeResult, - } from '@libar-dev/delivery-process/lint'; + } from '@libar-dev/architect/lint'; // 1. Derive state from annotations const state = (await deriveProcessState({ baseDir: '.' })).value; @@ -239,7 +239,7 @@ Feature: ADR-021 - Documentation Generation from Annotated Sources **Escape Hatches:** | Situation | Solution | Example | - | Fix bug in completed spec | Add unlock reason tag | `@libar-docs-unlock-reason:'Fix-typo'` | + | Fix bug in completed spec | Add unlock reason tag | `@architect-unlock-reason:'Fix-typo'` | | Modify outside session scope | Use ignore flag | `lint-process --staged --ignore-session` | | CI treats warnings as errors | Use strict flag | `lint-process --all --strict` | | Skip workflow (legacy import) | Multiple transitions | Set roadmap then completed in same commit | @@ -317,7 +317,7 @@ Feature: ADR-021 - Documentation Generation from Annotated Sources Rule: Consequences - Design stubs live in stubs, not src - **Invariant:** Pre-implementation design stubs must reside in `delivery-process/stubs/`, never in `src/`. + **Invariant:** Pre-implementation design stubs must reside in `architect/stubs/`, never in `src/`. **Rationale:** Stubs in `src/` require ESLint exceptions, create confusion between production and design code, and risk accidental imports of unimplemented functions. **Verified by:** N/A - architectural constraint verified by code structure, not runtime scenario @@ -350,20 +350,20 @@ Feature: ADR-021 - Documentation Generation from Annotated Sources **The Solution:** - Design stubs live in `delivery-process/stubs/`: + Design stubs live in `architect/stubs/`: | Location | Content | When Moved to src/ | - | delivery-process/stubs/{pattern}/*.ts | API shapes, interfaces, throw-not-implemented | Implementation session | + | architect/stubs/{pattern}/*.ts | API shapes, interfaces, throw-not-implemented | Implementation session | | src/**/*.ts | Production code only | Already there | **Design Stub Pattern:** """typescript - // delivery-process/stubs/shape-extractor/shape-extractor.ts + // architect/stubs/shape-extractor/shape-extractor.ts /** - * @libar-docs - * @libar-docs-pattern ShapeExtractorStub - * @libar-docs-status roadmap + * @architect + * @architect-pattern ShapeExtractorStub + * @architect-status roadmap * * ## Shape Extractor - Design Stub * @@ -388,14 +388,14 @@ Feature: ADR-021 - Documentation Generation from Annotated Sources | Benefit | How | | No ESLint exceptions | Stubs aren't in src/, no relaxation needed | - | Clear separation | delivery-process/stubs/ = design, src/ = production | + | Clear separation | architect/stubs/ = design, src/ = production | | Documentation source | Stubs with @extract-shapes generate API docs | | Safe iteration | Can refine stub APIs without breaking anything | - | Implementation signal | Moving from delivery-process/stubs/ to src/ = implementation started | + | Implementation signal | Moving from architect/stubs/ to src/ = implementation started | **Workflow:** - 1. **Design session:** Create stub in `delivery-process/stubs/{pattern-name}/` + 1. **Design session:** Create stub in `architect/stubs/{pattern-name}/` 2. **Iterate:** Refine API shapes, add JSDoc, test with docs generation 3. **Implementation session:** Move/copy to `src/`, implement real logic 4. **Stub becomes example:** Original stub stays as reference (optional) @@ -441,7 +441,7 @@ Feature: ADR-021 - Documentation Generation from Annotated Sources | Extraction Method | Source Type | Action | | Decision rule description | Decision (.feature) | Extract Rule: block content (Invariant, Rationale) | - | @extract-shapes tag | TypeScript (.ts) | Invoke shape extractor for @libar-docs-extract-shapes | + | @extract-shapes tag | TypeScript (.ts) | Invoke shape extractor for @architect-extract-shapes | | Rule blocks | Behavior spec (.feature) | Extract Rule: names and descriptions | | Scenario Outline Examples | Behavior spec (.feature) | Extract Examples tables as markdown | | JSDoc section | TypeScript (.ts) | Extract markdown from JSDoc comments | diff --git a/delivery-process/specs/docs-consolidation-strategy.feature b/architect/specs/docs-consolidation-strategy.feature similarity index 91% rename from delivery-process/specs/docs-consolidation-strategy.feature rename to architect/specs/docs-consolidation-strategy.feature index f3e5c65d..d36ad18d 100644 --- a/delivery-process/specs/docs-consolidation-strategy.feature +++ b/architect/specs/docs-consolidation-strategy.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:DocsConsolidationStrategy -@libar-docs-status:completed -@libar-docs-unlock-reason:Retroactive-completion -@libar-docs-phase:35 -@libar-docs-effort:4w -@libar-docs-product-area:Generation -@libar-docs-depends-on:CodecDrivenReferenceGeneration -@libar-docs-business-value:right-size-all-14-manual-docs-via-generation-relocation-and-audience-alignment -@libar-docs-priority:high +@architect +@architect-pattern:DocsConsolidationStrategy +@architect-status:completed +@architect-unlock-reason:Retroactive-completion +@architect-phase:35 +@architect-effort:4w +@architect-product-area:Generation +@architect-depends-on:CodecDrivenReferenceGeneration +@architect-business-value:right-size-all-14-manual-docs-via-generation-relocation-and-audience-alignment +@architect-priority:high Feature: Documentation Consolidation Strategy **Problem:** @@ -52,27 +52,27 @@ Feature: Documentation Consolidation Strategy | Deliverable | Status | Location | Tests | Test Type | | Preamble capability on ReferenceDocConfig | complete | src/renderable/codecs/reference.ts | Yes | unit | | Phase 1 - Taxonomy consolidation | complete | docs/TAXONOMY.md | No | n/a | - | Phase 2 - Codec listings extraction | complete | delivery-process.config.ts, src/renderable/codecs/*.ts | Yes | integration | + | Phase 2 - Codec listings extraction | complete | architect.config.ts, src/renderable/codecs/*.ts | Yes | integration | | Phase 3 - Process Guard consolidation | complete | src/renderable/codecs/validation-rules.ts | Yes | integration | | Phase 4 - Architecture decomposition | complete | docs/ARCHITECTURE.md | Yes | integration | | Phase 5 - Guide trimming | complete | docs/ANNOTATION-GUIDE.md, docs/CONFIGURATION.md | No | n/a | | Phase 6 - Index navigation update | complete | docs-live/INDEX.md, docs/INDEX.md | No | n/a | - | Phase 37 - docs-live/ directory consolidation | complete | delivery-process.config.ts | Yes | integration | + | Phase 37 - docs-live/ directory consolidation | complete | architect.config.ts | Yes | integration | | Phase 38 - Generated doc quality improvements | complete | src/renderable/codecs/reference.ts | Yes | integration | - | Phase 39 - Session workflow CLAUDE.md module generation | complete | delivery-process/specs/, _claude-md/workflow/ | No | n/a | + | Phase 39 - Session workflow CLAUDE.md module generation | complete | architect/specs/, _claude-md/workflow/ | No | n/a | | Phase 40 - PUBLISHING.md relocation to MAINTAINERS.md | complete | docs/PUBLISHING.md | No | n/a | | Phase 41 - GHERKIN-PATTERNS.md restructure | complete | docs/GHERKIN-PATTERNS.md, docs/VALIDATION.md | No | n/a | | Phase 42 - README.md rationalization | complete | README.md | No | n/a | | Phase 43 - PROCESS-API.md hybrid generation | complete | docs/PROCESS-API.md, src/cli/ | Yes | integration | - | Promote architecture generator from preview to docs:all | complete | package.json, delivery-process.config.ts | No | n/a | - | Promote changelog generator from preview to docs:all | complete | package.json, delivery-process.config.ts | No | n/a | + | Promote architecture generator from preview to docs:all | complete | package.json, architect.config.ts | No | n/a | + | Promote changelog generator from preview to docs:all | complete | package.json, architect.config.ts | No | n/a | Rule: Convention tags are the primary consolidation mechanism **Invariant:** Each consolidation phase follows the same pattern: register a convention tag value in `src/taxonomy/conventions.ts`, annotate source files with - `@libar-docs-convention` tags using structured JSDoc, add a `ReferenceDocConfig` - entry in `delivery-process.config.ts`, and replace the manual doc section with a + `@architect-convention` tags using structured JSDoc, add a `ReferenceDocConfig` + entry in `architect.config.ts`, and replace the manual doc section with a pointer to the generated reference document. **Rationale:** Convention-tagged annotations are the only sustainable way to keep diff --git a/delivery-process/specs/docs-live-consolidation.feature b/architect/specs/docs-live-consolidation.feature similarity index 87% rename from delivery-process/specs/docs-live-consolidation.feature rename to architect/specs/docs-live-consolidation.feature index 27f8aed1..209b404e 100644 --- a/delivery-process/specs/docs-live-consolidation.feature +++ b/architect/specs/docs-live-consolidation.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:DocsLiveConsolidation -@libar-docs-status:completed -@libar-docs-phase:37 -@libar-docs-effort:0.5d -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocsConsolidationStrategy -@libar-docs-business-value:single-output-directory-for-all-website-published-and-claude-readable-content -@libar-docs-priority:high -@libar-docs-unlock-reason:Move-business-rules-taxonomy-to-docs-live +@architect +@architect-pattern:DocsLiveConsolidation +@architect-status:completed +@architect-phase:37 +@architect-effort:0.5d +@architect-product-area:Generation +@architect-depends-on:DocsConsolidationStrategy +@architect-business-value:single-output-directory-for-all-website-published-and-claude-readable-content +@architect-priority:high +@architect-unlock-reason:Move-business-rules-taxonomy-to-docs-live Feature: Docs Live Directory Consolidation **Problem:** @@ -22,7 +22,7 @@ Feature: Docs Live Directory Consolidation Establish `docs-live/` as the single output directory for all website-published and Claude-readable content. Move reference docs to `docs-live/reference/` and architecture compact files to `docs-live/_claude-md/architecture/` by updating - output directory configs in `delivery-process.config.ts`. + output directory configs in `architect.config.ts`. After consolidation, `docs-generated/` contains no production artifacts — all generated reference content lives in `docs-live/`. **Why It Matters:** @@ -34,9 +34,9 @@ Feature: Docs Live Directory Consolidation Background: Deliverables Given the following deliverables: | Deliverable | Status | Location | Tests | Test Type | - | Reference docs output → docs-live/reference/ | complete | delivery-process.config.ts | Yes | integration | - | Architecture _claude-md/ → docs-live/_claude-md/architecture/ | complete | delivery-process.config.ts | Yes | integration | - | Remove root-level compact duplicates from docs-generated/ | complete | delivery-process.config.ts | No | n/a | + | Reference docs output → docs-live/reference/ | complete | architect.config.ts | Yes | integration | + | Architecture _claude-md/ → docs-live/_claude-md/architecture/ | complete | architect.config.ts | Yes | integration | + | Remove root-level compact duplicates from docs-generated/ | complete | architect.config.ts | No | n/a | | Update .gitignore: docs-generated/ ignored, docs-live/ committed | complete | .gitignore | No | n/a | Rule: docs-live/ is the single directory for website-published content diff --git a/delivery-process/specs/dod-validation.feature b/architect/specs/dod-validation.feature similarity index 88% rename from delivery-process/specs/dod-validation.feature rename to architect/specs/dod-validation.feature index 52dbef04..ec3db0dd 100644 --- a/delivery-process/specs/dod-validation.feature +++ b/architect/specs/dod-validation.feature @@ -1,12 +1,12 @@ @opportunity-2 -@libar-docs -@libar-docs-pattern:DoDValidation -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-effort:3d -@libar-docs-product-area:Validation -@libar-docs-business-value:enable-machine-checkable-phase-completion -@libar-docs-priority:high +@architect +@architect-pattern:DoDValidation +@architect-status:roadmap +@architect-phase:100 +@architect-effort:3d +@architect-product-area:Validation +@architect-business-value:enable-machine-checkable-phase-completion +@architect-priority:high Feature: DoD Validation CLI - Machine-Checkable Definition of Done **Problem:** diff --git a/delivery-process/specs/effort-variance-tracking.feature b/architect/specs/effort-variance-tracking.feature similarity index 82% rename from delivery-process/specs/effort-variance-tracking.feature rename to architect/specs/effort-variance-tracking.feature index 82801f4d..494a6912 100644 --- a/delivery-process/specs/effort-variance-tracking.feature +++ b/architect/specs/effort-variance-tracking.feature @@ -1,14 +1,14 @@ @opportunity-3 -@libar-docs -@libar-docs-pattern:EffortVarianceTracking -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-effort:2d -@libar-docs-product-area:Process -@libar-docs-include:process-workflow -@libar-docs-depends-on:MvpWorkflowImplementation -@libar-docs-business-value:track-planned-vs-actual-effort-variance -@libar-docs-priority:medium +@architect +@architect-pattern:EffortVarianceTracking +@architect-status:roadmap +@architect-phase:100 +@architect-effort:2d +@architect-product-area:Process +@architect-include:process-workflow +@architect-depends-on:MvpWorkflowImplementation +@architect-business-value:track-planned-vs-actual-effort-variance +@architect-priority:medium Feature: Effort Variance Tracking - Improve Estimates Over Time **Problem:** diff --git a/delivery-process/specs/enhanced-index-generation.feature b/architect/specs/enhanced-index-generation.feature similarity index 93% rename from delivery-process/specs/enhanced-index-generation.feature rename to architect/specs/enhanced-index-generation.feature index dc344691..cbb30feb 100644 --- a/delivery-process/specs/enhanced-index-generation.feature +++ b/architect/specs/enhanced-index-generation.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:EnhancedIndexGeneration -@libar-docs-status:completed -@libar-docs-unlock-reason:WP-2-implementation-complete -@libar-docs-phase:35 -@libar-docs-effort:2w -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocsConsolidationStrategy -@libar-docs-business-value:replaces-354-line-manual-INDEX-md-with-auto-generated-navigation-hub-combining-statistics-and-editorial-reading-paths -@libar-docs-priority:medium +@architect +@architect-pattern:EnhancedIndexGeneration +@architect-status:completed +@architect-unlock-reason:WP-2-implementation-complete +@architect-phase:35 +@architect-effort:2w +@architect-product-area:Generation +@architect-depends-on:DocsConsolidationStrategy +@architect-business-value:replaces-354-line-manual-INDEX-md-with-auto-generated-navigation-hub-combining-statistics-and-editorial-reading-paths +@architect-priority:medium Feature: Enhanced Index Generation **Problem:** @@ -68,9 +68,9 @@ Feature: Enhanced Index Generation **Design Stubs:** | Stub | Location | Purpose | - | index-codec-options.ts | delivery-process/stubs/enhanced-index-generation/index-codec-options.ts | IndexCodecOptions interface, DocumentEntry type, section visibility toggles, DD-1 and DD-5 rationale | - | index-codec.ts | delivery-process/stubs/enhanced-index-generation/index-codec.ts | createIndexCodec() factory, buildIndexDocument pipeline, section builder signatures, DD-1 rationale | - | index-preamble-config.ts | delivery-process/stubs/enhanced-index-generation/index-preamble-config.ts | Example preamble SectionBlock arrays, document entries, DD-2 DD-3 DD-4 rationale | + | index-codec-options.ts | architect/stubs/enhanced-index-generation/index-codec-options.ts | IndexCodecOptions interface, DocumentEntry type, section visibility toggles, DD-1 and DD-5 rationale | + | index-codec.ts | architect/stubs/enhanced-index-generation/index-codec.ts | createIndexCodec() factory, buildIndexDocument pipeline, section builder signatures, DD-1 rationale | + | index-preamble-config.ts | architect/stubs/enhanced-index-generation/index-preamble-config.ts | Example preamble SectionBlock arrays, document entries, DD-2 DD-3 DD-4 rationale | Background: Deliverables Given the following deliverables: @@ -78,7 +78,7 @@ Feature: Enhanced Index Generation | Create IndexCodec with MasterDataset-driven statistics | complete | src/renderable/codecs/index-codec.ts | Yes | unit | | Register IndexCodec in codec registry and generator config | complete | src/renderable/generate.ts | Yes | integration | | Preamble content for audience paths, document roles, quick finder | complete | docs-sources/index-navigation.md | No | n/a | - | CodecOptions entry for enhanced INDEX.md | complete | delivery-process.config.ts | Yes | integration | + | CodecOptions entry for enhanced INDEX.md | complete | architect.config.ts | Yes | integration | | Replace docs/INDEX.md with pointer to generated output | complete | docs/INDEX.md | No | n/a | | Behavior spec with scenarios for index generation | superseded | n/a | No | n/a | diff --git a/delivery-process/specs/error-guide-codec.feature b/architect/specs/error-guide-codec.feature similarity index 92% rename from delivery-process/specs/error-guide-codec.feature rename to architect/specs/error-guide-codec.feature index 52c5898c..b0966cab 100644 --- a/delivery-process/specs/error-guide-codec.feature +++ b/architect/specs/error-guide-codec.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:ErrorGuideCodec -@libar-docs-status:completed -@libar-docs-unlock-reason:Initial-commit-with-all-deliverables-complete -@libar-docs-phase:35 -@libar-docs-effort:2w -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocsConsolidationStrategy -@libar-docs-business-value:replaces-341-line-manual-PROCESS-GUARD-md-with-auto-generated-error-diagnosis-guides -@libar-docs-priority:medium +@architect +@architect-pattern:ErrorGuideCodec +@architect-status:completed +@architect-unlock-reason:Initial-commit-with-all-deliverables-complete +@architect-phase:35 +@architect-effort:2w +@architect-product-area:Generation +@architect-depends-on:DocsConsolidationStrategy +@architect-business-value:replaces-341-line-manual-PROCESS-GUARD-md-with-auto-generated-error-diagnosis-guides +@architect-priority:medium Feature: Error Guide Codec **Problem:** @@ -65,9 +65,9 @@ Feature: Error Guide Codec **Design Stubs:** | Stub | Location | Purpose | - | enhanced-validation-options.ts | delivery-process/stubs/error-guide-codec/ | DD-1: Extended ValidationRulesCodecOptions with includeErrorGuide toggle and EnhancedRuleDefinition interface | - | error-guide-config.ts | delivery-process/stubs/error-guide-codec/ | DD-2/DD-4: ReferenceDocConfig entry with preamble SectionBlocks and convention tag registration | - | convention-annotation-example.ts | delivery-process/stubs/error-guide-codec/ | DD-3: Example convention annotation format for all 6 error rules on decider.ts | + | enhanced-validation-options.ts | architect/stubs/error-guide-codec/ | DD-1: Extended ValidationRulesCodecOptions with includeErrorGuide toggle and EnhancedRuleDefinition interface | + | error-guide-config.ts | architect/stubs/error-guide-codec/ | DD-2/DD-4: ReferenceDocConfig entry with preamble SectionBlocks and convention tag registration | + | convention-annotation-example.ts | architect/stubs/error-guide-codec/ | DD-3: Example convention annotation format for all 6 error rules on decider.ts | Background: Deliverables Given the following deliverables: @@ -75,8 +75,8 @@ Feature: Error Guide Codec | Register process-guard-errors convention tag value | complete | src/taxonomy/conventions.ts | Yes | unit | | Annotate error-handling source files with convention tags | complete | src/lint/process-guard/decider.ts | No | n/a | | Add ValidationRulesCodecOptions toggles for error guide sections | complete | src/renderable/codecs/validation-rules.ts | Yes | unit | - | ReferenceDocConfig entry for PROCESS-GUARD generated reference | complete | delivery-process.config.ts | Yes | integration | - | Preamble content for Husky/CI setup and programmatic API | complete | delivery-process.config.ts | Yes | integration | + | ReferenceDocConfig entry for PROCESS-GUARD generated reference | complete | architect.config.ts | Yes | integration | + | Preamble content for Husky/CI setup and programmatic API | complete | architect.config.ts | Yes | integration | | Replace PROCESS-GUARD.md reference sections with pointer to generated output | complete | docs/PROCESS-GUARD.md | No | n/a | | Behavior spec with scenarios for error guide generation | n/a | tests/features/generation/error-guide-codec.feature | Yes | acceptance | @@ -117,7 +117,7 @@ Feature: Error Guide Codec **Invariant:** Every error code in the generated output includes not just a fix command but a "why this rule exists" rationale. The rationale is sourced from - `@libar-docs-convention:process-guard-errors` JSDoc annotations on the error-handling + `@architect-convention:process-guard-errors` JSDoc annotations on the error-handling code in `src/lint/process-guard/`. The `RuleDefinition` interface is extended with a `rationale` field, or rationale is composed from convention-extracted content. @@ -186,7 +186,7 @@ Feature: Error Guide Codec Rule: Convention tags source error context from annotated lint code **Invariant:** Error-handling code in `src/lint/process-guard/` is annotated with - `@libar-docs-convention:process-guard-errors` using structured JSDoc that includes + `@architect-convention:process-guard-errors` using structured JSDoc that includes rationale, alternative approaches, and common mistake patterns. The convention tag value `process-guard-errors` is registered in `src/taxonomy/conventions.ts` in the `CONVENTION_VALUES` array. The `createReferenceCodec` factory extracts this content diff --git a/delivery-process/specs/generated-doc-quality.feature b/architect/specs/generated-doc-quality.feature similarity index 93% rename from delivery-process/specs/generated-doc-quality.feature rename to architect/specs/generated-doc-quality.feature index c8219616..0382bd1a 100644 --- a/delivery-process/specs/generated-doc-quality.feature +++ b/architect/specs/generated-doc-quality.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:GeneratedDocQuality -@libar-docs-status:completed -@libar-docs-phase:38 -@libar-docs-effort:2d -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocsLiveConsolidation -@libar-docs-business-value:removes-500-lines-duplication-and-fixes-claude-context-coverage-for-generation-area -@libar-docs-priority:high +@architect +@architect-pattern:GeneratedDocQuality +@architect-status:completed +@architect-phase:38 +@architect-effort:2d +@architect-product-area:Generation +@architect-depends-on:DocsLiveConsolidation +@architect-business-value:removes-500-lines-duplication-and-fixes-claude-context-coverage-for-generation-area +@architect-priority:high Feature: Generated Documentation Quality Improvements **Problem:** @@ -36,7 +36,7 @@ Feature: Generated Documentation Quality Improvements | Deliverable | Status | Location | Tests | Test Type | | Fix behavior-specs renderer: no duplicate convention tables | complete | src/renderable/codecs/reference.ts | Yes | unit | | Enrich Generation _claude-md/ compact (target: 4+ KB) | complete | src/renderable/codecs/reference.ts | Yes | integration | - | Reorder ARCHITECTURE-TYPES.md: types first, convention content second | complete | delivery-process.config.ts, src/renderable/codecs/reference.ts | Yes | integration | + | Reorder ARCHITECTURE-TYPES.md: types first, convention content second | complete | architect.config.ts, src/renderable/codecs/reference.ts | Yes | integration | | Add generated TOC block to product area doc headers | complete | src/renderable/codecs/reference.ts | Yes | integration | Rule: Behavior-specs renderer does not duplicate convention table content diff --git a/delivery-process/specs/generator-infrastructure-testing.feature b/architect/specs/generator-infrastructure-testing.feature similarity index 96% rename from delivery-process/specs/generator-infrastructure-testing.feature rename to architect/specs/generator-infrastructure-testing.feature index ab5fea29..43df86ba 100644 --- a/delivery-process/specs/generator-infrastructure-testing.feature +++ b/architect/specs/generator-infrastructure-testing.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:GeneratorInfrastructureTesting -@libar-docs-status:roadmap -@libar-docs-phase:104 -@libar-docs-effort:2d -@libar-docs-product-area:Generation -@libar-docs-business-value:ensure-generator-orchestration-works-correctly -@libar-docs-priority:high -@libar-docs-executable-specs:tests/features/generators +@architect +@architect-pattern:GeneratorInfrastructureTesting +@architect-status:roadmap +@architect-phase:104 +@architect-effort:2d +@architect-product-area:Generation +@architect-business-value:ensure-generator-orchestration-works-correctly +@architect-priority:high +@architect-executable-specs:tests/features/generators Feature: Generator Infrastructure Testing **Problem:** diff --git a/delivery-process/specs/gherkin-patterns-restructure.feature b/architect/specs/gherkin-patterns-restructure.feature similarity index 96% rename from delivery-process/specs/gherkin-patterns-restructure.feature rename to architect/specs/gherkin-patterns-restructure.feature index 832eedef..a35ba37c 100644 --- a/delivery-process/specs/gherkin-patterns-restructure.feature +++ b/architect/specs/gherkin-patterns-restructure.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:GherkinPatternsRestructure -@libar-docs-status:completed -@libar-docs-phase:41 -@libar-docs-effort:0.5d -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocsConsolidationStrategy -@libar-docs-business-value:single-responsibility-per-doc -@libar-docs-priority:medium +@architect +@architect-pattern:GherkinPatternsRestructure +@architect-status:completed +@architect-phase:41 +@architect-effort:0.5d +@architect-product-area:Generation +@architect-depends-on:DocsConsolidationStrategy +@architect-business-value:single-responsibility-per-doc +@architect-priority:medium Feature: Gherkin Patterns Guide Restructure **Problem:** diff --git a/delivery-process/specs/gherkin-rules-support.feature b/architect/specs/gherkin-rules-support.feature similarity index 94% rename from delivery-process/specs/gherkin-rules-support.feature rename to architect/specs/gherkin-rules-support.feature index 18ca0a9f..f92cd1d4 100644 --- a/delivery-process/specs/gherkin-rules-support.feature +++ b/architect/specs/gherkin-rules-support.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:GherkinRulesSupport -@libar-docs-status:completed -@libar-docs-unlock-reason:Add-libar-docs-opt-in-marker -@libar-docs-phase:100 -@libar-docs-release:v1.0.0 -@libar-docs-effort:4h -@libar-docs-product-area:Annotation -@libar-docs-business-value:enable-human-readable-documentation-from-feature-files -@libar-docs-priority:high +@architect +@architect-pattern:GherkinRulesSupport +@architect-status:completed +@architect-unlock-reason:Add-libar-docs-opt-in-marker +@architect-phase:100 +@architect-release:v1.0.0 +@architect-effort:4h +@architect-product-area:Annotation +@architect-business-value:enable-human-readable-documentation-from-feature-files +@architect-priority:high Feature: Gherkin Rules and Custom Content Support **Problem:** diff --git a/delivery-process/specs/living-roadmap-cli.feature b/architect/specs/living-roadmap-cli.feature similarity index 88% rename from delivery-process/specs/living-roadmap-cli.feature rename to architect/specs/living-roadmap-cli.feature index 76f6e6b8..6c0612f4 100644 --- a/delivery-process/specs/living-roadmap-cli.feature +++ b/architect/specs/living-roadmap-cli.feature @@ -1,15 +1,15 @@ @opportunity-8 -@libar-docs +@architect @capstone -@libar-docs-pattern:LivingRoadmapCLI -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-effort:5d -@libar-docs-product-area:Process -@libar-docs-include:process-workflow -@libar-docs-depends-on:MvpWorkflowImplementation -@libar-docs-business-value:query-roadmap-with-natural-language -@libar-docs-priority:high +@architect-pattern:LivingRoadmapCLI +@architect-status:roadmap +@architect-phase:100 +@architect-effort:5d +@architect-product-area:Process +@architect-include:process-workflow +@architect-depends-on:MvpWorkflowImplementation +@architect-business-value:query-roadmap-with-natural-language +@architect-priority:high Feature: Living Roadmap CLI - Interactive Queries Over Reality **Problem:** diff --git a/delivery-process/specs/mcp-server-integration.feature b/architect/specs/mcp-server-integration.feature similarity index 82% rename from delivery-process/specs/mcp-server-integration.feature rename to architect/specs/mcp-server-integration.feature index 360741fa..297e5ee8 100644 --- a/delivery-process/specs/mcp-server-integration.feature +++ b/architect/specs/mcp-server-integration.feature @@ -1,14 +1,14 @@ -@libar-docs -@libar-docs-pattern:MCPServerIntegration -@libar-docs-status:active -@libar-docs-phase:46 -@libar-docs-product-area:DataAPI -@libar-docs-effort:3d -@libar-docs-priority:high -@libar-docs-depends-on:DataAPICLIErgonomics -@libar-docs-see-also:DataAPIPlatformIntegration,DataAPICLIErgonomics -@libar-docs-business-value:native-claude-code-tool-integration-with-zero-subprocess-overhead -@libar-docs-sequence-orchestrator:mcp-server +@architect +@architect-pattern:MCPServerIntegration +@architect-status:active +@architect-phase:46 +@architect-product-area:DataAPI +@architect-effort:3d +@architect-priority:high +@architect-depends-on:DataAPICLIErgonomics +@architect-see-also:DataAPIPlatformIntegration,DataAPICLIErgonomics +@architect-business-value:native-claude-code-tool-integration-with-zero-subprocess-overhead +@architect-sequence-orchestrator:mcp-server Feature: MCP Server Integration **Problem:** @@ -36,8 +36,8 @@ Feature: MCP Server Integration | MCP server bin entry | complete | src/cli/mcp-server.ts | | MCP configuration documentation | complete | docs/MCP-SETUP.md | - @libar-docs-sequence-step:1 - @libar-docs-sequence-module:pipeline-session + @architect-sequence-step:1 + @architect-sequence-module:pipeline-session Rule: MCP server starts via stdio transport and manages its own lifecycle **Invariant:** The MCP server communicates over stdio using JSON-RPC. It builds @@ -76,21 +76,21 @@ Feature: MCP Server Integration When the client sends an MCP initialize request Then the pipeline uses the explicit globs instead of config auto-detection - @libar-docs-sequence-step:2 - @libar-docs-sequence-module:tool-registry + @architect-sequence-step:2 + @architect-sequence-module:tool-registry Rule: ProcessStateAPI methods and CLI subcommands are registered as MCP tools **Invariant:** Every CLI subcommand is registered as an MCP tool with a JSON - Schema describing its input parameters. Tool names use snake_case with a "dp_" + Schema describing its input parameters. Tool names use snake_case with a "architect_" prefix to avoid collisions with other MCP servers. **Rationale:** MCP tools are the unit of interaction. Each tool needs a name, description (for LLM tool selection), and JSON Schema for input validation. - The "dp_" prefix prevents collisions in multi-server setups. + The "architect_" prefix prevents collisions in multi-server setups. **Input:** PipelineSession -- dataset, api, registry - **Output:** RegisteredTools -- 25 tools with dp_ prefix, Zod input schemas, handler functions + **Output:** RegisteredTools -- 25 tools with architect_ prefix, Zod input schemas, handler functions **Verified by:** All CLI subcommands appear as MCP tools, Tool schemas validate input parameters, @@ -101,35 +101,35 @@ Feature: MCP Server Integration Given the MCP server is initialized When the client requests the tool list Then at least 19 tools are registered - And each tool name starts with "dp_" + And each tool name starts with "architect_" And each tool has a non-empty description @acceptance-criteria @happy-path Scenario: Tool call executes successfully Given the MCP server is initialized - When the client calls "dp_overview" + When the client calls "architect_overview" Then the response contains the overview text with progress and phases - @acceptance-criteria @edge-case @libar-docs-sequence-error + @acceptance-criteria @edge-case @architect-sequence-error Scenario: Tool call with missing required parameter returns error Given the MCP server is initialized - When the client calls "dp_pattern" without the required "name" parameter + When the client calls "architect_pattern" without the required "name" parameter Then the response is an MCP error indicating invalid params @acceptance-criteria @happy-path Scenario: Pattern detail returns full metadata Given the MCP server is initialized - When the client calls "dp_pattern" for a pattern with rules and extracted shapes + When the client calls "architect_pattern" for a pattern with rules and extracted shapes Then the response contains the full pattern metadata payload And the response includes deliverables, dependencies, business rules, and extracted shapes - @libar-docs-sequence-step:3 - @libar-docs-sequence-module:pipeline-session + @architect-sequence-step:3 + @architect-sequence-module:pipeline-session Rule: MasterDataset is loaded once and reused across all tool invocations **Invariant:** The pipeline runs exactly once during server initialization. All subsequent tool calls read from in-memory MasterDataset. A manual rebuild can - be triggered via a "dp_rebuild" tool, and overlapping rebuild requests coalesce + be triggered via a "architect_rebuild" tool, and overlapping rebuild requests coalesce so the final in-memory session reflects the newest completed build. **Rationale:** The pipeline costs 2-5 seconds. Running it per tool call negates @@ -146,14 +146,14 @@ Feature: MCP Server Integration @acceptance-criteria @happy-path Scenario: Multiple tool calls share one pipeline build Given the MCP server is initialized - When the client calls "dp_status" then "dp_list" then "dp_overview" + When the client calls "architect_status" then "architect_list" then "architect_overview" Then all three return results And the pipeline was built exactly once @acceptance-criteria @happy-path Scenario: Rebuild refreshes the dataset Given the MCP server is running with a loaded dataset - When the client calls "dp_rebuild" + When the client calls "architect_rebuild" Then the pipeline runs again And subsequent tool calls use the new dataset @@ -167,12 +167,12 @@ Feature: MCP Server Integration @acceptance-criteria @edge-case Scenario: Concurrent reads during rebuild use previous dataset Given a rebuild is in progress - When a tool call arrives for "dp_status" + When a tool call arrives for "architect_status" Then the call uses the previous dataset And the call completes successfully with the previous data - @libar-docs-sequence-step:4 - @libar-docs-sequence-module:file-watcher + @architect-sequence-step:4 + @architect-sequence-module:file-watcher Rule: Source file changes trigger automatic dataset rebuild with debouncing **Invariant:** When --watch is enabled, changes to source files trigger an @@ -180,7 +180,7 @@ Feature: MCP Server Integration rebuild (default 500ms window). **Rationale:** During implementation sessions, source files change frequently. - Without auto-rebuild, agents must manually call dp_rebuild. Debouncing prevents + Without auto-rebuild, agents must manually call architect_rebuild. Debouncing prevents redundant rebuilds during rapid-fire saves. **Input:** FileChangeEvent -- filePath, eventType @@ -203,20 +203,20 @@ Feature: MCP Server Integration When 5 files are modified within 200ms Then the pipeline rebuilds exactly once after the debounce window - @acceptance-criteria @edge-case @libar-docs-sequence-error + @acceptance-criteria @edge-case @architect-sequence-error Scenario: Rebuild failure during watch does not crash server Given the MCP server is running with --watch enabled When a source file change introduces a parse error Then the server continues using the previous valid dataset And the rebuild failure is logged to stderr - @libar-docs-sequence-step:5 - @libar-docs-sequence-module:mcp-server + @architect-sequence-step:5 + @architect-sequence-module:mcp-server Rule: MCP server is configurable via standard client configuration **Invariant:** The server works with .mcp.json (Claude Code), claude_desktop_config.json (Claude Desktop), and any MCP client. It accepts --input, --features, --base-dir - args, auto-detects delivery-process.config.ts, and reports the package version + args, auto-detects architect.config.ts, and reports the package version accurately through the CLI. **Rationale:** MCP clients discover servers through configuration files. The @@ -234,14 +234,14 @@ Feature: MCP Server Integration @acceptance-criteria @happy-path Scenario: Default config auto-detection - Given a project with delivery-process.config.ts + Given a project with architect.config.ts When the MCP server is started without explicit arguments Then it loads globs from the config file And the pipeline builds successfully @acceptance-criteria @happy-path Scenario: Config without explicit sources falls back to conventional globs - Given a project with delivery-process.config.ts but no explicit sources + Given a project with architect.config.ts but no explicit sources When the MCP server is started without explicit arguments Then it falls back to the conventional source globs And the pipeline builds successfully @@ -249,18 +249,18 @@ Feature: MCP Server Integration @acceptance-criteria @happy-path Scenario: Server works when started via npx Given the package is installed - When running "npx @libar-dev/delivery-process dp-mcp-server" + When running "npx @libar-dev/architect architect-mcp" Then the server process starts and awaits MCP initialize And no extraneous output appears on stdout @acceptance-criteria @happy-path Scenario: Version flag reports package version Given the package is installed - When running "npx @libar-dev/delivery-process dp-mcp-server --version" + When running "npx @libar-dev/architect architect-mcp --version" Then the output contains the current package version - @acceptance-criteria @edge-case @libar-docs-sequence-error + @acceptance-criteria @edge-case @architect-sequence-error Scenario: No config file and no explicit globs - Given a directory without delivery-process.config.ts + Given a directory without architect.config.ts When the MCP server is started without arguments Then the server exits with a clear error message diff --git a/delivery-process/specs/monorepo-support.feature b/architect/specs/monorepo-support.feature similarity index 95% rename from delivery-process/specs/monorepo-support.feature rename to architect/specs/monorepo-support.feature index a7836aa8..b26373bd 100644 --- a/delivery-process/specs/monorepo-support.feature +++ b/architect/specs/monorepo-support.feature @@ -1,15 +1,15 @@ -@libar-docs -@libar-docs-pattern:MonorepoSupport -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-product-area:Configuration -@libar-docs-effort:3d -@libar-docs-priority:low -@libar-docs-business-value:multi-package-config-and-scoped-queries-for-monorepo-consumers +@architect +@architect-pattern:MonorepoSupport +@architect-status:roadmap +@architect-phase:100 +@architect-product-area:Configuration +@architect-effort:3d +@architect-priority:low +@architect-business-value:multi-package-config-and-scoped-queries-for-monorepo-consumers Feature: Monorepo Cross-Package Support **Problem:** - The delivery-process package is consumed by a large monorepo (~600 files across + The Architect package is consumed by a large monorepo (~600 files across multiple packages), but the config system has no concept of "packages." The consumer passes all source paths as repeated --input and --features CLI flags, creating massive duplication across 15+ scripts. MasterDataset has no concept of diff --git a/delivery-process/specs/mvp-workflow-implementation.feature b/architect/specs/mvp-workflow-implementation.feature similarity index 84% rename from delivery-process/specs/mvp-workflow-implementation.feature rename to architect/specs/mvp-workflow-implementation.feature index 046ee598..e69eeb72 100644 --- a/delivery-process/specs/mvp-workflow-implementation.feature +++ b/architect/specs/mvp-workflow-implementation.feature @@ -1,19 +1,19 @@ -@libar-docs -@libar-docs-pattern:MvpWorkflowImplementation -@libar-docs-status:completed -@libar-docs-unlock-reason:Add-process-workflow-include-tag -@libar-docs-phase:99 -@libar-docs-release:v1.0.0 -@libar-docs-effort:8h -@libar-docs-product-area:Process -@libar-docs-include:process-workflow -@libar-docs-business-value:align-package-with-pdr005-fsm -@libar-docs-priority:high +@architect +@architect-pattern:MvpWorkflowImplementation +@architect-status:completed +@architect-unlock-reason:Add-process-workflow-include-tag +@architect-phase:99 +@architect-release:v1.0.0 +@architect-effort:8h +@architect-product-area:Process +@architect-include:process-workflow +@architect-business-value:align-package-with-pdr005-fsm +@architect-priority:high Feature: MVP Workflow Implementation **Problem:** PDR-005 defines a 4-state workflow FSM (`roadmap, active, completed, deferred`) - but the delivery-process package validation schemas and generators may still + but the Architect package validation schemas and generators may still reference legacy status values. Need to ensure alignment. **Solution:** @@ -42,13 +42,13 @@ Feature: MVP Workflow Implementation @acceptance-criteria Scenario: Scanner extracts new status values - Given a feature file with @libar-docs-status:roadmap + Given a feature file with @architect-status:roadmap When the scanner processes the file Then the status field is "roadmap" @acceptance-criteria Scenario Outline: All four status values are valid - Given a feature file with @libar-docs-status: + Given a feature file with @architect-status: When validating the pattern Then validation passes diff --git a/delivery-process/specs/orchestrator-pipeline-factory-migration.feature b/architect/specs/orchestrator-pipeline-factory-migration.feature similarity index 97% rename from delivery-process/specs/orchestrator-pipeline-factory-migration.feature rename to architect/specs/orchestrator-pipeline-factory-migration.feature index 4800e56d..11f02a17 100644 --- a/delivery-process/specs/orchestrator-pipeline-factory-migration.feature +++ b/architect/specs/orchestrator-pipeline-factory-migration.feature @@ -1,14 +1,14 @@ -@libar-docs -@libar-docs-pattern:OrchestratorPipelineFactoryMigration -@libar-docs-status:completed -@libar-docs-unlock-reason:PR28-review-structural-fixes -@libar-docs-phase:101 -@libar-docs-effort:2d -@libar-docs-product-area:Generation -@libar-docs-include:process-workflow,codec-transformation -@libar-docs-depends-on:ProcessAPILayeredExtraction -@libar-docs-business-value:eliminate-last-parallel-pipeline-and-unify-pipeline-definition -@libar-docs-priority:high +@architect +@architect-pattern:OrchestratorPipelineFactoryMigration +@architect-status:completed +@architect-unlock-reason:PR28-review-structural-fixes +@architect-phase:101 +@architect-effort:2d +@architect-product-area:Generation +@architect-include:process-workflow,codec-transformation +@architect-depends-on:ProcessAPILayeredExtraction +@architect-business-value:eliminate-last-parallel-pipeline-and-unify-pipeline-definition +@architect-priority:high Feature: Orchestrator Pipeline Factory Migration **Problem:** diff --git a/delivery-process/specs/pattern-relationship-model.feature b/architect/specs/pattern-relationship-model.feature similarity index 83% rename from delivery-process/specs/pattern-relationship-model.feature rename to architect/specs/pattern-relationship-model.feature index 1305bb92..d9cbd32d 100644 --- a/delivery-process/specs/pattern-relationship-model.feature +++ b/architect/specs/pattern-relationship-model.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:PatternRelationshipModel -@libar-docs-status:completed -@libar-docs-unlock-reason:Normalize-deliverable-status-taxonomy -@libar-docs-phase:99 -@libar-docs-release:v1.0.0 -@libar-docs-effort:2w -@libar-docs-product-area:Annotation -@libar-docs-level:epic -@libar-docs-executable-specs:tests/features/behavior/pattern-relationships +@architect +@architect-pattern:PatternRelationshipModel +@architect-status:completed +@architect-unlock-reason:Normalize-deliverable-status-taxonomy +@architect-phase:99 +@architect-release:v1.0.0 +@architect-effort:2w +@architect-product-area:Annotation +@architect-level:epic +@architect-executable-specs:tests/features/behavior/pattern-relationships Feature: Pattern Relationship Model **Problem:** The delivery process lacks a comprehensive relationship model between artifacts. @@ -53,7 +53,7 @@ Feature: Pattern Relationship Model Rule: Code files declare pattern realization via implements tag - **Invariant:** Files with `@libar-docs-implements:PatternName,OtherPattern` are linked + **Invariant:** Files with `@architect-implements:PatternName,OtherPattern` are linked to the specified patterns without causing conflicts. Pattern definitions remain in roadmap specs; implementation files provide supplementary metadata. Multiple files can implement the same pattern, and one file can implement multiple patterns. @@ -72,10 +72,10 @@ Feature: Pattern Relationship Model Given a TypeScript file with annotations: """typescript /** - * @libar-docs - * @libar-docs-implements EventStoreDurability - * @libar-docs-status roadmap - * @libar-docs-uses idempotentAppend, Workpool + * @architect + * @architect-implements EventStoreDurability + * @architect-status roadmap + * @architect-uses idempotentAppend, Workpool */ """ When the scanner processes the file @@ -88,8 +88,8 @@ Feature: Pattern Relationship Model Given a TypeScript file with annotations: """typescript /** - * @libar-docs - * @libar-docs-implements EventStoreDurability, IdempotentAppend + * @architect + * @architect-implements EventStoreDurability, IdempotentAppend */ """ When the scanner processes the file @@ -98,15 +98,15 @@ Feature: Pattern Relationship Model @acceptance-criteria @happy-path Scenario: No conflict with pattern definition - Given a roadmap spec with `@libar-docs-pattern:EventStoreDurability` - And a TypeScript file with `@libar-docs-implements:EventStoreDurability` + Given a roadmap spec with `@architect-pattern:EventStoreDurability` + And a TypeScript file with `@architect-implements:EventStoreDurability` When the generator processes both Then no conflict error is raised And the implementation file is associated with the pattern @acceptance-criteria @happy-path Scenario: Multiple files implement same pattern - Given three TypeScript files each with `@libar-docs-implements:EventStoreDurability` + Given three TypeScript files each with `@architect-implements:EventStoreDurability` When the generator processes all files Then all three are listed as implementations of "EventStoreDurability" And each file's metadata is preserved separately @@ -117,7 +117,7 @@ Feature: Pattern Relationship Model Rule: Pattern inheritance uses extends relationship tag - **Invariant:** Files with `@libar-docs-extends:BasePattern` declare that they extend + **Invariant:** Files with `@architect-extends:BasePattern` declare that they extend another pattern's capabilities. This is a generalization relationship where the extending pattern is a specialization of the base pattern. @@ -133,9 +133,9 @@ Feature: Pattern Relationship Model Scenario: Extends tag parsed from feature file Given a roadmap spec with: """gherkin - @libar-docs - @libar-docs-pattern:ReactiveProjections - @libar-docs-extends:ProjectionCategories + @architect + @architect-pattern:ReactiveProjections + @architect-extends:ProjectionCategories """ When the scanner processes the file Then the pattern "ReactiveProjections" is linked to base "ProjectionCategories" @@ -143,14 +143,14 @@ Feature: Pattern Relationship Model @acceptance-criteria @happy-path Scenario: Extended-by reverse lookup computed - Given pattern A with `@libar-docs-extends:B` + Given pattern A with `@architect-extends:B` When the relationship index is built Then pattern B's `extendedBy` includes "A" @acceptance-criteria @validation Scenario: Circular inheritance detected - Given pattern A with `@libar-docs-extends:B` - And pattern B with `@libar-docs-extends:A` + Given pattern A with `@architect-extends:B` + And pattern B with `@architect-extends:A` When the linter runs Then an error is emitted about circular inheritance @@ -160,8 +160,8 @@ Feature: Pattern Relationship Model Rule: Technical dependencies use directed relationship tags - **Invariant:** `@libar-docs-uses` declares outbound dependencies (what this - pattern depends on). `@libar-docs-used-by` declares inbound dependencies + **Invariant:** `@architect-uses` declares outbound dependencies (what this + pattern depends on). `@architect-used-by` declares inbound dependencies (what depends on this pattern). Both are CSV format. **Rationale:** These represent technical coupling between patterns. The @@ -172,13 +172,13 @@ Feature: Pattern Relationship Model @acceptance-criteria @happy-path Scenario: Uses rendered as solid arrows in graph - Given a pattern with `@libar-docs-uses:CommandBus,EventStore` + Given a pattern with `@architect-uses:CommandBus,EventStore` When the Mermaid graph is generated Then solid arrows point from pattern to "CommandBus" and "EventStore" @acceptance-criteria @happy-path Scenario: Used-by aggregated in pattern detail - Given pattern A with `@libar-docs-used-by:B,C` + Given pattern A with `@architect-used-by:B,C` When the pattern detail page is generated Then the "Used By" section lists "B" and "C" @@ -188,8 +188,8 @@ Feature: Pattern Relationship Model Rule: Roadmap sequencing uses ordering relationship tags - **Invariant:** `@libar-docs-depends-on` declares what must be completed first - (roadmap sequencing). `@libar-docs-enables` declares what this unlocks when + **Invariant:** `@architect-depends-on` declares what must be completed first + (roadmap sequencing). `@architect-enables` declares what this unlocks when completed. These are planning relationships, not technical dependencies. **Rationale:** Sequencing is about order of work, not runtime coupling. @@ -213,8 +213,8 @@ Feature: Pattern Relationship Model Rule: Cross-tier linking uses traceability tags (PDR-007) - **Invariant:** `@libar-docs-executable-specs` on roadmap specs points to test - locations. `@libar-docs-roadmap-spec` on package specs points back to the + **Invariant:** `@architect-executable-specs` on roadmap specs points to test + locations. `@architect-roadmap-spec` on package specs points back to the pattern. These create bidirectional traceability. **Rationale:** Two-tier architecture (PDR-007) separates planning specs from @@ -225,15 +225,15 @@ Feature: Pattern Relationship Model @acceptance-criteria @happy-path Scenario: Bidirectional links established - Given a roadmap spec with `@libar-docs-executable-specs:platform-core/tests/features/durability` - And a package spec with `@libar-docs-roadmap-spec:EventStoreDurability` + Given a roadmap spec with `@architect-executable-specs:platform-core/tests/features/durability` + And a package spec with `@architect-roadmap-spec:EventStoreDurability` When the traceability index is built Then the roadmap spec links forward to the package location And the package spec links back to the pattern @acceptance-criteria @validation Scenario: Orphan executable spec detected - Given a package spec with `@libar-docs-roadmap-spec:NonExistentPattern` + Given a package spec with `@architect-roadmap-spec:NonExistentPattern` When the linter runs Then a warning is emitted about orphan executable spec @@ -243,8 +243,8 @@ Feature: Pattern Relationship Model Rule: Epic/Phase/Task hierarchy uses parent-child relationships - **Invariant:** `@libar-docs-level` declares the hierarchy tier (epic, phase, task). - `@libar-docs-parent` links to the containing pattern. This enables rollup + **Invariant:** `@architect-level` declares the hierarchy tier (epic, phase, task). + `@architect-parent` links to the containing pattern. This enables rollup progress tracking. **Rationale:** Large initiatives decompose into phases and tasks. The hierarchy @@ -254,14 +254,14 @@ Feature: Pattern Relationship Model @acceptance-criteria @happy-path Scenario: Parent link validated - Given a phase spec with `@libar-docs-parent:ProcessEnhancements` - And an epic spec with `@libar-docs-pattern:ProcessEnhancements` + Given a phase spec with `@architect-parent:ProcessEnhancements` + And an epic spec with `@architect-pattern:ProcessEnhancements` When the hierarchy is validated Then the parent link is confirmed valid @acceptance-criteria @validation Scenario: Invalid parent detected - Given a task spec with `@libar-docs-parent:NonExistentEpic` + Given a task spec with `@architect-parent:NonExistentEpic` When the linter runs Then an error is emitted about invalid parent reference @@ -317,21 +317,21 @@ Feature: Pattern Relationship Model @acceptance-criteria @validation Scenario: Missing relationship target detected - Given a file with `@libar-docs-uses:NonExistentPattern` + Given a file with `@architect-uses:NonExistentPattern` When the linter runs with strict mode Then a warning is emitted about unresolved relationship target @acceptance-criteria @validation Scenario: Pattern tag in implements file causes error - Given a file with both `@libar-docs-implements:X` and `@libar-docs-pattern:X` + Given a file with both `@architect-implements:X` and `@architect-pattern:X` When the linter runs Then an error is emitted about conflicting tags And the message explains that implements files must not define patterns @acceptance-criteria @validation Scenario: Asymmetric traceability detected - Given a roadmap spec with `@libar-docs-executable-specs:path/to/tests` - And no package spec at that path with `@libar-docs-roadmap-spec` back-link + Given a roadmap spec with `@architect-executable-specs:path/to/tests` + And no package spec at that path with `@architect-roadmap-spec` back-link When the linter runs with strict mode Then a warning is emitted about missing back-link diff --git a/delivery-process/specs/phase-numbering-conventions.feature b/architect/specs/phase-numbering-conventions.feature similarity index 83% rename from delivery-process/specs/phase-numbering-conventions.feature rename to architect/specs/phase-numbering-conventions.feature index b57dab7d..0b6355cd 100644 --- a/delivery-process/specs/phase-numbering-conventions.feature +++ b/architect/specs/phase-numbering-conventions.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:PhaseNumberingConventions -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-effort:2h -@libar-docs-product-area:Validation -@libar-docs-business-value:prevent-phase-number-conflicts-and-ensure-consistent-ordering -@libar-docs-priority:medium +@architect +@architect-pattern:PhaseNumberingConventions +@architect-status:roadmap +@architect-phase:100 +@architect-effort:2h +@architect-product-area:Validation +@architect-business-value:prevent-phase-number-conflicts-and-ensure-consistent-ordering +@architect-priority:medium Feature: Phase Numbering Conventions and Validation **Problem:** @@ -23,9 +23,9 @@ Feature: Phase Numbering Conventions and Validation Background: Deliverables Given the following deliverables: | Deliverable | Status | Tests | Location | - | Phase number validator | pending | Yes | @libar-dev/delivery-process/src/validation/ | - | Duplicate detection | pending | Yes | @libar-dev/delivery-process/src/lint/rules/ | - | Next phase suggester | pending | Yes | @libar-dev/delivery-process/src/cli/ | + | Phase number validator | pending | Yes | @libar-dev/architect/src/validation/ | + | Duplicate detection | pending | Yes | @libar-dev/architect/src/lint/rules/ | + | Next phase suggester | pending | Yes | @libar-dev/architect/src/cli/ | Rule: Phase numbers must be unique within a release diff --git a/delivery-process/specs/phase-state-machine.feature b/architect/specs/phase-state-machine.feature similarity index 80% rename from delivery-process/specs/phase-state-machine.feature rename to architect/specs/phase-state-machine.feature index 0b55ed40..0d67a382 100644 --- a/delivery-process/specs/phase-state-machine.feature +++ b/architect/specs/phase-state-machine.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:PhaseStateMachineValidation -@libar-docs-status:completed -@libar-docs-unlock-reason:Add-libar-docs-opt-in-marker -@libar-docs-phase:100 -@libar-docs-release:v1.0.0 -@libar-docs-effort:4h -@libar-docs-product-area:Validation -@libar-docs-business-value:ensure-state-machine-rules-are-enforced-programmatically -@libar-docs-priority:high +@architect +@architect-pattern:PhaseStateMachineValidation +@architect-status:completed +@architect-unlock-reason:Add-libar-docs-opt-in-marker +@architect-phase:100 +@architect-release:v1.0.0 +@architect-effort:4h +@architect-product-area:Validation +@architect-business-value:ensure-state-machine-rules-are-enforced-programmatically +@architect-priority:high Feature: Phase State Machine Validation **Problem:** @@ -24,11 +24,11 @@ Feature: Phase State Machine Validation Background: Deliverables Given the following deliverables: | Deliverable | Status | Tests | Location | - | FSM states and protection levels | complete | 123 | @libar-dev/delivery-process/src/validation/fsm/states.ts | - | FSM transition matrix and validator | complete | 123 | @libar-dev/delivery-process/src/validation/fsm/transitions.ts | - | Pure validation functions | complete | 123 | @libar-dev/delivery-process/src/validation/fsm/validator.ts | - | Status validation lint rule | complete | 2190 | @libar-dev/delivery-process/src/lint/rules.ts | - | ProcessStateAPI for programmatic queries | complete | 95 | @libar-dev/delivery-process/src/api/process-state.ts | + | FSM states and protection levels | complete | 123 | @libar-dev/architect/src/validation/fsm/states.ts | + | FSM transition matrix and validator | complete | 123 | @libar-dev/architect/src/validation/fsm/transitions.ts | + | Pure validation functions | complete | 123 | @libar-dev/architect/src/validation/fsm/validator.ts | + | Status validation lint rule | complete | 2190 | @libar-dev/architect/src/lint/rules.ts | + | ProcessStateAPI for programmatic queries | complete | 95 | @libar-dev/architect/src/api/process-state.ts | Rule: Valid status values are enforced @@ -91,11 +91,11 @@ Feature: Phase State Machine Validation @acceptance-criteria Scenario: Completed status requires completion date Given a phase transitioning to "completed" status - When the @libar-docs-completed tag is missing - Then validation warns "Completed phases should have @libar-docs-completed date" + When the @architect-completed tag is missing + Then validation warns "Completed phases should have @architect-completed date" @acceptance-criteria Scenario: Completed phases should have effort-actual Given a phase transitioning to "completed" status - When the @libar-docs-effort-actual tag is missing - Then validation warns "Completed phases should have @libar-docs-effort-actual for variance tracking" + When the @architect-effort-actual tag is missing + Then validation warns "Completed phases should have @architect-effort-actual for variance tracking" diff --git a/delivery-process/specs/prd-generator-code-annotations-inclusion.feature b/architect/specs/prd-generator-code-annotations-inclusion.feature similarity index 78% rename from delivery-process/specs/prd-generator-code-annotations-inclusion.feature rename to architect/specs/prd-generator-code-annotations-inclusion.feature index d787b7b2..821c2520 100644 --- a/delivery-process/specs/prd-generator-code-annotations-inclusion.feature +++ b/architect/specs/prd-generator-code-annotations-inclusion.feature @@ -1,18 +1,18 @@ -@libar-docs -@libar-docs-pattern:PrdImplementationSection -@libar-docs-status:roadmap -@libar-docs-phase:99 -@libar-docs-effort:3d -@libar-docs-product-area:Generation -@libar-docs-parent:PatternRelationshipModel +@architect +@architect-pattern:PrdImplementationSection +@architect-status:roadmap +@architect-phase:99 +@architect-effort:3d +@architect-product-area:Generation +@architect-parent:PatternRelationshipModel Feature: PRD Implementation Section - **Problem:** Implementation files with `@libar-docs-implements:PatternName` contain rich - relationship metadata (`@libar-docs-uses`, `@libar-docs-used-by`, `@libar-docs-usecase`) + **Problem:** Implementation files with `@architect-implements:PatternName` contain rich + relationship metadata (`@architect-uses`, `@architect-used-by`, `@architect-usecase`) that is not rendered in generated PRD documentation. This metadata provides valuable API guidance and dependency information. - **Solution:** Extend the PRD generator to collect all files with `@libar-docs-implements:X` + **Solution:** Extend the PRD generator to collect all files with `@architect-implements:X` and render their metadata in a dedicated "## Implementations" section. This leverages the relationship model from PatternRelationshipModel without requiring specs to list file paths. @@ -26,8 +26,8 @@ Feature: PRD Implementation Section Background: Deliverables Given the following deliverables: | Deliverable | Status | Location | Tests | Test Type | - | Implementation collector | pending | delivery-process/src/generators/ | Yes | unit | - | PRD section renderer | pending | delivery-process/src/renderable/ | Yes | unit | + | Implementation collector | pending | architect/src/generators/ | Yes | unit | + | PRD section renderer | pending | architect/src/renderable/ | Yes | unit | # ============================================================================ # RULE 1: Implementation Discovery via Relationship Index @@ -39,7 +39,7 @@ Feature: PRD Implementation Section relationship index for all files where `implements === X`. No explicit listing in the spec file is required. - **Rationale:** The `@libar-docs-implements` tag creates a backward link from + **Rationale:** The `@architect-implements` tag creates a backward link from code to spec. The relationship index aggregates these. PRD generation simply queries the index rather than scanning directories. @@ -47,8 +47,8 @@ Feature: PRD Implementation Section @acceptance-criteria @happy-path Scenario: Implementations discovered from relationship index - Given a roadmap spec with `@libar-docs-pattern:EventStoreDurability` - And three TypeScript files with `@libar-docs-implements:EventStoreDurability` + Given a roadmap spec with `@architect-pattern:EventStoreDurability` + And three TypeScript files with `@architect-implements:EventStoreDurability` When the PRD generator processes the pattern Then all three implementation files are discovered And no directory path is needed in the spec @@ -87,19 +87,19 @@ Feature: PRD Implementation Section @acceptance-criteria @happy-path Scenario: Dependencies rendered per implementation - Given implementation file with `@libar-docs-uses EventStore, Workpool` + Given implementation file with `@architect-uses EventStore, Workpool` When rendered in PRD Then output includes "**Dependencies:** EventStore, Workpool" @acceptance-criteria @happy-path Scenario: Usecases rendered as guidance - Given implementation file with `@libar-docs-usecase "When event append must survive failures"` + Given implementation file with `@architect-usecase "When event append must survive failures"` When rendered in PRD Then output includes "**When to Use:** When event append must survive failures" @acceptance-criteria @happy-path Scenario: Used-by rendered for visibility - Given implementation file with `@libar-docs-used-by CommandOrchestrator, SagaEngine` + Given implementation file with `@architect-used-by CommandOrchestrator, SagaEngine` When rendered in PRD Then output includes "**Used By:** CommandOrchestrator, SagaEngine" @@ -109,7 +109,7 @@ Feature: PRD Implementation Section Rule: Patterns without implementations render cleanly - **Invariant:** If no files have `@libar-docs-implements:X` for pattern X, + **Invariant:** If no files have `@architect-implements:X` for pattern X, the "## Implementations" section is omitted (not rendered as empty). **Rationale:** Planned patterns may not have implementations yet. Empty @@ -120,6 +120,6 @@ Feature: PRD Implementation Section @acceptance-criteria @happy-path Scenario: Section omitted when no implementations exist Given a pattern "FuturePattern" with status "roadmap" - And no files have `@libar-docs-implements:FuturePattern` + And no files have `@architect-implements:FuturePattern` When the PRD generator runs Then the output does not include "## Implementations" diff --git a/delivery-process/specs/procedural-guide-codec.feature b/architect/specs/procedural-guide-codec.feature similarity index 91% rename from delivery-process/specs/procedural-guide-codec.feature rename to architect/specs/procedural-guide-codec.feature index bea062cd..84cb110f 100644 --- a/delivery-process/specs/procedural-guide-codec.feature +++ b/architect/specs/procedural-guide-codec.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:ProceduralGuideCodec -@libar-docs-status:completed -@libar-docs-unlock-reason:DD7-DD8-preamble-migration-complete -@libar-docs-phase:35 -@libar-docs-effort:3w -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocsConsolidationStrategy -@libar-docs-business-value:replaces-757-lines-of-manual-SESSION-GUIDES-and-ANNOTATION-GUIDE-with-generated-procedural-guides-using-dual-source-codec -@libar-docs-priority:medium +@architect +@architect-pattern:ProceduralGuideCodec +@architect-status:completed +@architect-unlock-reason:DD7-DD8-preamble-migration-complete +@architect-phase:35 +@architect-effort:3w +@architect-product-area:Generation +@architect-depends-on:DocsConsolidationStrategy +@architect-business-value:replaces-757-lines-of-manual-SESSION-GUIDES-and-ANNOTATION-GUIDE-with-generated-procedural-guides-using-dual-source-codec +@architect-priority:medium Feature: Procedural Guide Codec **Problem:** @@ -76,7 +76,7 @@ Feature: Procedural Guide Codec **Design Session Findings (2026-03-06):** | Finding | Impact | Resolution | - | DD-1: No new codec class needed -- reuse createReferenceCodec() with two ReferenceDocConfig entries | Eliminates codec implementation deliverable; reduces to config-only work | Two ReferenceDocConfig entries in delivery-process.config.ts with different preamble, includeTags, and output paths | + | DD-1: No new codec class needed -- reuse createReferenceCodec() with two ReferenceDocConfig entries | Eliminates codec implementation deliverable; reduces to config-only work | Two ReferenceDocConfig entries in architect.config.ts with different preamble, includeTags, and output paths | | DD-2: SessionGuidesModuleSource Rules 3-8 tables already machine-extractable | buildBehaviorSectionsFromPatterns() + parseBusinessRuleAnnotations() + extractTablesFromDescription() handle all table formats | Use includeTags:session-workflows on SessionGuidesModuleSource to route behavior content to session guide | | DD-3: Checklists and decision trees use existing SectionBlock types | No new ChecklistBlock or DecisionTreeBlock needed; ListBlock with [ ] prefix = checkbox syntax; MermaidBlock = flowchart. SectionBlock[] produced by parsing markdown via loadPreambleFromMarkdown() | Zero schema/renderer changes required | | DD-4: Preamble is flat SectionBlock[] produced from markdown source files | No new named-section abstraction; heading blocks provide structure. Content authored as markdown in docs-sources/, parsed into SectionBlock[] at config import time -- not inline TypeScript object literals | Preserves same preamble composition pattern; authoring ergonomics improved | @@ -87,23 +87,23 @@ Feature: Procedural Guide Codec **Design Stubs:** | Stub | Purpose | Target | - | delivery-process/stubs/procedural-guide-codec/procedural-codec-options.ts | Documents DD-1,DD-3,DD-4: no new options type, reuses ReferenceDocConfig | src/renderable/codecs/procedural-guide.ts | - | delivery-process/stubs/procedural-guide-codec/procedural-codec.ts | Documents DD-1,DD-2,DD-5,DD-6,DD-7,DD-8: config entries with loadPreambleFromMarkdown() | delivery-process.config.ts | - | delivery-process/stubs/procedural-guide-codec/session-guide-preamble.ts | DD-7: Markdown source file example + loadPreambleFromMarkdown() usage | delivery-process.config.ts | - | delivery-process/stubs/procedural-guide-codec/annotation-guide-preamble.ts | DD-7: Markdown source file example + loadPreambleFromMarkdown() usage | delivery-process.config.ts | - | delivery-process/stubs/procedural-guide-codec/load-preamble.ts | DD-8: loadPreambleFromMarkdown() utility interface and parsing spec | src/renderable/load-preamble.ts | + | architect/stubs/procedural-guide-codec/procedural-codec-options.ts | Documents DD-1,DD-3,DD-4: no new options type, reuses ReferenceDocConfig | src/renderable/codecs/procedural-guide.ts | + | architect/stubs/procedural-guide-codec/procedural-codec.ts | Documents DD-1,DD-2,DD-5,DD-6,DD-7,DD-8: config entries with loadPreambleFromMarkdown() | architect.config.ts | + | architect/stubs/procedural-guide-codec/session-guide-preamble.ts | DD-7: Markdown source file example + loadPreambleFromMarkdown() usage | architect.config.ts | + | architect/stubs/procedural-guide-codec/annotation-guide-preamble.ts | DD-7: Markdown source file example + loadPreambleFromMarkdown() usage | architect.config.ts | + | architect/stubs/procedural-guide-codec/load-preamble.ts | DD-8: loadPreambleFromMarkdown() utility interface and parsing spec | src/renderable/load-preamble.ts | Background: Deliverables Given the following deliverables: | Deliverable | Status | Location | Tests | Test Type | - | ReferenceDocConfig entry for session workflow guide (DD-1: reuses createReferenceCodec) | complete | delivery-process.config.ts | Yes | integration | - | ReferenceDocConfig entry for annotation guide (DD-1: reuses createReferenceCodec) | complete | delivery-process.config.ts | Yes | integration | - | Add libar-docs-include:session-workflows tag to SessionGuidesModuleSource (DD-2) | complete | delivery-process/specs/session-guides-module-source.feature | No | n/a | + | ReferenceDocConfig entry for session workflow guide (DD-1: reuses createReferenceCodec) | complete | architect.config.ts | Yes | integration | + | ReferenceDocConfig entry for annotation guide (DD-1: reuses createReferenceCodec) | complete | architect.config.ts | Yes | integration | + | Add libar-docs-include:session-workflows tag to SessionGuidesModuleSource (DD-2) | complete | architect/specs/session-guides-module-source.feature | No | n/a | | Create loadPreambleFromMarkdown() utility (DD-8) | complete | src/renderable/load-preamble.ts | Yes | unit | | Create session workflow guide markdown source (DD-7) | complete | docs-sources/session-workflow-guide.md | No | n/a | | Create annotation guide markdown source (DD-7) | complete | docs-sources/annotation-guide.md | No | n/a | - | Migrate session workflow preamble to loadPreambleFromMarkdown() call (DD-7) | complete | delivery-process.config.ts | Yes | integration | - | Migrate annotation guide preamble to loadPreambleFromMarkdown() call (DD-7) | complete | delivery-process.config.ts | Yes | integration | + | Migrate session workflow preamble to loadPreambleFromMarkdown() call (DD-7) | complete | architect.config.ts | Yes | integration | + | Migrate annotation guide preamble to loadPreambleFromMarkdown() call (DD-7) | complete | architect.config.ts | Yes | integration | | Behavior spec with scenarios for procedural guide generation | n/a | tests/features/generation/procedural-guide-codec.feature | Yes | acceptance | | Quality comparison: generated vs manual content audit (DD-6) | n/a | docs/SESSION-GUIDES.md | No | n/a | diff --git a/delivery-process/specs/process-api-hybrid-generation.feature b/architect/specs/process-api-hybrid-generation.feature similarity index 95% rename from delivery-process/specs/process-api-hybrid-generation.feature rename to architect/specs/process-api-hybrid-generation.feature index 0eb51c60..385ec483 100644 --- a/delivery-process/specs/process-api-hybrid-generation.feature +++ b/architect/specs/process-api-hybrid-generation.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:ProcessApiHybridGeneration -@libar-docs-status:completed -@libar-docs-phase:43 -@libar-docs-effort:1d -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocsConsolidationStrategy -@libar-docs-business-value:keeps-process-api-reference-tables-in-sync-with-cli-schema-automatically -@libar-docs-priority:low +@architect +@architect-pattern:ProcessApiHybridGeneration +@architect-status:completed +@architect-phase:43 +@architect-effort:1d +@architect-product-area:Generation +@architect-depends-on:DocsConsolidationStrategy +@architect-business-value:keeps-process-api-reference-tables-in-sync-with-cli-schema-automatically +@architect-priority:low Feature: PROCESS-API.md Hybrid Generation **Problem:** @@ -69,7 +69,7 @@ Feature: PROCESS-API.md Hybrid Generation | Create declarative CLI schema with option groups | complete | src/cli/cli-schema.ts | Yes | unit | | Sync test verifying schema entries match parseArgs behavior | complete | tests/features/behavior/cli/ | Yes | integration | | ProcessApiReferenceGenerator producing complete reference file | complete | src/generators/built-in/process-api-reference-generator.ts | Yes | integration | - | Register generator in orchestrator config | complete | delivery-process.config.ts | Yes | integration | + | Register generator in orchestrator config | complete | architect.config.ts | Yes | integration | | Trim PROCESS-API.md Output Reference to link to generated file | complete | docs/PROCESS-API.md | Yes | manual | | Refactor showHelp to consume CLI schema | complete | src/cli/process-api.ts | Yes | integration | | Behavior spec with scenarios for all 3 generated tables | complete | tests/features/behavior/cli/process-api-reference.feature | Yes | integration | diff --git a/delivery-process/specs/process-api-layered-extraction.feature b/architect/specs/process-api-layered-extraction.feature similarity index 97% rename from delivery-process/specs/process-api-layered-extraction.feature rename to architect/specs/process-api-layered-extraction.feature index a3f7b676..03c6d21a 100644 --- a/delivery-process/specs/process-api-layered-extraction.feature +++ b/architect/specs/process-api-layered-extraction.feature @@ -1,14 +1,14 @@ -@libar-docs -@libar-docs-pattern:ProcessAPILayeredExtraction -@libar-docs-status:completed -@libar-docs-unlock-reason:PR28-review-structural-fixes -@libar-docs-phase:100 -@libar-docs-effort:2d -@libar-docs-product-area:DataAPI -@libar-docs-include:process-workflow -@libar-docs-depends-on:ValidatorReadModelConsolidation -@libar-docs-business-value:separate-cli-shell-from-domain-logic-in-process-api -@libar-docs-priority:high +@architect +@architect-pattern:ProcessAPILayeredExtraction +@architect-status:completed +@architect-unlock-reason:PR28-review-structural-fixes +@architect-phase:100 +@architect-effort:2d +@architect-product-area:DataAPI +@architect-include:process-workflow +@architect-depends-on:ValidatorReadModelConsolidation +@architect-business-value:separate-cli-shell-from-domain-logic-in-process-api +@architect-priority:high Feature: Process API Layered Extraction **Problem:** diff --git a/delivery-process/specs/process-guard-linter.feature b/architect/specs/process-guard-linter.feature similarity index 91% rename from delivery-process/specs/process-guard-linter.feature rename to architect/specs/process-guard-linter.feature index 06941462..3b4d2ed4 100644 --- a/delivery-process/specs/process-guard-linter.feature +++ b/architect/specs/process-guard-linter.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:ProcessGuardLinter -@libar-docs-status:completed -@libar-docs-unlock-reason:Complete-deliverables-for-v1.0.0-release -@libar-docs-phase:99 -@libar-docs-release:v1.0.0 -@libar-docs-effort:1d -@libar-docs-product-area:Validation -@libar-docs-business-value:prevent-accidental-scope-creep-and-locked-file-modifications -@libar-docs-priority:high +@architect +@architect-pattern:ProcessGuardLinter +@architect-status:completed +@architect-unlock-reason:Complete-deliverables-for-v1.0.0-release +@architect-phase:99 +@architect-release:v1.0.0 +@architect-effort:1d +@architect-product-area:Validation +@architect-business-value:prevent-accidental-scope-creep-and-locked-file-modifications +@architect-priority:high Feature: Process Guard Linter **Problem:** @@ -32,7 +32,7 @@ Feature: Process Guard Linter - Decider logic is pure (no I/O), enabling unit testing - Integrates with existing lint infrastructure (`lint-process.ts`) - Warnings for soft rules, errors for hard rules - - Escape hatch via `@libar-docs-unlock-reason` annotation + - Escape hatch via `@architect-unlock-reason` annotation **Relationship to PDR-005:** Uses the phase-state-machine FSM as protection levels: @@ -59,16 +59,16 @@ Feature: Process Guard Linter Rule: Protection levels determine modification restrictions - **Invariant:** Every file's modification restrictions are determined solely by its `@libar-docs-status` tag, with `completed` requiring an explicit unlock reason for any change. + **Invariant:** Every file's modification restrictions are determined solely by its `@architect-status` tag, with `completed` requiring an explicit unlock reason for any change. **Rationale:** Without status-derived protection, completed and approved work can be silently overwritten by bulk edits or accidental modifications. **Verified by:** Scenario Outline: Protection level from status; Completed file modification without unlock fails; Completed file modification with unlock passes; Active file modification is allowed but scope-locked - Files inherit protection from their `@libar-docs-status` tag. Higher + Files inherit protection from their `@architect-status` tag. Higher protection levels require explicit unlock to modify. @acceptance-criteria Scenario Outline: Protection level from status - Given a feature file with @libar-docs-status: + Given a feature file with @architect-status: When deriving protection level Then protection level is "" And modification restriction is "" @@ -78,24 +78,24 @@ Feature: Process Guard Linter | roadmap | none | Fully editable | | deferred | none | Fully editable | | active | scope | Errors on new deliverables | - | completed | hard | Requires @libar-docs-unlock-reason | + | completed | hard | Requires @architect-unlock-reason | @acceptance-criteria Scenario: Completed file modification without unlock fails - Given a feature file with @libar-docs-status:completed - When modifying the file without @libar-docs-unlock-reason + Given a feature file with @architect-status:completed + When modifying the file without @architect-unlock-reason Then linting fails with "completed-protection" violation And message is "Cannot modify completed spec without unlock reason" @acceptance-criteria Scenario: Completed file modification with unlock passes - Given a feature file with @libar-docs-status:completed + Given a feature file with @architect-status:completed Then linting passes And warning indicates "Modifying completed spec: Critical bug fix" @acceptance-criteria Scenario: Active file modification is allowed but scope-locked - Given a feature file with @libar-docs-status:active + Given a feature file with @architect-status:active When modifying existing content Then linting passes But adding new deliverables triggers scope-creep violation @@ -110,13 +110,13 @@ Feature: Process Guard Linter **Rationale:** Without session scoping, bulk operations and context switches cause unintended modifications to specs outside the current work focus. **Verified by:** Session file defines modification scope; Modifying spec outside active session scope warns; Modifying explicitly excluded spec fails; No active session allows all modifications - Optional session files (`delivery-process/sessions/*.feature`) explicitly + Optional session files (`architect/sessions/*.feature`) explicitly declare which specs are in-scope for modification during a work session. If active, modifications outside scope trigger warnings or errors. @acceptance-criteria Scenario: Session file defines modification scope - Given a session file with @libar-docs-session-id:S-2026-01-09 + Given a session file with @architect-session-id:S-2026-01-09 And session status is "active" And in-scope specs are: | spec | intent | @@ -166,7 +166,7 @@ Feature: Process Guard Linter @acceptance-criteria Scenario Outline: Valid status transitions - Given a spec with current @libar-docs-status: + Given a spec with current @architect-status: When changing status to Then transition validation passes @@ -181,7 +181,7 @@ Feature: Process Guard Linter @acceptance-criteria Scenario Outline: Invalid status transitions - Given a spec with current @libar-docs-status: + Given a spec with current @architect-status: When changing status to Then linting fails with "invalid-status-transition" violation And message indicates valid transitions from "" @@ -210,7 +210,7 @@ Feature: Process Guard Linter @acceptance-criteria Scenario: Adding deliverable to active spec fails - Given a spec with @libar-docs-status:active + Given a spec with @architect-status:active And existing deliverables: | Deliverable | Status | | Task A | complete | @@ -222,7 +222,7 @@ Feature: Process Guard Linter @acceptance-criteria Scenario: Updating deliverable status in active spec passes - Given a spec with @libar-docs-status:active + Given a spec with @architect-status:active And existing deliverables: | Deliverable | Status | | Task A | pending | @@ -231,7 +231,7 @@ Feature: Process Guard Linter @acceptance-criteria Scenario: Removing deliverable from active spec warns - Given a spec with @libar-docs-status:active + Given a spec with @architect-status:active When removing a deliverable row Then linting warns with "deliverable-removed" And message is "Deliverable removed from active spec - was it completed or descoped?" @@ -255,7 +255,7 @@ Feature: Process Guard Linter @acceptance-criteria Scenario: Validate all tracked files When running "pnpm lint:process --all" - Then all delivery-process files are validated + Then all Architect files are validated And summary shows total violations and warnings @acceptance-criteria diff --git a/delivery-process/specs/process-state-api-cli.feature b/architect/specs/process-state-api-cli.feature similarity index 94% rename from delivery-process/specs/process-state-api-cli.feature rename to architect/specs/process-state-api-cli.feature index f180fc7b..729f9e95 100644 --- a/delivery-process/specs/process-state-api-cli.feature +++ b/architect/specs/process-state-api-cli.feature @@ -1,14 +1,14 @@ -@libar-docs -@libar-docs-pattern:ProcessStateAPICLI -@libar-docs-status:completed -@libar-docs-completed:2026-02-09 -@libar-docs-unlock-reason:Normalize-deliverable-status-taxonomy -@libar-docs-phase:24 -@libar-docs-product-area:DataAPI -@libar-docs-effort:2d -@libar-docs-priority:high -@libar-docs-business-value:direct-api-queries-for-planning -@libar-docs-executable-specs:tests/features/api +@architect +@architect-pattern:ProcessStateAPICLI +@architect-status:completed +@architect-completed:2026-02-09 +@architect-unlock-reason:Normalize-deliverable-status-taxonomy +@architect-phase:24 +@architect-product-area:DataAPI +@architect-effort:2d +@architect-priority:high +@architect-business-value:direct-api-queries-for-planning +@architect-executable-specs:tests/features/api Feature: ProcessStateAPI CLI - Direct Queries for Planning Sessions **Problem:** @@ -65,7 +65,7 @@ Feature: ProcessStateAPI CLI - Direct Queries for Planning Sessions | --current-work | getCurrentWork() | Shorthand for active | | --roadmap-items | getRoadmapItems() | Shorthand for roadmap | - **API:** See `@libar-dev/delivery-process/src/cli/query-state.ts` + **API:** See `@libar-dev/architect/src/cli/query-state.ts` **Verified by:** Query active patterns, Query roadmap items, Query completed patterns with limit @@ -107,7 +107,7 @@ Feature: ProcessStateAPI CLI - Direct Queries for Planning Sessions | --phase N --progress | getPhaseProgress(N) | "How complete is Phase 18?" | | --phases | getAllPhases() | "List all phases with counts" | - **API:** See `@libar-dev/delivery-process/src/cli/query-state.ts` + **API:** See `@libar-dev/architect/src/cli/query-state.ts` **Verified by:** Query patterns in a specific phase, Query phase progress, List all phases @@ -148,7 +148,7 @@ Feature: ProcessStateAPI CLI - Direct Queries for Planning Sessions | --progress | getStatusCounts() + getCompletionPercentage() | Overall progress | | --distribution | getStatusDistribution() | Detailed status breakdown | - **API:** See `@libar-dev/delivery-process/src/cli/query-state.ts` + **API:** See `@libar-dev/architect/src/cli/query-state.ts` **Verified by:** Overall progress summary, Status distribution with percentages @@ -189,7 +189,7 @@ Feature: ProcessStateAPI CLI - Direct Queries for Planning Sessions | --format text | Human-readable tables | Terminal usage | | --format json | Structured JSON | AI agent parsing, scripting | - **API:** See `@libar-dev/delivery-process/src/cli/formatters/` + **API:** See `@libar-dev/architect/src/cli/formatters/` **Verified by:** JSON output format, Text output format (default), Invalid format flag @@ -231,7 +231,7 @@ Feature: ProcessStateAPI CLI - Direct Queries for Planning Sessions | --pattern NAME --deliverables | getPatternDeliverables(name) | "What needs to be built?" | | --pattern NAME --deps | getPatternDependencies(name) | "What does this depend on?" | - **API:** See `@libar-dev/delivery-process/src/cli/query-state.ts` + **API:** See `@libar-dev/architect/src/cli/query-state.ts` **Verified by:** Lookup pattern by name, Query pattern deliverables, Pattern not found @@ -268,7 +268,7 @@ Feature: ProcessStateAPI CLI - Direct Queries for Planning Sessions without needing external documentation. Self-documenting CLIs reduce the need for Claude Code to read additional context files. - **API:** See `@libar-dev/delivery-process/src/cli/query-state.ts` + **API:** See `@libar-dev/architect/src/cli/query-state.ts` **Verified by:** Help output shows all flags, Help shows examples diff --git a/delivery-process/specs/process-state-api-relationship-queries.feature b/architect/specs/process-state-api-relationship-queries.feature similarity index 93% rename from delivery-process/specs/process-state-api-relationship-queries.feature rename to architect/specs/process-state-api-relationship-queries.feature index a03e7ad5..b9ab9122 100644 --- a/delivery-process/specs/process-state-api-relationship-queries.feature +++ b/architect/specs/process-state-api-relationship-queries.feature @@ -1,10 +1,10 @@ -@libar-docs -@libar-docs-pattern:ProcessStateAPIRelationshipQueries -@libar-docs-status:completed -@libar-docs-unlock-reason:Relationships-available-via-getPatternRelationships-superseded-by-DataAPIRelationshipGraph -@libar-docs-phase:24 -@libar-docs-product-area:DataAPI -@libar-docs-effort:3d +@architect +@architect-pattern:ProcessStateAPIRelationshipQueries +@architect-status:completed +@architect-unlock-reason:Relationships-available-via-getPatternRelationships-superseded-by-DataAPIRelationshipGraph +@architect-phase:24 +@architect-product-area:DataAPI +@architect-effort:3d Feature: ProcessStateAPI Relationship Queries **Problem:** ProcessStateAPI currently supports dependency queries (`uses`, `usedBy`, `dependsOn`, @@ -54,15 +54,15 @@ Feature: ProcessStateAPI Relationship Queries Given a pattern "ProcessGuardLinter" exists And files implement this pattern: | File | Via Tag | - | src/lint/process-guard/decider.ts | @libar-docs-implements:ProcessGuardLinter | - | src/lint/process-guard/derive-state.ts | @libar-docs-implements:ProcessGuardLinter | + | src/lint/process-guard/decider.ts | @architect-implements:ProcessGuardLinter | + | src/lint/process-guard/derive-state.ts | @architect-implements:ProcessGuardLinter | When querying getImplementations("ProcessGuardLinter") Then the result should contain both file paths And the result should be sorted alphabetically @acceptance-criteria @happy-path Scenario: Query implemented patterns for a file - Given a file "decider.ts" with tag "@libar-docs-implements:ProcessGuardLinter, ProcessGuardDecider" + Given a file "decider.ts" with tag "@architect-implements:ProcessGuardLinter, ProcessGuardDecider" When querying getImplementedPatterns("decider.ts") Then the result should contain ["ProcessGuardLinter", "ProcessGuardDecider"] @@ -128,7 +128,7 @@ Feature: ProcessStateAPI Relationship Queries **Rationale:** Claude Code often needs the complete picture: dependencies AND implementations AND inheritance. A single call reduces round-trips and context switching. - **API:** See `@libar-dev/delivery-process/src/api/process-state.ts` + **API:** See `@libar-dev/architect/src/api/process-state.ts` **Verified by:** Get all relationships, Filter by relationship type diff --git a/delivery-process/specs/progressive-governance.feature b/architect/specs/progressive-governance.feature similarity index 88% rename from delivery-process/specs/progressive-governance.feature rename to architect/specs/progressive-governance.feature index bdb4f861..14ae96c2 100644 --- a/delivery-process/specs/progressive-governance.feature +++ b/architect/specs/progressive-governance.feature @@ -1,12 +1,12 @@ @opportunity-6 -@libar-docs -@libar-docs-pattern:ProgressiveGovernance -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-effort:2d -@libar-docs-product-area:Validation -@libar-docs-business-value:filter-work-by-risk-and-priority -@libar-docs-priority:medium +@architect +@architect-pattern:ProgressiveGovernance +@architect-status:roadmap +@architect-phase:100 +@architect-effort:2d +@architect-product-area:Validation +@architect-business-value:filter-work-by-risk-and-priority +@architect-priority:medium Feature: Progressive Governance - Opt-in Richness Where It Matters **Problem:** diff --git a/delivery-process/specs/publishing-relocation.feature b/architect/specs/publishing-relocation.feature similarity index 96% rename from delivery-process/specs/publishing-relocation.feature rename to architect/specs/publishing-relocation.feature index db419b4d..68402d93 100644 --- a/delivery-process/specs/publishing-relocation.feature +++ b/architect/specs/publishing-relocation.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:PublishingRelocation -@libar-docs-status:completed -@libar-docs-phase:40 -@libar-docs-effort:0.25d -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocsConsolidationStrategy -@libar-docs-business-value:move-maintainer-only-npm-and-ci-publishing-procedures-to-correct-repo-root-audience -@libar-docs-priority:medium +@architect +@architect-pattern:PublishingRelocation +@architect-status:completed +@architect-phase:40 +@architect-effort:0.25d +@architect-product-area:Generation +@architect-depends-on:DocsConsolidationStrategy +@architect-business-value:move-maintainer-only-npm-and-ci-publishing-procedures-to-correct-repo-root-audience +@architect-priority:medium Feature: PUBLISHING.md Relocation to MAINTAINERS.md **Problem:** diff --git a/delivery-process/specs/readme-rationalization.feature b/architect/specs/readme-rationalization.feature similarity index 94% rename from delivery-process/specs/readme-rationalization.feature rename to architect/specs/readme-rationalization.feature index 115bfdce..0504ba7a 100644 --- a/delivery-process/specs/readme-rationalization.feature +++ b/architect/specs/readme-rationalization.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:ReadmeRationalization -@libar-docs-status:completed -@libar-docs-phase:42 -@libar-docs-effort:0.5d -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocsConsolidationStrategy -@libar-docs-business-value:focused-npm-landing-page -@libar-docs-priority:medium +@architect +@architect-pattern:ReadmeRationalization +@architect-status:completed +@architect-phase:42 +@architect-effort:0.5d +@architect-product-area:Generation +@architect-depends-on:DocsConsolidationStrategy +@architect-business-value:focused-npm-landing-page +@architect-priority:medium Feature: README Rationalization **Problem:** @@ -34,7 +34,7 @@ Feature: README Rationalization | Benefit | How | | Faster npm discovery | 150-line README places install within first 20 lines | | No configuration duplication | Single source of truth in docs/CONFIGURATION.md | - | Better getting-started page | Trimmed README aligns with /delivery-process/getting-started/ URL | + | Better getting-started page | Trimmed README aligns with /architect/getting-started/ URL | | Zero content loss | All enterprise pitch content already lives on the website | **Section Disposition (18 sections):** @@ -83,7 +83,7 @@ Feature: README Rationalization | Deliverable | Status | Location | Tests | Test Type | | Trim README.md to ~150 lines per section disposition table | complete | README.md | No | n/a | | Remove Configuration section (lines 441-474) duplicating docs/CONFIGURATION.md | complete | README.md | No | n/a | - | Document README-to-website component mapping for extracted enterprise sections | complete | delivery-process/specs/readme-rationalization.feature | No | n/a | + | Document README-to-website component mapping for extracted enterprise sections | complete | architect/specs/readme-rationalization.feature | No | n/a | | Verify all retained links in trimmed README resolve to valid targets | complete | README.md | No | n/a | | Update INDEX.md Quick Navigation line count for README (1-504 to ~1-150) | complete | docs/INDEX.md | No | n/a | | Verify trimmed README serves as effective getting-started page at /getting-started/ | complete | README.md | No | n/a | @@ -136,7 +136,7 @@ Feature: README Rationalization Rule: Trimmed README must serve as an effective getting-started page - **Invariant:** The website publishes README.md as /delivery-process/getting-started/ via + **Invariant:** The website publishes README.md as /architect/getting-started/ via content-manifest.mjs (line 57). After trimming, the remaining content must serve a first-time visitor arriving at that URL: install instructions, a quick annotated code example, CLI commands to run, and navigation links to deeper documentation. @@ -151,7 +151,7 @@ Feature: README Rationalization @acceptance-criteria @happy-path Scenario: Trimmed README has install instructions within first 20 lines and links to all guide documents - Given the website publishes README.md as /delivery-process/getting-started/ + Given the website publishes README.md as /architect/getting-started/ When the rationalization is complete Then install instructions appear within the first 20 lines of README.md And Quick Start steps cover annotate, generate, and enforce diff --git a/delivery-process/specs/reference-doc-showcase.feature b/architect/specs/reference-doc-showcase.feature similarity index 97% rename from delivery-process/specs/reference-doc-showcase.feature rename to architect/specs/reference-doc-showcase.feature index 4a4602d7..53aaf64e 100644 --- a/delivery-process/specs/reference-doc-showcase.feature +++ b/architect/specs/reference-doc-showcase.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:ReferenceDocShowcase -@libar-docs-status:completed -@libar-docs-phase:30 -@libar-docs-effort:13d -@libar-docs-product-area:Generation -@libar-docs-depends-on:CodecDrivenReferenceGeneration,ScopedArchitecturalView,ShapeExtraction -@libar-docs-business-value:validates-all-content-blocks-via-single-integration-document -@libar-docs-priority:high +@architect +@architect-pattern:ReferenceDocShowcase +@architect-status:completed +@architect-phase:30 +@architect-effort:13d +@architect-product-area:Generation +@architect-depends-on:CodecDrivenReferenceGeneration,ScopedArchitecturalView,ShapeExtraction +@architect-business-value:validates-all-content-blocks-via-single-integration-document +@architect-priority:high Feature: Reference Document Showcase **Problem:** @@ -70,8 +70,8 @@ Feature: Reference Document Showcase | CompositeCodec for multi-codec assembly | Complete | src/renderable/codecs/ | | renderToClaudeContext renderer | Complete | src/renderable/ | | Data-driven Gherkin tag extraction | Complete | src/scanner/gherkin-ast-parser.ts | - | Expanded sample config with all content sources | Complete | delivery-process.config.ts | - | Sample convention decision with rich content | Complete | delivery-process/decisions/ | + | Expanded sample config with all content sources | Complete | architect.config.ts | + | Sample convention decision with rich content | Complete | architect/decisions/ | Rule: Deep behavior rendering replaces shallow truncation diff --git a/delivery-process/specs/release-association-rules.feature b/architect/specs/release-association-rules.feature similarity index 75% rename from delivery-process/specs/release-association-rules.feature rename to architect/specs/release-association-rules.feature index 9bf8e0f0..8520a283 100644 --- a/delivery-process/specs/release-association-rules.feature +++ b/architect/specs/release-association-rules.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:ReleaseAssociationRules -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-effort:3h -@libar-docs-product-area:Validation -@libar-docs-business-value:enforce-separation-of-specs-from-release-metadata -@libar-docs-priority:medium +@architect +@architect-pattern:ReleaseAssociationRules +@architect-status:roadmap +@architect-phase:100 +@architect-effort:3h +@architect-product-area:Validation +@architect-business-value:enforce-separation-of-specs-from-release-metadata +@architect-priority:medium Feature: Release Association Rules Validation **Problem:** @@ -24,9 +24,9 @@ Feature: Release Association Rules Validation Background: Deliverables Given the following deliverables: | Deliverable | Status | Tests | Location | - | Spec compliance validator | pending | Yes | @libar-dev/delivery-process/src/lint/rules/ | - | TypeScript phase file validator | pending | Yes | @libar-dev/delivery-process/src/lint/rules/ | - | Release version format validator | pending | Yes | @libar-dev/delivery-process/src/validation/ | + | Spec compliance validator | pending | Yes | @libar-dev/architect/src/lint/rules/ | + | TypeScript phase file validator | pending | Yes | @libar-dev/architect/src/lint/rules/ | + | Release version format validator | pending | Yes | @libar-dev/architect/src/validation/ | Rule: Spec files must not contain release columns @@ -36,29 +36,29 @@ Feature: Release Association Rules Validation @acceptance-criteria Scenario: Spec with release column is rejected - Given a feature file in delivery-process/specs/ + Given a feature file in architect/specs/ And the deliverables DataTable has a "Release" column When validating spec compliance Then error indicates "Spec files must not contain Release column (per PDR-003)" @acceptance-criteria Scenario: Spec without release column passes - Given a feature file in delivery-process/specs/ + Given a feature file in architect/specs/ And the deliverables DataTable has only Deliverable, Status, Tests, Location When validating spec compliance Then validation passes Rule: TypeScript phase files must have required annotations - **Invariant:** Every TypeScript phase file must include @libar-docs-pattern, @libar-docs-phase, and @libar-docs-status annotations. + **Invariant:** Every TypeScript phase file must include @architect-pattern, @architect-phase, and @architect-status annotations. **Rationale:** Missing required annotations cause phase files to be invisible to the scanner, producing incomplete roadmap projections and broken cross-references. **Verified by:** Phase file with missing required annotations; Scenario Outline: Phase file required annotations @acceptance-criteria Scenario: Phase file with missing required annotations - Given a TypeScript file in delivery-process/src/phases/ - When @libar-docs-pattern is missing - Then validation fails with "Required: @libar-docs-pattern" + Given a TypeScript file in architect/src/phases/ + When @architect-pattern is missing + Then validation fails with "Required: @architect-pattern" @acceptance-criteria Scenario Outline: Phase file required annotations @@ -68,10 +68,10 @@ Feature: Release Association Rules Validation Examples: | annotation | result | - | @libar-docs-pattern | fails with "Required annotation" | - | @libar-docs-phase | fails with "Required annotation" | - | @libar-docs-status | fails with "Required annotation" | - | @libar-docs-quarter | warns "Recommended annotation" | + | @architect-pattern | fails with "Required annotation" | + | @architect-phase | fails with "Required annotation" | + | @architect-status | fails with "Required annotation" | + | @architect-quarter | warns "Recommended annotation" | Rule: Release version follows semantic versioning diff --git a/delivery-process/specs/scoped-architectural-view.feature b/architect/specs/scoped-architectural-view.feature similarity index 94% rename from delivery-process/specs/scoped-architectural-view.feature rename to architect/specs/scoped-architectural-view.feature index ae103fc7..0c7d6d7f 100644 --- a/delivery-process/specs/scoped-architectural-view.feature +++ b/architect/specs/scoped-architectural-view.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:ScopedArchitecturalView -@libar-docs-status:completed -@libar-docs-unlock-reason:Retroactive-spec-for-completed-work -@libar-docs-phase:28 -@libar-docs-effort:3d -@libar-docs-product-area:Generation -@libar-docs-depends-on:ArchitectureDiagramGeneration,ShapeExtraction -@libar-docs-business-value:enables-selective-pattern-composition-with-architecture-diagrams -@libar-docs-priority:high +@architect +@architect-pattern:ScopedArchitecturalView +@architect-status:completed +@architect-unlock-reason:Retroactive-spec-for-completed-work +@architect-phase:28 +@architect-effort:3d +@architect-product-area:Generation +@architect-depends-on:ArchitectureDiagramGeneration,ShapeExtraction +@architect-business-value:enables-selective-pattern-composition-with-architecture-diagrams +@architect-priority:high Feature: Scoped Architectural View **Problem:** diff --git a/delivery-process/specs/session-file-cleanup.feature b/architect/specs/session-file-cleanup.feature similarity index 83% rename from delivery-process/specs/session-file-cleanup.feature rename to architect/specs/session-file-cleanup.feature index fedfa942..6fd00c12 100644 --- a/delivery-process/specs/session-file-cleanup.feature +++ b/architect/specs/session-file-cleanup.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:SessionFileCleanup -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-effort:2h -@libar-docs-product-area:Process -@libar-docs-include:process-workflow -@libar-docs-depends-on:SessionFileLifecycle -@libar-docs-business-value:ensure-session-directory-only-contains-active-phase-files -@libar-docs-priority:low +@architect +@architect-pattern:SessionFileCleanup +@architect-status:roadmap +@architect-phase:100 +@architect-effort:2h +@architect-product-area:Process +@architect-include:process-workflow +@architect-depends-on:SessionFileLifecycle +@architect-business-value:ensure-session-directory-only-contains-active-phase-files +@architect-priority:low Feature: Session File Cleanup Behavior **Problem:** @@ -26,10 +26,10 @@ Feature: Session File Cleanup Behavior Background: Deliverables Given the following deliverables: | Deliverable | Status | Tests | Location | - | Cleanup trigger integration | pending | Yes | @libar-dev/delivery-process/src/generators/ | - | File pattern matching | pending | Yes | @libar-dev/delivery-process/src/utils/ | - | Error handling | pending | Yes | @libar-dev/delivery-process/src/utils/ | - | Cleanup logging | pending | Yes | @libar-dev/delivery-process/src/utils/ | + | Cleanup trigger integration | pending | Yes | @libar-dev/architect/src/generators/ | + | File pattern matching | pending | Yes | @libar-dev/architect/src/utils/ | + | Error handling | pending | Yes | @libar-dev/architect/src/utils/ | + | Cleanup logging | pending | Yes | @libar-dev/architect/src/utils/ | Rule: Cleanup triggers during session-context generation diff --git a/delivery-process/specs/session-guides-module-source.feature b/architect/specs/session-guides-module-source.feature similarity index 93% rename from delivery-process/specs/session-guides-module-source.feature rename to architect/specs/session-guides-module-source.feature index 34eaa8f7..5f43f023 100644 --- a/delivery-process/specs/session-guides-module-source.feature +++ b/architect/specs/session-guides-module-source.feature @@ -1,17 +1,17 @@ -@libar-docs -@libar-docs-pattern:SessionGuidesModuleSource -@libar-docs-status:completed -@libar-docs-unlock-reason:Add-include-tag-for-ProceduralGuideCodec -@libar-docs-phase:39 -@libar-docs-effort:0.5d -@libar-docs-product-area:Generation -@libar-docs-depends-on:ClaudeModuleGeneration,DocsConsolidationStrategy -@libar-docs-business-value:session-workflow-CLAUDE-md-section-generated-from-annotated-specs -@libar-docs-priority:medium -@libar-docs-claude-module:session-workflows -@libar-docs-claude-section:workflow -@libar-docs-claude-tags:core -@libar-docs-include:session-workflows +@architect +@architect-pattern:SessionGuidesModuleSource +@architect-status:completed +@architect-unlock-reason:Add-include-tag-for-ProceduralGuideCodec +@architect-phase:39 +@architect-effort:0.5d +@architect-product-area:Generation +@architect-depends-on:ClaudeModuleGeneration,DocsConsolidationStrategy +@architect-business-value:session-workflow-CLAUDE-md-section-generated-from-annotated-specs +@architect-priority:medium +@architect-claude-module:session-workflows +@architect-claude-section:workflow +@architect-claude-tags:core +@architect-include:session-workflows Feature: Session Guides as Annotated Module Source **Problem:** @@ -20,7 +20,7 @@ Feature: Session Guides as Annotated Module Source (session-workflows.md, session-details.md, fsm-handoff.md) are equally opaque: no machine-readable origin, no regeneration from source annotations. - The prior plan proposed tagging ADR-001, ADR-003, and PDR-001 with `@libar-docs-claude-module` + The prior plan proposed tagging ADR-001, ADR-003, and PDR-001 with `@architect-claude-module` to make them the source for generated workflow modules. Design analysis revealed this is fundamentally flawed: `claude-module` is a file-level tag that pulls ALL Rules from a file, but most Rules in those decision specs are irrelevant to session workflows (ADR-001 has 9 @@ -32,8 +32,8 @@ Feature: Session Guides as Annotated Module Source Session workflow invariants are captured as Rule: blocks here, covering session type contracts, FSM protection, execution order, error recovery, and handoff patterns. - Once ClaudeModuleGeneration (Phase 25) ships, adding `@libar-docs-claude-module` and - `@libar-docs-claude-section:workflow` tags to this spec will cause the codec to produce + Once ClaudeModuleGeneration (Phase 25) ships, adding `@architect-claude-module` and + `@architect-claude-section:workflow` tags to this spec will cause the codec to produce `_claude-md/workflow/` modules automatically. The hand-written files are then deleted and the CLAUDE.md section becomes a generated include. @@ -67,10 +67,10 @@ Feature: Session Guides as Annotated Module Source Background: Deliverables Given the following deliverables: | Deliverable | Status | Location | Tests | Test Type | - | Session workflow behavior spec with Rule blocks (session types, FSM contracts, escape hatches, handoff) | complete | delivery-process/specs/session-guides-module-source.feature | No | n/a | + | Session workflow behavior spec with Rule blocks (session types, FSM contracts, escape hatches, handoff) | complete | architect/specs/session-guides-module-source.feature | No | n/a | | Verify SESSION-GUIDES.md retained with correct INDEX.md links | complete | docs/SESSION-GUIDES.md | No | n/a | - | Add workflow to Phase 25 claude-section enum | complete | delivery-process/specs/claude-module-generation.feature | No | n/a | - | Add claude-module and claude-section:workflow tags to this spec | complete | delivery-process/specs/session-guides-module-source.feature | No | n/a | + | Add workflow to Phase 25 claude-section enum | complete | architect/specs/claude-module-generation.feature | No | n/a | + | Add claude-module and claude-section:workflow tags to this spec | complete | architect/specs/session-guides-module-source.feature | No | n/a | | Generated _claude-md/workflow/session-workflows.md replaces hand-written version | complete | _claude-md/workflow/session-workflows.md | No | n/a | | Generated _claude-md/workflow/fsm-handoff.md replaces hand-written version | complete | _claude-md/workflow/fsm-handoff.md | No | n/a | | CLAUDE.md Session Workflows section replaced with modular-claude-md include | complete | CLAUDE.md | No | n/a | @@ -199,7 +199,7 @@ Feature: Session Guides as Annotated Module Source Process Data API must precede any explore agent usage. **Rationale:** Design sessions resolve ambiguity before implementation begins. Code - stubs in delivery-process/stubs/ live outside src/ to avoid TypeScript compilation + stubs in architect/stubs/ live outside src/ to avoid TypeScript compilation and ESLint issues, making them zero-risk artifacts. **Verified by:** Design session output constraints @@ -213,7 +213,7 @@ Feature: Session Guides as Annotated Module Source Scenario: Design session output constraints Given a design session for a pattern with multiple valid approaches When the session completes - Then code stubs exist in delivery-process/stubs/ + Then code stubs exist in architect/stubs/ And no implementation code was written in src/ And decision rationale is captured in Rule: blocks @@ -328,7 +328,7 @@ Feature: Session Guides as Annotated Module Source Rule: ClaudeModuleGeneration is the generation mechanism **Invariant:** Phase 39 depends on ClaudeModuleGeneration (Phase 25). Adding - `@libar-docs-claude-module` and `@libar-docs-claude-section:workflow` tags to + `@architect-claude-module` and `@architect-claude-section:workflow` tags to this spec will cause ClaudeModuleGeneration to produce `_claude-md/workflow/` output files. The hand-written `_claude-md/workflow/` files are deleted after successful verified generation. diff --git a/delivery-process/specs/setup-command.feature b/architect/specs/setup-command.feature similarity index 84% rename from delivery-process/specs/setup-command.feature rename to architect/specs/setup-command.feature index 19baa824..48ee3839 100644 --- a/delivery-process/specs/setup-command.feature +++ b/architect/specs/setup-command.feature @@ -1,19 +1,19 @@ -@libar-docs -@libar-docs-pattern:SetupCommand -@libar-docs-status:roadmap -@libar-docs-phase:45 -@libar-docs-product-area:Configuration -@libar-docs-effort:3d -@libar-docs-priority:high -@libar-docs-depends-on:ConfigLoader -@libar-docs-business-value:reduce-first-project-setup-from-55-minutes-to-under-2-minutes -@libar-docs-sequence-orchestrator:init-cli +@architect +@architect-pattern:SetupCommand +@architect-status:roadmap +@architect-phase:45 +@architect-product-area:Configuration +@architect-effort:3d +@architect-priority:high +@architect-depends-on:ConfigLoader +@architect-business-value:reduce-first-project-setup-from-55-minutes-to-under-2-minutes +@architect-sequence-orchestrator:init-cli Feature: Interactive Setup Command **Problem:** - Setting up a new project to use delivery-process requires 7 manual steps spanning + Setting up a new project to use Architect requires 7 manual steps spanning ~55 minutes: install the package plus dev dependencies, create tsconfig.json with - correct module settings, create delivery-process.config.ts with defineConfig() and + correct module settings, create architect.config.ts with defineConfig() and correct source globs, add 15+ npm scripts to package.json, create directory structure, and annotate the first file with the correct opt-in marker and tags. @@ -25,7 +25,7 @@ Feature: Interactive Setup Command **Solution:** Add an interactive setup CLI invoked via npx: - npx @libar-dev/delivery-process init + npx @libar-dev/architect init The command detects existing project context (package.json, TypeScript config, monorepo markers), asks the user to select a preset, and generates all required @@ -45,12 +45,12 @@ Feature: Interactive Setup Command | Init CLI entry point | pending | src/cli/init.ts | | Bin entry registration | pending | package.json | - @libar-docs-sequence-step:1 - @libar-docs-sequence-module:detect-context + @architect-sequence-step:1 + @architect-sequence-module:detect-context Rule: Init detects existing project context before making changes **Invariant:** The init command reads the target directory for package.json, - tsconfig.json, delivery-process.config.ts (or .js), and monorepo markers before prompting + tsconfig.json, architect.config.ts (or .js), and monorepo markers before prompting or generating any files. Detection results determine which steps are skipped. **Rationale:** Blindly generating files overwrites user configuration and breaks @@ -74,15 +74,15 @@ Feature: Interactive Setup Command And the command does not modify tsconfig.json And the command proceeds to preset selection - @acceptance-criteria @validation @libar-docs-sequence-error + @acceptance-criteria @validation @architect-sequence-error Scenario: Fails gracefully when no package.json exists Given an empty directory with no package.json When running the init command Then the command prints "No package.json found. Run npm init first." And exits with code 1 - @libar-docs-sequence-step:2 - @libar-docs-sequence-module:prompts + @architect-sequence-step:2 + @architect-sequence-module:prompts Rule: Interactive prompts configure preset and source paths with smart defaults **Invariant:** The init command prompts for preset selection from the three @@ -122,18 +122,18 @@ Feature: Interactive Setup Command And preset defaults to "libar-generic" And source globs use sensible defaults - @acceptance-criteria @validation @libar-docs-sequence-error + @acceptance-criteria @validation @architect-sequence-error Scenario: Non-interactive mode refuses to overwrite existing config - Given a directory with an existing delivery-process config file + Given a directory with an existing Architect config file When running the init command with --yes flag Then the command prints a message requiring --force to overwrite And exits with code 1 - @libar-docs-sequence-step:3 - @libar-docs-sequence-module:generate-config + @architect-sequence-step:3 + @architect-sequence-module:generate-config Rule: Generated config file uses defineConfig with correct imports - **Invariant:** The generated delivery-process.config.ts (or .js) imports + **Invariant:** The generated architect.config.ts (or .js) imports defineConfig from the correct path, uses the selected preset, and includes configured source globs. An existing config file is never overwritten without confirmation. @@ -144,7 +144,7 @@ Feature: Interactive Setup Command **Input:** InitConfig - **Output:** delivery-process.config.ts written to targetDir + **Output:** architect.config.ts written to targetDir **Verified by:** Generated config is valid TypeScript, Existing config is not overwritten without confirmation @@ -154,19 +154,19 @@ Feature: Interactive Setup Command Given the user selected preset "libar-generic" And TypeScript source glob is "src/**/*.ts" When the config file is generated - Then delivery-process.config.ts imports from "@libar-dev/delivery-process/config" + Then architect.config.ts imports from "@libar-dev/architect/config" And contains defineConfig with the selected preset And contains the configured source globs - @acceptance-criteria @validation @libar-docs-sequence-error + @acceptance-criteria @validation @architect-sequence-error Scenario: Existing config file is not overwritten without confirmation - Given a directory with an existing delivery-process config file + Given a directory with an existing Architect config file When running the init command Then the command prompts for overwrite confirmation And answering "no" preserves the existing file - @libar-docs-sequence-step:4 - @libar-docs-sequence-module:augment-package-json + @architect-sequence-step:4 + @architect-sequence-module:augment-package-json Rule: Npm scripts are injected using bin command names **Invariant:** Injected scripts reference bin names (process-api, generate-docs) @@ -186,7 +186,7 @@ Feature: Interactive Setup Command @acceptance-criteria @happy-path Scenario: Injected scripts use bin command names - Given a package.json with no delivery-process scripts + Given a package.json with no Architect scripts When the init command injects scripts Then package.json contains process:query using "process-api" And contains docs:all using "generate-docs" @@ -199,8 +199,8 @@ Feature: Interactive Setup Command Then existing scripts are unchanged And new process and docs scripts are added alongside them - @libar-docs-sequence-step:5 - @libar-docs-sequence-module:scaffold-dirs,generate-example + @architect-sequence-step:5 + @architect-sequence-module:scaffold-dirs,generate-example Rule: Directory structure and example annotation enable immediate first run **Invariant:** The init command creates directories for configured source globs @@ -223,8 +223,8 @@ Feature: Interactive Setup Command When running process-api overview Then the output shows 1 pattern detected - @libar-docs-sequence-step:6 - @libar-docs-sequence-module:validate-setup + @architect-sequence-step:6 + @architect-sequence-module:validate-setup Rule: Init validates the complete setup by running the pipeline **Invariant:** After all files are generated, init runs process-api overview and @@ -250,7 +250,7 @@ Feature: Interactive Setup Command And prints next steps for annotating files and generating docs And exits with code 0 - @acceptance-criteria @validation @libar-docs-sequence-error + @acceptance-criteria @validation @architect-sequence-error Scenario: Failed validation prints diagnostic information Given init completed but the example file has an invalid glob match When the validation step detects 0 patterns diff --git a/delivery-process/specs/shape-extraction.feature b/architect/specs/shape-extraction.feature similarity index 89% rename from delivery-process/specs/shape-extraction.feature rename to architect/specs/shape-extraction.feature index 7b597774..ca1fbdc1 100644 --- a/delivery-process/specs/shape-extraction.feature +++ b/architect/specs/shape-extraction.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:ShapeExtraction -@libar-docs-status:completed -@libar-docs-unlock-reason:Fix-code-fence-formatting-per-PR-review -@libar-docs-phase:26 -@libar-docs-effort:2d -@libar-docs-product-area:Annotation -@libar-docs-enables:DocGenerationProofOfConcept -@libar-docs-business-value:eliminates-type-duplication-in-documentation -@libar-docs-priority:high +@architect +@architect-pattern:ShapeExtraction +@architect-status:completed +@architect-unlock-reason:Fix-code-fence-formatting-per-PR-review +@architect-phase:26 +@architect-effort:2d +@architect-product-area:Annotation +@architect-enables:DocGenerationProofOfConcept +@architect-business-value:eliminates-type-duplication-in-documentation +@architect-priority:high Feature: TypeScript Shape Extraction for Documentation **Problem:** @@ -24,7 +24,7 @@ Feature: TypeScript Shape Extraction for Documentation Current pattern (duplication): """typescript /** - * @libar-docs + * @architect * * ## API * @@ -45,15 +45,15 @@ Feature: TypeScript Shape Extraction for Documentation """ **Solution:** - New tag `@libar-docs-extract-shapes` lists type names to extract from the same file. + New tag `@architect-extract-shapes` lists type names to extract from the same file. The extractor pulls actual TypeScript definitions from AST and inserts them into generated documentation as fenced code blocks. Target pattern (single source): """typescript /** - * @libar-docs - * @libar-docs-extract-shapes DeciderInput, ValidationResult + * @architect + * @architect-extract-shapes DeciderInput, ValidationResult * * ## API * @@ -110,7 +110,7 @@ Feature: TypeScript Shape Extraction for Documentation Rule: Interfaces are extracted from TypeScript AST - **Invariant:** When `@libar-docs-extract-shapes` lists an interface name, + **Invariant:** When `@architect-extract-shapes` lists an interface name, the extractor must find and extract the complete interface definition including JSDoc comments, generics, and extends clauses. **Rationale:** Partial extraction (missing generics, JSDoc, or extends clauses) produces incomplete API documentation that misleads consumers about a type's actual contract. @@ -120,8 +120,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes MyConfig + * @architect + * @architect-extract-shapes MyConfig */ export interface MyConfig { @@ -144,8 +144,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes ConfigOptions + * @architect + * @architect-extract-shapes ConfigOptions */ /** Configuration for the processor. */ @@ -163,8 +163,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes Result + * @architect + * @architect-extract-shapes Result */ export interface Result { @@ -180,8 +180,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes ExtendedConfig + * @architect + * @architect-extract-shapes ExtendedConfig */ export interface ExtendedConfig extends BaseConfig { @@ -196,8 +196,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes NonExistent + * @architect + * @architect-extract-shapes NonExistent */ """ When extracting shapes @@ -219,8 +219,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes Status + * @architect + * @architect-extract-shapes Status */ export type Status = 'pending' | 'active' | 'completed'; @@ -237,8 +237,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes Readonly + * @architect + * @architect-extract-shapes Readonly */ export type Readonly = { readonly [K in keyof T]: T[K] }; @@ -251,8 +251,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes Unwrap + * @architect + * @architect-extract-shapes Unwrap */ export type Unwrap = T extends Promise ? U : T; @@ -275,8 +275,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes Severity + * @architect + * @architect-extract-shapes Severity */ export enum Severity { @@ -294,8 +294,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes Direction + * @architect + * @architect-extract-shapes Direction */ export const enum Direction { @@ -324,8 +324,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes validateChanges + * @architect + * @architect-extract-shapes validateChanges */ export function validateChanges(input: DeciderInput): DeciderOutput { @@ -346,8 +346,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes fetchData + * @architect + * @architect-extract-shapes fetchData */ export async function fetchData(url: string): Promise { @@ -362,8 +362,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes createValidator + * @architect + * @architect-extract-shapes createValidator */ export const createValidator: (rules: Rule[]) => Validator = (rules) => { @@ -388,8 +388,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes Output, Input, Options + * @architect + * @architect-extract-shapes Output, Input, Options */ export interface Input { /* first in source */ } @@ -404,8 +404,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes Status, Config, validate + * @architect + * @architect-extract-shapes Status, Config, validate */ export type Status = 'ok' | 'error'; @@ -468,8 +468,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes MyHandler + * @architect + * @architect-extract-shapes MyHandler */ import { Request, Response } from './types.js'; @@ -484,7 +484,7 @@ Feature: TypeScript Shape Extraction for Documentation @acceptance-criteria @validation Scenario: Shape extraction does not follow imports - Given `@libar-docs-extract-shapes Request` where Request is imported + Given `@architect-extract-shapes Request` where Request is imported When extracting shapes Then warning: "Shape 'Request' is imported, not defined in this file" And suggestion: "Add extract-shapes to the source file" @@ -494,8 +494,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes Foo + * @architect + * @architect-extract-shapes Foo */ // Re-export from another file @@ -505,7 +505,7 @@ Feature: TypeScript Shape Extraction for Documentation When extracting shapes for "Foo" Then warning: "Shape 'Foo' is re-exported, not defined in this file" And the shape is NOT extracted - And suggestion: "Add @libar-docs-extract-shapes to ./types.js instead" + And suggestion: "Add @architect-extract-shapes to ./types.js instead" # ============================================================================ # RULE 9: Overloaded Functions @@ -522,8 +522,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes validate + * @architect + * @architect-extract-shapes validate */ export function validate(input: string): boolean; @@ -545,8 +545,8 @@ Feature: TypeScript Shape Extraction for Documentation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-extract-shapes Parser + * @architect + * @architect-extract-shapes Parser */ export interface Parser { diff --git a/delivery-process/specs/status-aware-eslint-suppression.feature b/architect/specs/status-aware-eslint-suppression.feature similarity index 87% rename from delivery-process/specs/status-aware-eslint-suppression.feature rename to architect/specs/status-aware-eslint-suppression.feature index 681f4dc0..8dc781f0 100644 --- a/delivery-process/specs/status-aware-eslint-suppression.feature +++ b/architect/specs/status-aware-eslint-suppression.feature @@ -1,14 +1,14 @@ -@libar-docs -@libar-docs-pattern:StatusAwareEslintSuppression -@libar-docs-status:roadmap -@libar-docs-phase:99 -@libar-docs-effort:2d -@libar-docs-product-area:Validation -@libar-docs-executable-specs:tests/features/behavior/status-aware-eslint +@architect +@architect-pattern:StatusAwareEslintSuppression +@architect-status:roadmap +@architect-phase:99 +@architect-effort:2d +@architect-product-area:Validation +@architect-executable-specs:tests/features/behavior/status-aware-eslint Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxation **Problem:** - Design artifacts (code stubs with `@libar-docs-status roadmap`) intentionally have unused + Design artifacts (code stubs with `@architect-status roadmap`) intentionally have unused exports that define API shapes before implementation. Current workaround uses directory-based ESLint exclusions which: - Don't account for status transitions (roadmap -> active -> completed) @@ -17,7 +17,7 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio **Solution:** Extend the Process Guard Linter infrastructure with an ESLint integration that: - 1. Reads `@libar-docs-status` from file-level JSDoc comments + 1. Reads `@architect-status` from file-level JSDoc comments 2. Maps status to protection level using existing `deriveProcessState()` 3. Generates dynamic ESLint configuration or filters messages at runtime 4. Removes the need for directory-based exclusions entirely @@ -32,10 +32,10 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio Background: Deliverables Given the following deliverables: | Deliverable | Status | Location | Tests | Test Type | - | ESLint processor plugin | pending | @libar-dev/delivery-process/src/eslint/processor.ts | Yes | unit | - | Status-to-config mapper | pending | @libar-dev/delivery-process/src/eslint/status-config.ts | Yes | unit | - | ESLint plugin entry point | pending | @libar-dev/delivery-process/src/eslint/index.ts | Yes | unit | - | CLI command for ignore list | pending | @libar-dev/delivery-process/src/cli/eslint-ignores.ts | Yes | unit | + | ESLint processor plugin | pending | @libar-dev/architect/src/eslint/processor.ts | Yes | unit | + | Status-to-config mapper | pending | @libar-dev/architect/src/eslint/status-config.ts | Yes | unit | + | ESLint plugin entry point | pending | @libar-dev/architect/src/eslint/index.ts | Yes | unit | + | CLI command for ignore list | pending | @libar-dev/architect/src/cli/eslint-ignores.ts | Yes | unit | | Root eslint.config.js update | pending | eslint.config.js | No | - | | Directory exclusion removal | pending | eslint.config.js (lines 30-57) | No | - | @@ -45,7 +45,7 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio Rule: File status determines unused-vars enforcement - **Invariant:** Files with `@libar-docs-status roadmap` or `deferred` have relaxed + **Invariant:** Files with `@architect-status roadmap` or `deferred` have relaxed unused-vars rules. Files with `active`, `completed`, or no status have strict enforcement. **Rationale:** Design artifacts (roadmap stubs) define API shapes that are intentionally @@ -66,9 +66,9 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio Given a TypeScript file with JSDoc containing: """typescript /** - * @libar-docs - * @libar-docs-pattern ReservationPattern - * @libar-docs-status roadmap + * @architect + * @architect-pattern ReservationPattern + * @architect-status roadmap */ export interface ReservationResult { reservationId: string; @@ -87,9 +87,9 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio Given a TypeScript file with JSDoc containing: """typescript /** - * @libar-docs - * @libar-docs-pattern CMSDualWrite - * @libar-docs-status completed + * @architect + * @architect-pattern CMSDualWrite + * @architect-status completed */ export interface CMSState { id: string; @@ -101,7 +101,7 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio @acceptance-criteria @validation Scenario: File without status tag has strict rules - Given a TypeScript file without any @libar-docs-status tag + Given a TypeScript file without any @architect-status tag When ESLint processes the file with the status-aware processor Then unused exports ARE reported as errors And the default strict configuration applies @@ -142,7 +142,7 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio @acceptance-criteria @happy-path Scenario: Protection level matches Process Guard derivation - Given a file with @libar-docs-status:roadmap + Given a file with @architect-status:roadmap When Process Guard derives protection level And ESLint processor derives protection level Then both return "none" @@ -186,7 +186,7 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio @acceptance-criteria @validation Scenario: No source code modification occurs - Given a TypeScript file with @libar-docs-status:roadmap + Given a TypeScript file with @architect-status:roadmap When the processor runs Then file content on disk is unchanged And no eslint-disable comments are present in the file @@ -240,7 +240,7 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio Rule: Replaces directory-based ESLint exclusions **Invariant:** After implementation, the directory-based exclusions in eslint.config.js - (lines 30-57) are removed. All suppression is driven by @libar-docs-status annotations. + (lines 30-57) are removed. All suppression is driven by @architect-status annotations. **Rationale:** Directory-based exclusions are tech debt: - They don't account for file lifecycle (roadmap -> completed) @@ -252,7 +252,7 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio // eslint.config.js - directory-based exclusions pattern { files: [ - "**/delivery-process/stubs/**", + "**/architect/stubs/**", // ... patterns for roadmap/deferred files ], rules: { @@ -264,7 +264,7 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio **Target State:** """javascript // eslint.config.js - import { statusAwareProcessor } from "@libar-dev/delivery-process/eslint"; + import { statusAwareProcessor } from "@libar-dev/architect/eslint"; { files: ["**/*.ts", "**/*.tsx"], @@ -287,11 +287,11 @@ Feature: Status-Aware ESLint Suppression - Annotation-Driven Lint Rule Relaxatio Scenario: Existing roadmap files still pass lint Given roadmap files that previously relied on directory exclusions: | File | - | delivery-process/stubs/reservation-pattern/reservation-pattern.ts | - | delivery-process/stubs/durability-types/durability-types.ts | + | architect/stubs/reservation-pattern/reservation-pattern.ts | + | architect/stubs/durability-types/durability-types.ts | When running "pnpm lint" after migration Then files pass lint (no unused-vars errors) - And files have @libar-docs-status:roadmap annotations + And files have @architect-status:roadmap annotations # =========================================================================== # RULE 6: Configurable rule relaxation diff --git a/delivery-process/specs/step-definition-completion.feature b/architect/specs/step-definition-completion.feature similarity index 96% rename from delivery-process/specs/step-definition-completion.feature rename to architect/specs/step-definition-completion.feature index ed0b2358..324c0db7 100644 --- a/delivery-process/specs/step-definition-completion.feature +++ b/architect/specs/step-definition-completion.feature @@ -1,14 +1,14 @@ -@libar-docs -@libar-docs-pattern:StepDefinitionCompletion -@libar-docs-status:roadmap -@libar-docs-phase:103 -@libar-docs-effort:2d -@libar-docs-product-area:Process -@libar-docs-include:process-workflow -@libar-docs-depends-on:ADR002GherkinOnlyTesting -@libar-docs-business-value:make-existing-behavior-specs-executable -@libar-docs-priority:critical -@libar-docs-executable-specs:tests/steps/behavior +@architect +@architect-pattern:StepDefinitionCompletion +@architect-status:roadmap +@architect-phase:103 +@architect-effort:2d +@architect-product-area:Process +@architect-include:process-workflow +@architect-depends-on:ADR002GherkinOnlyTesting +@architect-business-value:make-existing-behavior-specs-executable +@architect-priority:critical +@architect-executable-specs:tests/steps/behavior Feature: Step Definition Completion **Problem:** diff --git a/delivery-process/specs/step-lint-extended-rules.feature b/architect/specs/step-lint-extended-rules.feature similarity index 95% rename from delivery-process/specs/step-lint-extended-rules.feature rename to architect/specs/step-lint-extended-rules.feature index ad4af35d..faf55b71 100644 --- a/delivery-process/specs/step-lint-extended-rules.feature +++ b/architect/specs/step-lint-extended-rules.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:StepLintExtendedRules -@libar-docs-status:completed -@libar-docs-unlock-reason:Retroactive-completion -@libar-docs-phase:51 -@libar-docs-effort:1d -@libar-docs-depends-on:StepLintVitestCucumber -@libar-docs-product-area:Validation -@libar-docs-business-value:catch-remaining-vitest-cucumber-traps-statically -@libar-docs-priority:high +@architect +@architect-pattern:StepLintExtendedRules +@architect-status:completed +@architect-unlock-reason:Retroactive-completion +@architect-phase:51 +@architect-effort:1d +@architect-depends-on:StepLintVitestCucumber +@architect-product-area:Validation +@architect-business-value:catch-remaining-vitest-cucumber-traps-statically +@architect-priority:high Feature: Step Lint Extended Rules - Additional vitest-cucumber Traps **Problem:** diff --git a/delivery-process/specs/step-lint-vitest-cucumber.feature b/architect/specs/step-lint-vitest-cucumber.feature similarity index 97% rename from delivery-process/specs/step-lint-vitest-cucumber.feature rename to architect/specs/step-lint-vitest-cucumber.feature index 4f6f4177..67f708ff 100644 --- a/delivery-process/specs/step-lint-vitest-cucumber.feature +++ b/architect/specs/step-lint-vitest-cucumber.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:StepLintVitestCucumber -@libar-docs-status:completed -@libar-docs-phase:50 -@libar-docs-effort:1d -@libar-docs-product-area:Validation -@libar-docs-business-value:prevent-hours-lost-debugging-vitest-cucumber-traps -@libar-docs-priority:high +@architect +@architect-pattern:StepLintVitestCucumber +@architect-status:completed +@architect-phase:50 +@architect-effort:1d +@architect-product-area:Validation +@architect-business-value:prevent-hours-lost-debugging-vitest-cucumber-traps +@architect-priority:high Feature: Step Lint - vitest-cucumber Static Compatibility Checker **Problem:** diff --git a/delivery-process/specs/streaming-git-diff.feature b/architect/specs/streaming-git-diff.feature similarity index 94% rename from delivery-process/specs/streaming-git-diff.feature rename to architect/specs/streaming-git-diff.feature index 2ad71f3f..607151a0 100644 --- a/delivery-process/specs/streaming-git-diff.feature +++ b/architect/specs/streaming-git-diff.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:StreamingGitDiff -@libar-docs-status:roadmap -@libar-docs-phase:99 -@libar-docs-effort:2d -@libar-docs-product-area:Validation -@libar-docs-business-value:enable-process-guard-on-large-repositories -@libar-docs-priority:high -@libar-docs-depends-on:ProcessGuardLinter +@architect +@architect-pattern:StreamingGitDiff +@architect-status:roadmap +@architect-phase:99 +@architect-effort:2d +@architect-product-area:Validation +@architect-business-value:enable-process-guard-on-large-repositories +@architect-priority:high +@architect-depends-on:ProcessGuardLinter Feature: Streaming Git Diff for Process Guard **Problem:** diff --git a/delivery-process/specs/traceability-enhancements.feature b/architect/specs/traceability-enhancements.feature similarity index 82% rename from delivery-process/specs/traceability-enhancements.feature rename to architect/specs/traceability-enhancements.feature index f65da277..e8c571c3 100644 --- a/delivery-process/specs/traceability-enhancements.feature +++ b/architect/specs/traceability-enhancements.feature @@ -1,13 +1,13 @@ @opportunity-4 -@libar-docs -@libar-docs-pattern:TraceabilityEnhancements -@libar-docs-status:roadmap -@libar-docs-phase:100 -@libar-docs-effort:3d -@libar-docs-product-area:Generation -@libar-docs-business-value:detect-coverage-gaps-and-requirements-drift -@libar-docs-priority:medium -@libar-docs-depends-on:TraceabilityGenerator +@architect +@architect-pattern:TraceabilityEnhancements +@architect-status:roadmap +@architect-phase:100 +@architect-effort:3d +@architect-product-area:Generation +@architect-business-value:detect-coverage-gaps-and-requirements-drift +@architect-priority:medium +@architect-depends-on:TraceabilityGenerator Feature: Traceability Enhancements - Requirements ↔ Tests Loop **Problem:** diff --git a/delivery-process/specs/traceability-generator.feature b/architect/specs/traceability-generator.feature similarity index 93% rename from delivery-process/specs/traceability-generator.feature rename to architect/specs/traceability-generator.feature index 88626d55..8357f0a5 100644 --- a/delivery-process/specs/traceability-generator.feature +++ b/architect/specs/traceability-generator.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:TraceabilityGenerator -@libar-docs-status:roadmap -@libar-docs-phase:18 -@libar-docs-effort:2d -@libar-docs-product-area:Generation +@architect +@architect-pattern:TraceabilityGenerator +@architect-status:roadmap +@architect-phase:18 +@architect-effort:2d +@architect-product-area:Generation Feature: Traceability Generator - Rule-to-Scenario Coverage via Codec **Problem:** @@ -28,7 +28,7 @@ Feature: Traceability Generator - Rule-to-Scenario Coverage via Codec | Annotation parser | `src/renderable/codecs/helpers.ts` parseBusinessRuleAnnotations() | Exists | | TraceabilityCodec | `src/renderable/codecs/reporting.ts` | Exists (timeline coverage only) | | Codec registry | `src/renderable/generate.ts` | Registered as 'traceability' | - | Config wiring | `delivery-process.config.ts` | NOT wired | + | Config wiring | `architect.config.ts` | NOT wired | | npm script | `package.json` docs:traceability | NOT wired | Background: Deliverables @@ -38,7 +38,7 @@ Feature: Traceability Generator - Rule-to-Scenario Coverage via Codec | CLI integration | complete | src/renderable/generate.ts | Yes | unit | | Rule-to-Scenario cross-reference | pending | src/renderable/codecs/reporting.ts | Yes | unit | | Coverage gap detection | pending | src/renderable/codecs/reporting.ts | Yes | unit | - | Config pipeline wiring | pending | delivery-process.config.ts | No | - | + | Config pipeline wiring | pending | architect.config.ts | No | - | | docs:traceability npm script | pending | package.json | No | - | # =========================================================================== @@ -146,10 +146,10 @@ Feature: Traceability Generator - Rule-to-Scenario Coverage via Codec **Invariant:** The TraceabilityCodec output is generated as part of `pnpm docs:all` via a `docs:traceability` npm script backed by a ReferenceDocConfig entry in - `delivery-process.config.ts`. The output file lands in `docs-live/TRACEABILITY.md`. + `architect.config.ts`. The output file lands in `docs-live/TRACEABILITY.md`. **Rationale:** The TraceabilityCodec is registered in the CodecRegistry but not - wired into `delivery-process.config.ts` or `package.json`. Without config wiring, + wired into `architect.config.ts` or `package.json`. Without config wiring, the codec is only usable programmatically or via tests. Adding it to the docs pipeline makes traceability output a first-class generated artifact alongside CHANGELOG.md, OVERVIEW.md, and other reporting codecs. @@ -158,7 +158,7 @@ Feature: Traceability Generator - Rule-to-Scenario Coverage via Codec @acceptance-criteria @happy-path Scenario: Config entry generates traceability output - Given a ReferenceDocConfig entry for traceability in delivery-process.config.ts + Given a ReferenceDocConfig entry for traceability in architect.config.ts When running `pnpm docs:traceability` Then `docs-live/TRACEABILITY.md` should be generated And it should contain a "Coverage Statistics" section diff --git a/delivery-process/specs/typescript-taxonomy-implementation.feature b/architect/specs/typescript-taxonomy-implementation.feature similarity index 95% rename from delivery-process/specs/typescript-taxonomy-implementation.feature rename to architect/specs/typescript-taxonomy-implementation.feature index 1da61cf3..c77233f1 100644 --- a/delivery-process/specs/typescript-taxonomy-implementation.feature +++ b/architect/specs/typescript-taxonomy-implementation.feature @@ -1,16 +1,16 @@ -@libar-docs -@libar-docs-pattern:TypeScriptTaxonomyImplementation -@libar-docs-status:completed -@libar-docs-unlock-reason:PR28-acceptance-criteria-tagging -@libar-docs-phase:99 -@libar-docs-release:v1.0.0 -@libar-docs-effort:4h -@libar-docs-business-value:compile-time-taxonomy-protection -@libar-docs-product-area:Annotation -@libar-docs-user-role:Developer +@architect +@architect-pattern:TypeScriptTaxonomyImplementation +@architect-status:completed +@architect-unlock-reason:PR28-acceptance-criteria-tagging +@architect-phase:99 +@architect-release:v1.0.0 +@architect-effort:4h +@architect-business-value:compile-time-taxonomy-protection +@architect-product-area:Annotation +@architect-user-role:Developer Feature: TypeScript Taxonomy Implementation - As a delivery-process developer + As an Architect developer I want taxonomy defined in TypeScript with Zod integration So that I get compile-time safety and runtime validation diff --git a/delivery-process/specs/universal-doc-generator-robustness.feature b/architect/specs/universal-doc-generator-robustness.feature similarity index 96% rename from delivery-process/specs/universal-doc-generator-robustness.feature rename to architect/specs/universal-doc-generator-robustness.feature index 394e73dd..96db9120 100644 --- a/delivery-process/specs/universal-doc-generator-robustness.feature +++ b/architect/specs/universal-doc-generator-robustness.feature @@ -1,13 +1,13 @@ -@libar-docs -@libar-docs-pattern:UniversalDocGeneratorRobustness -@libar-docs-status:completed -@libar-docs-unlock-reason:All-deliverables-implemented-and-tested -@libar-docs-phase:28 -@libar-docs-effort:2d -@libar-docs-product-area:Generation -@libar-docs-depends-on:DocGenerationProofOfConcept -@libar-docs-business-value:enables-monorepo-scale-doc-generation -@libar-docs-priority:high +@architect +@architect-pattern:UniversalDocGeneratorRobustness +@architect-status:completed +@architect-unlock-reason:All-deliverables-implemented-and-tested +@architect-phase:28 +@architect-effort:2d +@architect-product-area:Generation +@architect-depends-on:DocGenerationProofOfConcept +@architect-business-value:enables-monorepo-scale-doc-generation +@architect-priority:high Feature: Universal Document Generator - Robustness Foundation This feature transforms the PoC document generator into a production-ready diff --git a/delivery-process/specs/validator-read-model-consolidation.feature b/architect/specs/validator-read-model-consolidation.feature similarity index 81% rename from delivery-process/specs/validator-read-model-consolidation.feature rename to architect/specs/validator-read-model-consolidation.feature index 503fb7da..65f94497 100644 --- a/delivery-process/specs/validator-read-model-consolidation.feature +++ b/architect/specs/validator-read-model-consolidation.feature @@ -1,20 +1,20 @@ -@libar-docs -@libar-docs-pattern:ValidatorReadModelConsolidation -@libar-docs-status:completed -@libar-docs-phase:100 -@libar-docs-effort:3d -@libar-docs-product-area:Validation -@libar-docs-include:process-workflow,codec-transformation -@libar-docs-depends-on:ADR006SingleReadModelArchitecture -@libar-docs-business-value:eliminate-parallel-pipeline-and-relationship-blind-spots-in-validator -@libar-docs-priority:high +@architect +@architect-pattern:ValidatorReadModelConsolidation +@architect-status:completed +@architect-phase:100 +@architect-effort:3d +@architect-product-area:Validation +@architect-include:process-workflow,codec-transformation +@architect-depends-on:ADR006SingleReadModelArchitecture +@architect-business-value:eliminate-parallel-pipeline-and-relationship-blind-spots-in-validator +@architect-priority:high Feature: Validator Read Model Consolidation **Problem:** `validate-patterns.ts` is the only feature consumer that bypasses the MasterDataset. It wires its own mini-pipeline (scan + extract + ad-hoc matching), creates a lossy local type (`GherkinPatternInfo`) that discards - relationship data, and then fails to resolve `@libar-docs-implements` + relationship data, and then fails to resolve `@architect-implements` links — producing 7 false-positive warnings. This is the Parallel Pipeline anti-pattern identified in ADR-006. The @@ -32,13 +32,13 @@ Feature: Validator Read Model Consolidation **Current 7 warnings decomposed:** | Warning Pattern | Root Cause | Fix Category | - | ShapeExtractor | Has @libar-docs-implements ShapeExtraction — only resolvable via relationshipIndex | Relationship-blind | - | DecisionDocGenerator | Test feature DecisionDocGeneratorTesting has @libar-docs-implements:DecisionDocGenerator | Relationship-blind | - | ContentDeduplicator | Utility with @libar-docs-phase 28 but no Gherkin spec | Spurious phase tag | - | FileCache | Utility with @libar-docs-phase 27 but no Gherkin spec | Spurious phase tag | - | WarningCollector | Utility with @libar-docs-phase 28 but no Gherkin spec | Spurious phase tag | - | SourceMappingValidator | Utility with @libar-docs-phase 28 but no Gherkin spec | Spurious phase tag | - | SourceMapper | Utility with @libar-docs-phase 27 but no Gherkin spec | Spurious phase tag | + | ShapeExtractor | Has @architect-implements ShapeExtraction — only resolvable via relationshipIndex | Relationship-blind | + | DecisionDocGenerator | Test feature DecisionDocGeneratorTesting has @architect-implements:DecisionDocGenerator | Relationship-blind | + | ContentDeduplicator | Utility with @architect-phase 28 but no Gherkin spec | Spurious phase tag | + | FileCache | Utility with @architect-phase 27 but no Gherkin spec | Spurious phase tag | + | WarningCollector | Utility with @architect-phase 28 but no Gherkin spec | Spurious phase tag | + | SourceMappingValidator | Utility with @architect-phase 28 but no Gherkin spec | Spurious phase tag | + | SourceMapper | Utility with @architect-phase 27 but no Gherkin spec | Spurious phase tag | **Solution:** Refactor `validate-patterns.ts` to consume the MasterDataset as its @@ -88,7 +88,7 @@ Feature: Validator Read Model Consolidation **Implementation Order:** | Step | What | Verification | - | 1 | Remove @libar-docs-phase from 5 utility files | pnpm build, warnings drop from 7 to 2 | + | 1 | Remove @architect-phase from 5 utility files | pnpm build, warnings drop from 7 to 2 | | 2 | Wire MasterDataset pipeline in main() | pnpm typecheck | | 3 | Rewrite validatePatterns() to consume RuntimeMasterDataset | pnpm typecheck | | 4 | Delete GherkinPatternInfo, extractGherkinPatternInfo | pnpm typecheck, pnpm test | @@ -99,11 +99,11 @@ Feature: Validator Read Model Consolidation | File | Change | Lines Affected | | src/cli/validate-patterns.ts | Major: rewrite pipeline + validatePatterns() | ~200 lines net reduction | - | src/generators/content-deduplicator.ts | Remove @libar-docs-phase 28 | Line 6 | - | src/cache/file-cache.ts | Remove @libar-docs-phase 27 | Line 5 | - | src/generators/warning-collector.ts | Remove @libar-docs-phase 28 | Line 6 | - | src/generators/source-mapping-validator.ts | Remove @libar-docs-phase 28 | Line 6 | - | src/generators/source-mapper.ts | Remove @libar-docs-phase 27 | Line 6 | + | src/generators/content-deduplicator.ts | Remove @architect-phase 28 | Line 6 | + | src/cache/file-cache.ts | Remove @architect-phase 27 | Line 5 | + | src/generators/warning-collector.ts | Remove @architect-phase 28 | Line 6 | + | src/generators/source-mapping-validator.ts | Remove @architect-phase 28 | Line 6 | + | src/generators/source-mapper.ts | Remove @architect-phase 27 | Line 6 | **What does NOT change:** @@ -140,14 +140,14 @@ Feature: Validator Read Model Consolidation @acceptance-criteria Scenario: Implements relationships resolve in both directions Given a TS pattern "DecisionDocGenerator" - And a Gherkin feature "DecisionDocGeneratorTesting" with @libar-docs-implements:DecisionDocGenerator + And a Gherkin feature "DecisionDocGeneratorTesting" with @architect-implements:DecisionDocGenerator When running cross-source validation Then no warning is produced for "DecisionDocGenerator" And the relationship is resolved via MasterDataset.relationshipIndex @acceptance-criteria Scenario: TS pattern implementing a Gherkin spec resolves - Given a TS pattern "ShapeExtractor" with @libar-docs-implements ShapeExtraction + Given a TS pattern "ShapeExtractor" with @architect-implements ShapeExtraction And a Gherkin feature "ShapeExtraction" When running cross-source validation Then no warning is produced for "ShapeExtractor" @@ -174,7 +174,7 @@ Feature: Validator Read Model Consolidation Rule: Utility patterns without specs are not false positives - **Invariant:** Internal utility patterns that have a `@libar-docs-phase` + **Invariant:** 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. diff --git a/delivery-process/stubs/.gitkeep b/architect/stubs/.gitkeep similarity index 100% rename from delivery-process/stubs/.gitkeep rename to architect/stubs/.gitkeep diff --git a/delivery-process/stubs/DataAPIDesignSessionSupport/handoff-generator.ts b/architect/stubs/DataAPIDesignSessionSupport/handoff-generator.ts similarity index 95% rename from delivery-process/stubs/DataAPIDesignSessionSupport/handoff-generator.ts rename to architect/stubs/DataAPIDesignSessionSupport/handoff-generator.ts index 938a0e54..f669ddb7 100644 --- a/delivery-process/stubs/DataAPIDesignSessionSupport/handoff-generator.ts +++ b/architect/stubs/DataAPIDesignSessionSupport/handoff-generator.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements DataAPIDesignSessionSupport - * @libar-docs-uses ProcessStateAPI, MasterDataset, ContextFormatterImpl - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-target src/api/handoff-generator.ts - * @libar-docs-since DS-E + * @architect + * @architect-status roadmap + * @architect-implements DataAPIDesignSessionSupport + * @architect-uses ProcessStateAPI, MasterDataset, ContextFormatterImpl + * @architect-used-by ProcessAPICLIImpl + * @architect-target src/api/handoff-generator.ts + * @architect-since DS-E * * ## HandoffGenerator — Session-End State Summary * diff --git a/delivery-process/stubs/DataAPIDesignSessionSupport/scope-validator.ts b/architect/stubs/DataAPIDesignSessionSupport/scope-validator.ts similarity index 97% rename from delivery-process/stubs/DataAPIDesignSessionSupport/scope-validator.ts rename to architect/stubs/DataAPIDesignSessionSupport/scope-validator.ts index 72d54e25..5ae0fe58 100644 --- a/delivery-process/stubs/DataAPIDesignSessionSupport/scope-validator.ts +++ b/architect/stubs/DataAPIDesignSessionSupport/scope-validator.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements DataAPIDesignSessionSupport - * @libar-docs-uses ProcessStateAPI, MasterDataset, StubResolver - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-target src/api/scope-validator.ts - * @libar-docs-since DS-E + * @architect + * @architect-status roadmap + * @architect-implements DataAPIDesignSessionSupport + * @architect-uses ProcessStateAPI, MasterDataset, StubResolver + * @architect-used-by ProcessAPICLIImpl + * @architect-target src/api/scope-validator.ts + * @architect-since DS-E * * ## ScopeValidator — Pre-flight Session Readiness Checker * diff --git a/delivery-process/stubs/cli-recipe-codec/cli-recipe-generator.ts b/architect/stubs/cli-recipe-codec/cli-recipe-generator.ts similarity index 96% rename from delivery-process/stubs/cli-recipe-codec/cli-recipe-generator.ts rename to architect/stubs/cli-recipe-codec/cli-recipe-generator.ts index 60d08505..c97ee204 100644 --- a/delivery-process/stubs/cli-recipe-codec/cli-recipe-generator.ts +++ b/architect/stubs/cli-recipe-codec/cli-recipe-generator.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements CliRecipeCodec - * @libar-docs-target src/generators/built-in/cli-recipe-generator.ts + * @architect + * @architect-status roadmap + * @architect-implements CliRecipeCodec + * @architect-target src/generators/built-in/cli-recipe-generator.ts * * ## CliRecipeGenerator — Standalone Generator for CLI Recipes and Narratives * @@ -32,7 +32,7 @@ * `SectionBlock[]` that is prepended before all generated content. This * follows the proven pattern from `ReferenceDocConfig.preamble` and * `ErrorGuideCodec` design. The preamble is configured in - * `delivery-process.config.ts`, not in the generator source. + * `architect.config.ts`, not in the generator source. * * **Design Decision DD-5 (No claude-md output):** * The generator produces only `docs-live/reference/PROCESS-API-RECIPES.md`. @@ -227,7 +227,7 @@ export interface CliRecipeGeneratorConfig { /** * Static editorial sections prepended before all generated content. * Contains "Why Use This", Quick Start example, and session decision tree. - * Configured in delivery-process.config.ts. + * Configured in architect.config.ts. */ readonly preamble: readonly unknown[]; // SectionBlock[] — see src/renderable/schema.ts } @@ -243,7 +243,7 @@ export interface CliRecipeGeneratorConfig { * - Implements DocumentGenerator interface * - Consumes CLI_SCHEMA directly (no MasterDataset dependency) * - Returns OutputFile[] via standard orchestrator write path - * - Registered in delivery-process.config.ts generatorOverrides + * - Registered in architect.config.ts generatorOverrides * * Key difference from ProcessApiReferenceGenerator: * - ProcessApiReferenceGenerator reads CLIOptionGroup → produces flag tables @@ -280,7 +280,7 @@ class CliRecipeGeneratorImpl { /** * Factory function following the createXxxGenerator() convention. * - * Called from delivery-process.config.ts or generator registration. + * Called from architect.config.ts or generator registration. * Receives preamble content from config. */ export function createCliRecipeGenerator( @@ -298,7 +298,7 @@ export function createCliRecipeGenerator( * Registration follows the programmatic pattern from codec-generators.ts. * The generator is registered similarly to createProcessApiReferenceGenerator(). * - * Output directory override is set in delivery-process.config.ts: + * Output directory override is set in architect.config.ts: * ```typescript * generatorOverrides: { * 'cli-recipe': { outputDirectory: 'docs-live' }, diff --git a/delivery-process/stubs/cli-recipe-codec/recipe-data.ts b/architect/stubs/cli-recipe-codec/recipe-data.ts similarity index 97% rename from delivery-process/stubs/cli-recipe-codec/recipe-data.ts rename to architect/stubs/cli-recipe-codec/recipe-data.ts index 268049a4..32155e96 100644 --- a/delivery-process/stubs/cli-recipe-codec/recipe-data.ts +++ b/architect/stubs/cli-recipe-codec/recipe-data.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements CliRecipeCodec - * @libar-docs-target src/cli/cli-schema.ts + * @architect + * @architect-status roadmap + * @architect-implements CliRecipeCodec + * @architect-target src/cli/cli-schema.ts * * ## Recipe Data — Example Definitions for CLI_SCHEMA Extension * @@ -188,7 +188,7 @@ const SESSION_WORKFLOW_NARRATIVES: CommandNarrativeGroup = { }; // ============================================================================= -// Preamble Content Example (configured in delivery-process.config.ts) +// Preamble Content Example (configured in architect.config.ts) // ============================================================================= /** @@ -203,7 +203,7 @@ const SESSION_WORKFLOW_NARRATIVES: CommandNarrativeGroup = { * * Source: docs/PROCESS-API.md lines 13-77. * - * Note: The preamble is configured in delivery-process.config.ts, NOT in + * Note: The preamble is configured in architect.config.ts, NOT in * CLI_SCHEMA. This keeps editorial prose separate from structured command * metadata and follows the proven pattern from ReferenceDocConfig.preamble. */ diff --git a/delivery-process/stubs/cli-recipe-codec/recipe-schema.ts b/architect/stubs/cli-recipe-codec/recipe-schema.ts similarity index 98% rename from delivery-process/stubs/cli-recipe-codec/recipe-schema.ts rename to architect/stubs/cli-recipe-codec/recipe-schema.ts index 8d22a524..db9e8b13 100644 --- a/delivery-process/stubs/cli-recipe-codec/recipe-schema.ts +++ b/architect/stubs/cli-recipe-codec/recipe-schema.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements CliRecipeCodec - * @libar-docs-target src/cli/cli-schema.ts + * @architect + * @architect-status roadmap + * @architect-implements CliRecipeCodec + * @architect-target src/cli/cli-schema.ts * * ## Recipe Schema — Structured Data Model for CLI Recipes * diff --git a/delivery-process/stubs/config-based-workflow-definition/default-workflow-config.ts b/architect/stubs/config-based-workflow-definition/default-workflow-config.ts similarity index 92% rename from delivery-process/stubs/config-based-workflow-definition/default-workflow-config.ts rename to architect/stubs/config-based-workflow-definition/default-workflow-config.ts index e9a46b32..4806c3dc 100644 --- a/delivery-process/stubs/config-based-workflow-definition/default-workflow-config.ts +++ b/architect/stubs/config-based-workflow-definition/default-workflow-config.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements ConfigBasedWorkflowDefinition - * @libar-docs-product-area Configuration - * @libar-docs-target src/config/workflow-loader.ts - * @libar-docs-since DS-1 + * @architect + * @architect-status roadmap + * @architect-implements ConfigBasedWorkflowDefinition + * @architect-product-area Configuration + * @architect-target src/config/workflow-loader.ts + * @architect-since DS-1 * * ## DEFAULT_WORKFLOW_CONFIG — Inline Default Workflow Constant * diff --git a/delivery-process/stubs/data-api-architecture-queries/arch-queries.ts b/architect/stubs/data-api-architecture-queries/arch-queries.ts similarity index 97% rename from delivery-process/stubs/data-api-architecture-queries/arch-queries.ts rename to architect/stubs/data-api-architecture-queries/arch-queries.ts index b9c689d5..50dc1d6d 100644 --- a/delivery-process/stubs/data-api-architecture-queries/arch-queries.ts +++ b/architect/stubs/data-api-architecture-queries/arch-queries.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements DataAPIArchitectureQueries - * @libar-docs-uses ProcessStateAPI, MasterDataset, Pattern Scanner - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-target src/api/arch-queries.ts - * @libar-docs-since DS-D + * @architect + * @architect-status roadmap + * @architect-implements DataAPIArchitectureQueries + * @architect-uses ProcessStateAPI, MasterDataset, Pattern Scanner + * @architect-used-by ProcessAPICLIImpl + * @architect-target src/api/arch-queries.ts + * @architect-since DS-D * * ## ArchQueries — Neighborhood, Comparison, Tags, Sources, and CLI Context * diff --git a/delivery-process/stubs/data-api-architecture-queries/coverage-analyzer.ts b/architect/stubs/data-api-architecture-queries/coverage-analyzer.ts similarity index 91% rename from delivery-process/stubs/data-api-architecture-queries/coverage-analyzer.ts rename to architect/stubs/data-api-architecture-queries/coverage-analyzer.ts index 26d7b4c4..91730ec5 100644 --- a/delivery-process/stubs/data-api-architecture-queries/coverage-analyzer.ts +++ b/architect/stubs/data-api-architecture-queries/coverage-analyzer.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements DataAPIArchitectureQueries - * @libar-docs-uses Pattern Scanner, MasterDataset - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-target src/api/coverage-analyzer.ts - * @libar-docs-since DS-D + * @architect + * @architect-status roadmap + * @architect-implements DataAPIArchitectureQueries + * @architect-uses Pattern Scanner, MasterDataset + * @architect-used-by ProcessAPICLIImpl + * @architect-target src/api/coverage-analyzer.ts + * @architect-since DS-D * * ## CoverageAnalyzer — Annotation Coverage and Taxonomy Gap Detection * @@ -64,13 +64,13 @@ export interface UnusedTaxonomyReport { * Unused taxonomy: [categories, roles, layers] */ export interface CoverageReport { - /** Count of files with @libar-docs opt-in that produced patterns. */ + /** Count of files with @architect opt-in that produced patterns. */ readonly annotatedFileCount: number; /** Total .ts files found by glob (before opt-in filter). */ readonly totalScannableFiles: number; /** annotatedFileCount / totalScannableFiles * 100. */ readonly coveragePercentage: number; - /** Files matching input globs but lacking @libar-docs marker. */ + /** Files matching input globs but lacking @architect marker. */ readonly unannotatedFiles: readonly string[]; /** Taxonomy values defined but never used. */ readonly unusedTaxonomy: UnusedTaxonomyReport; @@ -117,7 +117,7 @@ export async function analyzeCoverage( * @param baseDir - Base directory for scanning * @param registry - TagRegistry for opt-in detection * @param pathFilter - Optional additional glob to narrow results (e.g., 'src/generators/**\/*.ts') - * @returns Relative paths of files without @libar-docs marker + * @returns Relative paths of files without @architect marker */ export async function findUnannotatedFiles( _inputGlobs: readonly string[], diff --git a/delivery-process/stubs/data-api-context-assembly/context-assembler.ts b/architect/stubs/data-api-context-assembly/context-assembler.ts similarity index 97% rename from delivery-process/stubs/data-api-context-assembly/context-assembler.ts rename to architect/stubs/data-api-context-assembly/context-assembler.ts index 57b33478..c5d09ef5 100644 --- a/delivery-process/stubs/data-api-context-assembly/context-assembler.ts +++ b/architect/stubs/data-api-context-assembly/context-assembler.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements DataAPIContextAssembly - * @libar-docs-uses ProcessStateAPI, MasterDataset, PatternSummarizer - * @libar-docs-used-by ProcessAPICLIImpl, ContextFormatter - * @libar-docs-target src/api/context-assembler.ts - * @libar-docs-since DS-C + * @architect + * @architect-status roadmap + * @architect-implements DataAPIContextAssembly + * @architect-uses ProcessStateAPI, MasterDataset, PatternSummarizer + * @architect-used-by ProcessAPICLIImpl, ContextFormatter + * @architect-target src/api/context-assembler.ts + * @architect-since DS-C * * ## ContextAssembler — Session-Oriented Context Bundle Builder * diff --git a/delivery-process/stubs/data-api-context-assembly/context-formatter.ts b/architect/stubs/data-api-context-assembly/context-formatter.ts similarity index 90% rename from delivery-process/stubs/data-api-context-assembly/context-formatter.ts rename to architect/stubs/data-api-context-assembly/context-formatter.ts index 09ab4aa7..b09c2310 100644 --- a/delivery-process/stubs/data-api-context-assembly/context-formatter.ts +++ b/architect/stubs/data-api-context-assembly/context-formatter.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements DataAPIContextAssembly - * @libar-docs-uses ContextAssembler - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-target src/api/context-formatter.ts - * @libar-docs-since DS-C + * @architect + * @architect-status roadmap + * @architect-implements DataAPIContextAssembly + * @architect-uses ContextAssembler + * @architect-used-by ProcessAPICLIImpl + * @architect-target src/api/context-formatter.ts + * @architect-since DS-C * * ## ContextFormatter — Plain Text Renderer for Context Bundles * @@ -56,13 +56,13 @@ import type { * * === PATTERN: AgentLLMIntegration === * Status: roadmap | Phase: 22b | Category: agent - * Spec: delivery-process/specs/agent-llm-integration.feature + * Spec: architect/specs/agent-llm-integration.feature * * === STUBS === * stubs/agent-llm/adapter.ts -> src/agent/adapter.ts * * === DEPENDENCIES === - * [completed] AgentBCIsolation (22a) delivery-process/specs/... + * [completed] AgentBCIsolation (22a) architect/specs/... * [roadmap] AgentAsBoundedContext (22) * * === CONSUMERS === @@ -112,14 +112,14 @@ export function formatDepTree(_tree: DepTreeNode): string { * Output format: * * === PRIMARY === - * delivery-process/specs/order-saga.feature - * delivery-process/stubs/order-saga/saga.ts + * architect/specs/order-saga.feature + * architect/stubs/order-saga/saga.ts * * === COMPLETED DEPENDENCIES === * src/events/event-store.ts * * === ROADMAP DEPENDENCIES === - * delivery-process/specs/saga-engine.feature + * architect/specs/saga-engine.feature * * === ARCHITECTURE NEIGHBORS === * src/orders/command-handler.ts diff --git a/delivery-process/stubs/data-api-output-shaping/fuzzy-match.ts b/architect/stubs/data-api-output-shaping/fuzzy-match.ts similarity index 93% rename from delivery-process/stubs/data-api-output-shaping/fuzzy-match.ts rename to architect/stubs/data-api-output-shaping/fuzzy-match.ts index aac225d8..5a542da4 100644 --- a/delivery-process/stubs/data-api-output-shaping/fuzzy-match.ts +++ b/architect/stubs/data-api-output-shaping/fuzzy-match.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements DataAPIOutputShaping - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-target src/api/fuzzy-match.ts - * @libar-docs-since DS-A + * @architect + * @architect-status roadmap + * @architect-implements DataAPIOutputShaping + * @architect-used-by ProcessAPICLIImpl + * @architect-target src/api/fuzzy-match.ts + * @architect-since DS-A * * ## FuzzyMatcher — Pattern Name Fuzzy Search * diff --git a/delivery-process/stubs/data-api-output-shaping/output-pipeline.ts b/architect/stubs/data-api-output-shaping/output-pipeline.ts similarity index 95% rename from delivery-process/stubs/data-api-output-shaping/output-pipeline.ts rename to architect/stubs/data-api-output-shaping/output-pipeline.ts index d36398d0..6f079d6b 100644 --- a/delivery-process/stubs/data-api-output-shaping/output-pipeline.ts +++ b/architect/stubs/data-api-output-shaping/output-pipeline.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements DataAPIOutputShaping - * @libar-docs-uses PatternSummarizer - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-target src/cli/output-pipeline.ts - * @libar-docs-since DS-A + * @architect + * @architect-status roadmap + * @architect-implements DataAPIOutputShaping + * @architect-uses PatternSummarizer + * @architect-used-by ProcessAPICLIImpl + * @architect-target src/cli/output-pipeline.ts + * @architect-since DS-A * * ## OutputPipeline — CLI Output Shaping and Formatting * diff --git a/delivery-process/stubs/data-api-output-shaping/summarize.ts b/architect/stubs/data-api-output-shaping/summarize.ts similarity index 88% rename from delivery-process/stubs/data-api-output-shaping/summarize.ts rename to architect/stubs/data-api-output-shaping/summarize.ts index 546e468a..df9b5610 100644 --- a/delivery-process/stubs/data-api-output-shaping/summarize.ts +++ b/architect/stubs/data-api-output-shaping/summarize.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements DataAPIOutputShaping - * @libar-docs-uses ProcessStateAPI - * @libar-docs-used-by OutputPipeline, ProcessAPICLIImpl - * @libar-docs-target src/api/summarize.ts - * @libar-docs-since DS-A + * @architect + * @architect-status roadmap + * @architect-implements DataAPIOutputShaping + * @architect-uses ProcessStateAPI + * @architect-used-by OutputPipeline, ProcessAPICLIImpl + * @architect-target src/api/summarize.ts + * @architect-since DS-A * * ## PatternSummarizer — Compact Pattern Projection * @@ -56,7 +56,7 @@ export type PatternSummary = z.infer; /** * Project an ExtractedPattern to a compact PatternSummary. * - * - `patternName` prefers explicit @libar-docs-pattern tag, falls back to `name` + * - `patternName` prefers explicit @architect-pattern tag, falls back to `name` * - `source` is derived from file extension (`.feature` → gherkin, else typescript) * - Optional fields (status, phase) are included when present, omitted when undefined * diff --git a/delivery-process/stubs/data-api-stub-integration/stub-resolver.ts b/architect/stubs/data-api-stub-integration/stub-resolver.ts similarity index 87% rename from delivery-process/stubs/data-api-stub-integration/stub-resolver.ts rename to architect/stubs/data-api-stub-integration/stub-resolver.ts index 063ac9d4..576e27b7 100644 --- a/delivery-process/stubs/data-api-stub-integration/stub-resolver.ts +++ b/architect/stubs/data-api-stub-integration/stub-resolver.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements DataAPIStubIntegration - * @libar-docs-uses ProcessStateAPI - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-target src/api/stub-resolver.ts - * @libar-docs-since DS-B + * @architect + * @architect-status roadmap + * @architect-implements DataAPIStubIntegration + * @architect-uses ProcessStateAPI + * @architect-used-by ProcessAPICLIImpl + * @architect-target src/api/stub-resolver.ts + * @architect-since DS-B * * ## StubResolver — Design Stub Discovery and Resolution * @@ -14,10 +14,10 @@ * * Stub identification heuristic: * - Source file path contains `/stubs/` (lives in stubs directory), OR - * - Pattern has a `targetPath` field (from @libar-docs-target tag) + * - Pattern has a `targetPath` field (from @architect-target tag) * * Resolution uses a `fileExists` callback (defaulting to `fs.existsSync()`) on - * targetPath — not pipeline data — because target files may not have `@libar-docs` + * targetPath — not pipeline data — because target files may not have `@architect` * annotations. The callback enables testing without filesystem side effects. * * See: DataAPIStubIntegration spec, Rule 2 (Stubs Subcommand) @@ -33,15 +33,15 @@ * Result of resolving a single stub against the filesystem. */ export interface StubResolution { - /** The stub's pattern name (from @libar-docs-implements or patternName) */ + /** The stub's pattern name (from @architect-implements or patternName) */ readonly stubName: string; /** Source file path of the stub */ readonly stubFile: string; - /** Target implementation path (from @libar-docs-target) */ + /** Target implementation path (from @architect-target) */ readonly targetPath: string; - /** Design session that created this stub (from @libar-docs-since) */ + /** Design session that created this stub (from @architect-since) */ readonly since: string | undefined; - /** Parent pattern this stub implements (from @libar-docs-implements) */ + /** Parent pattern this stub implements (from @architect-implements) */ readonly implementsPattern: string | undefined; /** Whether the target file exists on disk */ readonly targetExists: boolean; @@ -70,7 +70,7 @@ export interface StubSummary { * * A pattern is a stub if: * 1. Its source file path contains '/stubs/' (lives in stubs directory), OR - * 2. It has a `targetPath` field (from @libar-docs-target tag) + * 2. It has a `targetPath` field (from @architect-target tag) * * @param dataset - MasterDataset with all patterns * @returns Array of patterns identified as stubs diff --git a/delivery-process/stubs/enhanced-index-generation/index-codec-options.ts b/architect/stubs/enhanced-index-generation/index-codec-options.ts similarity index 96% rename from delivery-process/stubs/enhanced-index-generation/index-codec-options.ts rename to architect/stubs/enhanced-index-generation/index-codec-options.ts index 6c6b427d..e745978f 100644 --- a/delivery-process/stubs/enhanced-index-generation/index-codec-options.ts +++ b/architect/stubs/enhanced-index-generation/index-codec-options.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status completed - * @libar-docs-implements EnhancedIndexGeneration - * @libar-docs-target src/renderable/codecs/index-codec.ts + * @architect + * @architect-status completed + * @architect-implements EnhancedIndexGeneration + * @architect-target src/renderable/codecs/index-codec.ts * * ## IndexCodecOptions — DD-1, DD-5 Decisions * @@ -47,7 +47,7 @@ * | CodecRegistry | `CodecRegistry.register('index', IndexCodec)` | * | DOCUMENT_TYPES | Add `index: { outputPath: 'INDEX.md', description: '...' }` | * | CodecOptions | Add `index?: IndexCodecOptions` to CodecOptions interface | - * | delivery-process.config.ts | Add `generatorOverrides.index.outputDirectory: 'docs-live'` | + * | architect.config.ts | Add `generatorOverrides.index.outputDirectory: 'docs-live'` | * | generateAllDocuments() | Automatically included via DOCUMENT_TYPES iteration | */ @@ -154,7 +154,7 @@ export interface DocumentEntry { * * All auto-generated sections are enabled by default. * Preamble and document entries are empty by default — they must be - * provided via delivery-process.config.ts. + * provided via architect.config.ts. */ export const DEFAULT_INDEX_OPTIONS: Required> & { preamble: readonly SectionBlock[]; diff --git a/delivery-process/stubs/enhanced-index-generation/index-codec.ts b/architect/stubs/enhanced-index-generation/index-codec.ts similarity index 98% rename from delivery-process/stubs/enhanced-index-generation/index-codec.ts rename to architect/stubs/enhanced-index-generation/index-codec.ts index 14f94b9c..74572545 100644 --- a/delivery-process/stubs/enhanced-index-generation/index-codec.ts +++ b/architect/stubs/enhanced-index-generation/index-codec.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status completed - * @libar-docs-implements EnhancedIndexGeneration - * @libar-docs-target src/renderable/codecs/index-codec.ts + * @architect + * @architect-status completed + * @architect-implements EnhancedIndexGeneration + * @architect-target src/renderable/codecs/index-codec.ts * * ## IndexCodec Factory — DD-1 Implementation Stub * diff --git a/delivery-process/stubs/enhanced-index-generation/index-preamble-config.ts b/architect/stubs/enhanced-index-generation/index-preamble-config.ts similarity index 97% rename from delivery-process/stubs/enhanced-index-generation/index-preamble-config.ts rename to architect/stubs/enhanced-index-generation/index-preamble-config.ts index c2867154..e0c4a052 100644 --- a/delivery-process/stubs/enhanced-index-generation/index-preamble-config.ts +++ b/architect/stubs/enhanced-index-generation/index-preamble-config.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status completed - * @libar-docs-implements EnhancedIndexGeneration - * @libar-docs-target delivery-process.config.ts + * @architect + * @architect-status completed + * @architect-implements EnhancedIndexGeneration + * @architect-target architect.config.ts * * ## Index Preamble Configuration — DD-3, DD-4 Decisions * @@ -30,7 +30,7 @@ * not for human onboarding. Attempting to derive glossary content from pattern * metadata would produce entries like "FSM enforcement, pre-commit hooks" — * accurate but unhelpful for someone encountering the concept for the first - * time. A future `@libar-docs-glossary` annotation type could solve this, but + * time. A future `@architect-glossary` annotation type could solve this, but * it would require a new scanner capability and extraction pipeline. The * preamble approach works today with zero new infrastructure. * @@ -62,10 +62,10 @@ * * ### Config Integration * - * This preamble is provided via `CodecOptions` in delivery-process.config.ts: + * This preamble is provided via `CodecOptions` in architect.config.ts: * * ```typescript - * // In delivery-process.config.ts (future) + * // In architect.config.ts (future) * export default defineConfig({ * // ... existing config ... * codecOptions: { diff --git a/delivery-process/stubs/error-guide-codec/convention-annotation-example.ts b/architect/stubs/error-guide-codec/convention-annotation-example.ts similarity index 89% rename from delivery-process/stubs/error-guide-codec/convention-annotation-example.ts rename to architect/stubs/error-guide-codec/convention-annotation-example.ts index e0d28ea7..4ecec58b 100644 --- a/delivery-process/stubs/error-guide-codec/convention-annotation-example.ts +++ b/architect/stubs/error-guide-codec/convention-annotation-example.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements ErrorGuideCodec - * @libar-docs-target src/lint/process-guard/decider.ts + * @architect + * @architect-status roadmap + * @architect-implements ErrorGuideCodec + * @architect-target src/lint/process-guard/decider.ts * * ## Convention Annotation Example — DD-3 Decision * @@ -14,9 +14,9 @@ * code, not in a planning spec. When a developer changes an error rule in * the decider, the convention JSDoc is right there -- they update both in * the same commit. This follows the proven pattern used by: - * - `src/generators/orchestrator.ts` with `@libar-docs-convention pipeline-architecture` - * - `src/renderable/codecs/reference.ts` with `@libar-docs-convention codec-registry` - * - `src/renderable/codecs/validation-rules.ts` with `@libar-docs-convention codec-registry` + * - `src/generators/orchestrator.ts` with `@architect-convention pipeline-architecture` + * - `src/renderable/codecs/reference.ts` with `@architect-convention codec-registry` + * - `src/renderable/codecs/validation-rules.ts` with `@architect-convention codec-registry` * * All three use TypeScript JSDoc convention annotations with `## Heading` * decomposition. The convention extractor's `extractConventionRulesFromDescription()` @@ -40,10 +40,10 @@ * JSDoc describing the decider's design principles and rules. The * convention annotation extends this JSDoc, not replaces it. * - * Specifically, `@libar-docs-convention process-guard-errors` is added + * Specifically, `@architect-convention process-guard-errors` is added * to the file-level JSDoc alongside the existing annotations: - * - `@libar-docs-pattern ProcessGuardDecider` - * - `@libar-docs-arch-role decider` + * - `@architect-pattern ProcessGuardDecider` + * - `@architect-arch-role decider` * - etc. * * Then the `## ` headings for each error rule are added below the existing @@ -68,7 +68,7 @@ * In the actual decider.ts, these would follow the existing `### Rules * Implemented` section. * - * @libar-docs-convention process-guard-errors + * @architect-convention process-guard-errors * * ## completed-protection * @@ -83,7 +83,7 @@ * * | Situation | Solution | Example | * |-----------|----------|---------| - * | Fix typo in completed spec | Add unlock reason tag | `@libar-docs-unlock-reason:Fix-typo-in-FSM-diagram` | + * | Fix typo in completed spec | Add unlock reason tag | `@architect-unlock-reason:Fix-typo-in-FSM-diagram` | * | Spec needs rework | Create new spec instead | New feature file with `roadmap` status | * | Legacy import | Multiple transitions in one commit | Set `roadmap` then `completed` | * diff --git a/delivery-process/stubs/error-guide-codec/enhanced-validation-options.ts b/architect/stubs/error-guide-codec/enhanced-validation-options.ts similarity index 97% rename from delivery-process/stubs/error-guide-codec/enhanced-validation-options.ts rename to architect/stubs/error-guide-codec/enhanced-validation-options.ts index c1059eeb..89c01ff5 100644 --- a/delivery-process/stubs/error-guide-codec/enhanced-validation-options.ts +++ b/architect/stubs/error-guide-codec/enhanced-validation-options.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements ErrorGuideCodec - * @libar-docs-target src/renderable/codecs/validation-rules.ts + * @architect + * @architect-status roadmap + * @architect-implements ErrorGuideCodec + * @architect-target src/renderable/codecs/validation-rules.ts * * ## Enhanced ValidationRulesCodecOptions — DD-1 Decision * diff --git a/delivery-process/stubs/error-guide-codec/error-guide-config.ts b/architect/stubs/error-guide-codec/error-guide-config.ts similarity index 94% rename from delivery-process/stubs/error-guide-codec/error-guide-config.ts rename to architect/stubs/error-guide-codec/error-guide-config.ts index 55848af8..92038732 100644 --- a/delivery-process/stubs/error-guide-codec/error-guide-config.ts +++ b/architect/stubs/error-guide-codec/error-guide-config.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements ErrorGuideCodec - * @libar-docs-target delivery-process.config.ts + * @architect + * @architect-status roadmap + * @architect-implements ErrorGuideCodec + * @architect-target architect.config.ts * * ## ReferenceDocConfig Entry for Process Guard Error Guide — DD-2, DD-4 Decisions * @@ -36,7 +36,7 @@ * **Rationale (DD-4):** Integration recipes (Husky hook setup, CI YAML * patterns, programmatic API examples, architecture diagrams) describe how * external systems consume Process Guard, not how Process Guard is - * implemented. This content cannot come from `@libar-docs-convention` + * implemented. This content cannot come from `@architect-convention` * annotations because it is not attached to any source code entity. * The preamble mechanism was designed precisely for this case: * - Already proven by product-area docs (e.g., `PRODUCT_AREA_META` preamble) @@ -65,12 +65,12 @@ */ // --------------------------------------------------------------------------- -// Example ReferenceDocConfig entry (would be added to delivery-process.config.ts) +// Example ReferenceDocConfig entry (would be added to architect.config.ts) // --------------------------------------------------------------------------- /** * This stub demonstrates the config entry shape. The actual entry goes in - * `delivery-process.config.ts` under the `referenceDocConfigs` array. + * `architect.config.ts` under the `referenceDocConfigs` array. * * The preamble sections below show the editorial content structure for * Husky setup, programmatic API, and architecture diagram. Each preamble @@ -146,7 +146,7 @@ export const ERROR_GUIDE_REFERENCE_CONFIG = { " validateChanges,", " hasErrors,", " summarizeResult,", - "} from '@libar-dev/delivery-process/lint';", + "} from '@libar-dev/architect/lint';", "", "// 1. Derive state from annotations", "const state = (await deriveProcessState({ baseDir: '.' })).value;", diff --git a/delivery-process/stubs/mcp-server-integration/file-watcher.ts b/architect/stubs/mcp-server-integration/file-watcher.ts similarity index 87% rename from delivery-process/stubs/mcp-server-integration/file-watcher.ts rename to architect/stubs/mcp-server-integration/file-watcher.ts index a345404d..59d32e0e 100644 --- a/delivery-process/stubs/mcp-server-integration/file-watcher.ts +++ b/architect/stubs/mcp-server-integration/file-watcher.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-status completed - * @libar-docs-implements MCPServerIntegration - * @libar-docs-uses MCPPipelineSession - * @libar-docs-used-by MCPServerImpl - * @libar-docs-target src/mcp/file-watcher.ts - * @libar-docs-since DS-MCP + * @architect + * @architect-status completed + * @architect-implements MCPServerIntegration + * @architect-uses MCPPipelineSession + * @architect-used-by MCPServerImpl + * @architect-target src/mcp/file-watcher.ts + * @architect-since DS-MCP * * ## McpFileWatcher — Debounced Source File Watcher * diff --git a/delivery-process/stubs/mcp-server-integration/pipeline-session.ts b/architect/stubs/mcp-server-integration/pipeline-session.ts similarity index 83% rename from delivery-process/stubs/mcp-server-integration/pipeline-session.ts rename to architect/stubs/mcp-server-integration/pipeline-session.ts index 75feb3fa..ba67422c 100644 --- a/delivery-process/stubs/mcp-server-integration/pipeline-session.ts +++ b/architect/stubs/mcp-server-integration/pipeline-session.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-status completed - * @libar-docs-implements MCPServerIntegration - * @libar-docs-uses PipelineFactory, ProcessStateAPI, ConfigLoader - * @libar-docs-used-by MCPServerImpl, MCPToolRegistry, MCPFileWatcher - * @libar-docs-target src/mcp/pipeline-session.ts - * @libar-docs-since DS-MCP + * @architect + * @architect-status completed + * @architect-implements MCPServerIntegration + * @architect-uses PipelineFactory, ProcessStateAPI, ConfigLoader + * @architect-used-by MCPServerImpl, MCPToolRegistry, MCPFileWatcher + * @architect-target src/mcp/pipeline-session.ts + * @architect-since DS-MCP * * ## PipelineSessionManager — In-Memory MasterDataset Lifecycle * @@ -35,8 +35,8 @@ * * DD-2: Config auto-detection mirrors the CLI - uses the same * applyProjectSourceDefaults() from config-loader, then falls back to - * filesystem-based detection (delivery-process.config.ts presence, - * delivery-process/specs/ and delivery-process/stubs/ directories). + * filesystem-based detection (architect.config.ts presence, + * architect/specs/ and architect/stubs/ directories). * * DD-3: No caching layer - the CLI uses dataset-cache.ts for inter-process * caching, but the MCP server keeps the dataset in-process memory. Caching diff --git a/delivery-process/stubs/mcp-server-integration/server.ts b/architect/stubs/mcp-server-integration/server.ts similarity index 81% rename from delivery-process/stubs/mcp-server-integration/server.ts rename to architect/stubs/mcp-server-integration/server.ts index 24d37e5a..41c7d108 100644 --- a/delivery-process/stubs/mcp-server-integration/server.ts +++ b/architect/stubs/mcp-server-integration/server.ts @@ -1,15 +1,15 @@ /** - * @libar-docs - * @libar-docs-status completed - * @libar-docs-implements MCPServerIntegration - * @libar-docs-uses MCPPipelineSession, MCPToolRegistry, MCPFileWatcher - * @libar-docs-used-by MCPServerBin - * @libar-docs-target src/mcp/server.ts - * @libar-docs-since DS-MCP + * @architect + * @architect-status completed + * @architect-implements MCPServerIntegration + * @architect-uses MCPPipelineSession, MCPToolRegistry, MCPFileWatcher + * @architect-used-by MCPServerBin + * @architect-target src/mcp/server.ts + * @architect-since DS-MCP * * ## MCPServer — Entry Point and Lifecycle Manager * - * Main entry point for the delivery-process MCP server. Wires together + * Main entry point for the Architect MCP server. Wires together * the pipeline session, tool registry, file watcher, and stdio transport. * * ### Lifecycle (5 phases) @@ -25,7 +25,7 @@ * DD-1: Stdout isolation via console.log redirect - MCP protocol uses JSON-RPC * over stdout exclusively. console.log is redirected to console.error at module * load time (before any imports). All application logging uses console.error - * via a log() helper that prefixes messages with [dp-mcp]. + * via a log() helper that prefixes messages with [architect-mcp]. * * DD-2: Graceful shutdown with cleanup - SIGINT/SIGTERM handlers stop the file * watcher, close the McpServer, then exit. Prevents dangling watchers and ensures @@ -37,7 +37,7 @@ * * DD-4: Config auto-detection with override - explicit --input/--features override * config file detection. When no args are provided, the server auto-detects - * delivery-process.config.ts using the same applyProjectSourceDefaults() as CLI. + * architect.config.ts using the same applyProjectSourceDefaults() as CLI. * * DD-5: Pipeline failure at startup is fatal - if the pipeline fails during * initialization (bad config, scan errors), the server exits with code 1. diff --git a/delivery-process/stubs/mcp-server-integration/tool-registry.ts b/architect/stubs/mcp-server-integration/tool-registry.ts similarity index 83% rename from delivery-process/stubs/mcp-server-integration/tool-registry.ts rename to architect/stubs/mcp-server-integration/tool-registry.ts index c737b70d..8acbc2f2 100644 --- a/delivery-process/stubs/mcp-server-integration/tool-registry.ts +++ b/architect/stubs/mcp-server-integration/tool-registry.ts @@ -1,16 +1,16 @@ /** - * @libar-docs - * @libar-docs-status completed - * @libar-docs-implements MCPServerIntegration - * @libar-docs-uses ProcessStateAPI, MCPPipelineSession - * @libar-docs-used-by MCPServerImpl - * @libar-docs-target src/mcp/tool-registry.ts - * @libar-docs-since DS-MCP + * @architect + * @architect-status completed + * @architect-implements MCPServerIntegration + * @architect-uses ProcessStateAPI, MCPPipelineSession + * @architect-used-by MCPServerImpl + * @architect-target src/mcp/tool-registry.ts + * @architect-since DS-MCP * * ## MCPToolRegistry — Tool Definitions with Zod Schemas * * Defines 25 MCP tools mapping to ProcessStateAPI methods and CLI subcommands. - * Each tool has a dp_ prefix, a Zod input schema for parameter validation, + * Each tool has a architect_ prefix, a Zod input schema for parameter validation, * and a handler that delegates to existing API functions. * * ### Tool Categories (5 groups) @@ -41,7 +41,7 @@ * fields modifiers) is replaced by dedicated tool parameters. Each tool has * explicit namesOnly/count parameters instead of generic modifier flags. * - * DD-5: dp_ prefix per spec invariant - avoids collision with other MCP servers + * DD-5: architect_ prefix per spec invariant - avoids collision with other MCP servers * in multi-server Claude Code setups. Matches the spec's Rule 2 invariant. * * ### When to Use diff --git a/delivery-process/stubs/procedural-guide-codec/annotation-guide-preamble.ts b/architect/stubs/procedural-guide-codec/annotation-guide-preamble.ts similarity index 87% rename from delivery-process/stubs/procedural-guide-codec/annotation-guide-preamble.ts rename to architect/stubs/procedural-guide-codec/annotation-guide-preamble.ts index 403285a8..ede5d33d 100644 --- a/delivery-process/stubs/procedural-guide-codec/annotation-guide-preamble.ts +++ b/architect/stubs/procedural-guide-codec/annotation-guide-preamble.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements ProceduralGuideCodec - * @libar-docs-target delivery-process.config.ts + * @architect + * @architect-status roadmap + * @architect-implements ProceduralGuideCodec + * @architect-target architect.config.ts * * ## Annotation Guide — Markdown Source File Example * @@ -50,7 +50,7 @@ * ### Config Usage Example * * ```typescript - * // In delivery-process.config.ts: + * // In architect.config.ts: * import { loadPreambleFromMarkdown } from './src/renderable/load-preamble.js'; * * const annotationPreamble = loadPreambleFromMarkdown( @@ -77,7 +77,7 @@ * ## Getting Started * * Every file that participates in the annotation system must have a - * `@libar-docs` opt-in marker. Files without this marker are invisible + * `@architect` opt-in marker. Files without this marker are invisible * to the scanner. * * ### File-Level Opt-In @@ -86,9 +86,9 @@ * * \`\`\`typescript * /** - * * @libar-docs - * * @libar-docs-pattern MyPattern - * * @libar-docs-status roadmap + * * @architect + * * @architect-pattern MyPattern + * * @architect-status roadmap * * / * \`\`\` * @@ -96,8 +96,8 @@ * * | Preset | Prefix | Categories | Use Case | * |--------|--------|------------|----------| - * | `libar-generic` (default) | `@libar-docs-` | 3 | Simple projects | - * | `ddd-es-cqrs` | `@libar-docs-` | 21 | DDD/Event Sourcing monorepos | + * | `libar-generic` (default) | `@architect-` | 3 | Simple projects | + * | `ddd-es-cqrs` | `@architect-` | 21 | DDD/Event Sourcing monorepos | * * --- * @@ -116,7 +116,7 @@ * * | Symptom | Cause | Fix | * |---------|-------|-----| - * | Pattern not in scanner output | Missing `@libar-docs` opt-in | Add file-level `@libar-docs` JSDoc/tag | + * | Pattern not in scanner output | Missing `@architect` opt-in | Add file-level `@architect` JSDoc/tag | * | Shape shows `z.infer<>` wrapper | Extracted type alias, not schema | Use schema constant name | * ``` */ diff --git a/delivery-process/stubs/procedural-guide-codec/load-preamble.ts b/architect/stubs/procedural-guide-codec/load-preamble.ts similarity index 95% rename from delivery-process/stubs/procedural-guide-codec/load-preamble.ts rename to architect/stubs/procedural-guide-codec/load-preamble.ts index a073bb56..fc28511a 100644 --- a/delivery-process/stubs/procedural-guide-codec/load-preamble.ts +++ b/architect/stubs/procedural-guide-codec/load-preamble.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements ProceduralGuideCodec - * @libar-docs-target src/renderable/load-preamble.ts + * @architect + * @architect-status roadmap + * @architect-implements ProceduralGuideCodec + * @architect-target src/renderable/load-preamble.ts * * ## loadPreambleFromMarkdown() — Shared Utility Stub * @@ -76,7 +76,7 @@ * ### Usage * * ```typescript - * // In delivery-process.config.ts: + * // In architect.config.ts: * import { loadPreambleFromMarkdown } from './src/renderable/load-preamble.js'; * * const sessionWorkflowPreamble = loadPreambleFromMarkdown( @@ -99,7 +99,7 @@ * * The `filePath` argument is resolved relative to the project root directory * (the directory containing `package.json`). This matches how other config - * file paths are resolved in `delivery-process.config.ts`. + * file paths are resolved in `architect.config.ts`. * * ```typescript * // These are equivalent: diff --git a/delivery-process/stubs/procedural-guide-codec/procedural-codec-options.ts b/architect/stubs/procedural-guide-codec/procedural-codec-options.ts similarity index 96% rename from delivery-process/stubs/procedural-guide-codec/procedural-codec-options.ts rename to architect/stubs/procedural-guide-codec/procedural-codec-options.ts index 8f28432b..8a0cf61b 100644 --- a/delivery-process/stubs/procedural-guide-codec/procedural-codec-options.ts +++ b/architect/stubs/procedural-guide-codec/procedural-codec-options.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements ProceduralGuideCodec - * @libar-docs-target src/renderable/codecs/procedural-guide.ts + * @architect + * @architect-status roadmap + * @architect-implements ProceduralGuideCodec + * @architect-target src/renderable/codecs/procedural-guide.ts * * ## ProceduralGuideCodecOptions -- Configuration Interface * @@ -74,7 +74,7 @@ * * The `includeTags` mechanism is preferred over `behaviorCategories` * because SessionGuidesModuleSource needs to be explicitly opted-in - * via `@libar-docs-include:session-workflows` rather than category-matched. + * via `@architect-include:session-workflows` rather than category-matched. * This allows precise control over which patterns contribute behavior * content to each guide document. */ diff --git a/delivery-process/stubs/procedural-guide-codec/procedural-codec.ts b/architect/stubs/procedural-guide-codec/procedural-codec.ts similarity index 93% rename from delivery-process/stubs/procedural-guide-codec/procedural-codec.ts rename to architect/stubs/procedural-guide-codec/procedural-codec.ts index e57f0203..2b7027bd 100644 --- a/delivery-process/stubs/procedural-guide-codec/procedural-codec.ts +++ b/architect/stubs/procedural-guide-codec/procedural-codec.ts @@ -1,15 +1,15 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements ProceduralGuideCodec - * @libar-docs-target src/renderable/codecs/procedural-guide.ts + * @architect + * @architect-status roadmap + * @architect-implements ProceduralGuideCodec + * @architect-target src/renderable/codecs/procedural-guide.ts * * ## ProceduralGuideCodec -- Factory Stub for Dual-Source Procedural Guides * * **Design Decision DD-1 (One codec, two configs):** * This codec IS `createReferenceCodec()`. The ProceduralGuideCodec does not * introduce a new codec class. Instead, it adds two new `ReferenceDocConfig` - * entries to the `referenceDocConfigs` array in `delivery-process.config.ts`. + * entries to the `referenceDocConfigs` array in `architect.config.ts`. * Each entry configures `createReferenceCodec()` with document-specific * preamble content and behavior extraction settings. * @@ -26,8 +26,8 @@ * not a code pattern. The implementation deliverables are: * 1. `loadPreambleFromMarkdown()` utility in `src/renderable/load-preamble.ts` * 2. Two markdown source files in `docs-sources/` - * 3. Two `ReferenceDocConfig` entries in `delivery-process.config.ts` - * 4. `@libar-docs-include:session-workflows` tag on SessionGuidesModuleSource + * 3. Two `ReferenceDocConfig` entries in `architect.config.ts` + * 4. `@architect-include:session-workflows` tag on SessionGuidesModuleSource * * **Design Decision DD-2 (SessionGuidesModuleSource as behavior source):** * The SessionGuidesModuleSource spec's Rule: blocks (Rules 3-8) are extracted @@ -116,13 +116,13 @@ * Step 1: Create `loadPreambleFromMarkdown()` in `src/renderable/load-preamble.ts` * Step 2: Create `docs-sources/session-workflow-guide.md` (content from current inline preamble) * Step 3: Create `docs-sources/annotation-guide.md` (content from current inline preamble) - * Step 4: Update `delivery-process.config.ts` to use `loadPreambleFromMarkdown()` calls + * Step 4: Update `architect.config.ts` to use `loadPreambleFromMarkdown()` calls * Step 5: Verify generated output matches current output (regression test) * Step 6: Quality audit document comparing generated vs manual */ // --------------------------------------------------------------------------- -// Example ReferenceDocConfig entries for delivery-process.config.ts +// Example ReferenceDocConfig entries for architect.config.ts // --------------------------------------------------------------------------- import type { SectionBlock } from '../../../src/renderable/schema.js'; @@ -152,7 +152,7 @@ interface ReferenceDocConfigEntry { * DD-7: Preamble loaded from markdown source file, not inline SectionBlock[]. * * ```typescript - * // In delivery-process.config.ts: + * // In architect.config.ts: * import { loadPreambleFromMarkdown } from './src/renderable/load-preamble.js'; * * const sessionWorkflowPreamble = loadPreambleFromMarkdown( diff --git a/delivery-process/stubs/procedural-guide-codec/session-guide-preamble.ts b/architect/stubs/procedural-guide-codec/session-guide-preamble.ts similarity index 96% rename from delivery-process/stubs/procedural-guide-codec/session-guide-preamble.ts rename to architect/stubs/procedural-guide-codec/session-guide-preamble.ts index 879b48ac..a33ab6ab 100644 --- a/delivery-process/stubs/procedural-guide-codec/session-guide-preamble.ts +++ b/architect/stubs/procedural-guide-codec/session-guide-preamble.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-implements ProceduralGuideCodec - * @libar-docs-target delivery-process.config.ts + * @architect + * @architect-status roadmap + * @architect-implements ProceduralGuideCodec + * @architect-target architect.config.ts * * ## Session Workflow Guide — Markdown Source File Example * @@ -47,7 +47,7 @@ * ### Config Usage Example * * ```typescript - * // In delivery-process.config.ts: + * // In architect.config.ts: * import { loadPreambleFromMarkdown } from './src/renderable/load-preamble.js'; * * const sessionWorkflowPreamble = loadPreambleFromMarkdown( diff --git a/architect/tag-taxonomy.md b/architect/tag-taxonomy.md new file mode 100644 index 00000000..20175caf --- /dev/null +++ b/architect/tag-taxonomy.md @@ -0,0 +1,87 @@ +# Tag Taxonomy Reference + +> ⚠️ **Auto-generated from `architect.config.ts`** - Do not edit manually. + +## File Opt-In + +All files must have this tag at the top to be included in documentation extraction: + +| Tag | Purpose | +| ------------ | ------------------------------------------ | +| `@architect` | Gates extraction - file must have this tag | + +## Category Tags + +Sorted by priority (lower number = higher priority): + +| Priority | Tag | Domain | Description | +| -------- | --------------------------------------------------------- | -------------- | -------------- | +| 1 | `@architect-core` | Core | Core patterns | +| 2 | `@architect-api` | API | Public APIs | +| 3 | `@architect-infra` (aliases: `@architect-infrastructure`) | Infrastructure | Infrastructure | + +## Metadata Tags + +| Tag | Format | Purpose | Required | Example | +| ------------------------------ | ------------ | -------------------------------------------------------------------------- | -------- | ---------------------------------------------------------------------------- | +| `@architect-pattern` | value | Explicit pattern name | Yes | `@architect-pattern CommandOrchestrator` | +| `@architect-status` | enum | Work item lifecycle status (per PDR-005 FSM) | No | `@architect-status roadmap` | +| `@architect-core` | flag | Marks as essential/must-know pattern | No | `@architect-core` | +| `@architect-usecase` | quoted-value | Use case association | No | `@architect-usecase "When handling command failures"` | +| `@architect-uses` | csv | Patterns this depends on | No | `@architect-uses CommandBus, EventStore` | +| `@architect-used-by` | csv | Patterns that depend on this | No | `@architect-used-by SagaOrchestrator` | +| `@architect-phase` | number | Roadmap phase number (unified across monorepo) | No | `@architect-phase 14` | +| `@architect-release` | value | Target release version (semver or vNEXT for unreleased work) | No | `@architect-release v0.1.0` | +| `@architect-brief` | value | Path to pattern brief markdown | No | `@architect-brief docs/briefs/decider-pattern.md` | +| `@architect-depends-on` | csv | Roadmap dependencies (pattern or phase names) | No | `@architect-depends-on EventStore, CommandBus` | +| `@architect-enables` | csv | Patterns this enables | No | `@architect-enables SagaOrchestrator, ProjectionBuilder` | +| `@architect-implements` | csv | Patterns this code file realizes (realization relationship) | No | `@architect-implements EventStoreDurability, IdempotentAppend` | +| `@architect-extends` | value | Base pattern this pattern extends (generalization relationship) | No | `@architect-extends ProjectionCategories` | +| `@architect-quarter` | value | Delivery quarter for timeline tracking | No | `@architect-quarter Q1-2026` | +| `@architect-completed` | value | Completion date (YYYY-MM-DD format) | No | `@architect-completed 2026-01-08` | +| `@architect-effort` | value | Estimated effort (4h, 2d, 1w format) | No | `@architect-effort 2d` | +| `@architect-effort-actual` | value | Actual effort spent (4h, 2d, 1w format) | No | `@architect-effort-actual 3d` | +| `@architect-team` | value | Responsible team assignment | No | `@architect-team platform` | +| `@architect-workflow` | enum | Workflow discipline for process tracking | No | `@architect-workflow implementation` | +| `@architect-risk` | enum | Risk level for planning | No | `@architect-risk medium` | +| `@architect-priority` | enum | Priority level for roadmap ordering | No | `@architect-priority high` | +| `@architect-product-area` | value | Product area for PRD grouping | No | `@architect-product-area PlatformCore` | +| `@architect-user-role` | value | Target user persona for this feature | No | `@architect-user-role Developer` | +| `@architect-business-value` | value | Business value statement (hyphenated for tag format) | No | `@architect-business-value eliminates-event-replay-complexity` | +| `@architect-constraint` | value | Technical constraint affecting feature implementation | No | `@architect-constraint requires-convex-backend` | +| `@architect-adr` | value | ADR/PDR number for decision tracking | No | `@architect-adr 015` | +| `@architect-adr-status` | enum | ADR/PDR decision status | No | `@architect-adr-status accepted` | +| `@architect-adr-category` | value | ADR/PDR category (architecture, process, tooling) | No | `@architect-adr-category architecture` | +| `@architect-adr-supersedes` | value | ADR/PDR number this decision supersedes | No | `@architect-adr-supersedes 012` | +| `@architect-adr-superseded-by` | value | ADR/PDR number that supersedes this decision | No | `@architect-adr-superseded-by 020` | +| `@architect-adr-theme` | enum | Theme grouping for related decisions (from synthesis) | No | `@architect-adr-theme persistence` | +| `@architect-adr-layer` | enum | Evolutionary layer of the decision | No | `@architect-adr-layer foundation` | +| `@architect-level` | enum | Hierarchy level for epic->phase->task breakdown | No | `@architect-level epic` | +| `@architect-parent` | value | Parent pattern name in hierarchy (links tasks to phases, phases to epics) | No | `@architect-parent AggregateArchitecture` | +| `@architect-executable-specs` | csv | Links roadmap spec to package executable spec locations (PDR-007) | No | `@architect-executable-specs platform-decider/tests/features/behavior` | +| `@architect-roadmap-spec` | value | Links package spec back to roadmap pattern for traceability (PDR-007) | No | `@architect-roadmap-spec DeciderPattern` | +| `@architect-see-also` | csv | Related patterns for cross-reference without dependency implication | No | `@architect-see-also AgentAsBoundedContext, CrossContextIntegration` | +| `@architect-api-ref` | csv | File paths to implementation APIs (replaces 'See:' Markdown text in Rules) | No | `@architect-api-ref @libar-dev/platform-core/src/durability/outbox.ts` | +| `@architect-extract-shapes` | csv | TypeScript type names to extract from this file for documentation | No | `@architect-extract-shapes DeciderInput, ValidationResult, ProcessViolation` | +| `@architect-arch-role` | enum | Architectural role for diagram generation (component type) | No | `@architect-arch-role projection` | +| `@architect-arch-context` | value | Bounded context this component belongs to (for subgraph grouping) | No | `@architect-arch-context orders` | +| `@architect-arch-layer` | enum | Architectural layer for layered diagrams | No | `@architect-arch-layer application` | +| `@architect-target` | value | Target implementation path for stub files | No | `@architect-target src/api/stub-resolver.ts` | +| `@architect-since` | value | Design session that created this pattern | No | `@architect-since DS-A` | +| `@architect-convention` | csv | Convention domains for reference document generation from decision records | No | `@architect-convention fsm-rules, testing-policy` | + +## Aggregation Tags + +| Tag | Target Document | Purpose | +| --------------------- | --------------------------- | ------------------------------------------- | +| `@architect-overview` | OVERVIEW.md | Architecture overview patterns | +| `@architect-decision` | DECISIONS.md | ADR-style decisions (auto-numbered) | +| `@architect-intro` | (template placeholder only) | Package introduction (template placeholder) | + +## Format Options + +Used in template placeholders: `{{@architect-core format=X}}` + +- `full` +- `list` +- `summary` diff --git a/delivery-process/tag-taxonomy.md b/delivery-process/tag-taxonomy.md deleted file mode 100644 index b463c142..00000000 --- a/delivery-process/tag-taxonomy.md +++ /dev/null @@ -1,87 +0,0 @@ -# Tag Taxonomy Reference - -> ⚠️ **Auto-generated from `delivery-process.config.ts`** - Do not edit manually. - -## File Opt-In - -All files must have this tag at the top to be included in documentation extraction: - -| Tag | Purpose | -| ------------- | ------------------------------------------ | -| `@libar-docs` | Gates extraction - file must have this tag | - -## Category Tags - -Sorted by priority (lower number = higher priority): - -| Priority | Tag | Domain | Description | -| -------- | ----------------------------------------------------------- | -------------- | -------------- | -| 1 | `@libar-docs-core` | Core | Core patterns | -| 2 | `@libar-docs-api` | API | Public APIs | -| 3 | `@libar-docs-infra` (aliases: `@libar-docs-infrastructure`) | Infrastructure | Infrastructure | - -## Metadata Tags - -| Tag | Format | Purpose | Required | Example | -| ------------------------------- | ------------ | -------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------- | -| `@libar-docs-pattern` | value | Explicit pattern name | Yes | `@libar-docs-pattern CommandOrchestrator` | -| `@libar-docs-status` | enum | Work item lifecycle status (per PDR-005 FSM) | No | `@libar-docs-status roadmap` | -| `@libar-docs-core` | flag | Marks as essential/must-know pattern | No | `@libar-docs-core` | -| `@libar-docs-usecase` | quoted-value | Use case association | No | `@libar-docs-usecase "When handling command failures"` | -| `@libar-docs-uses` | csv | Patterns this depends on | No | `@libar-docs-uses CommandBus, EventStore` | -| `@libar-docs-used-by` | csv | Patterns that depend on this | No | `@libar-docs-used-by SagaOrchestrator` | -| `@libar-docs-phase` | number | Roadmap phase number (unified across monorepo) | No | `@libar-docs-phase 14` | -| `@libar-docs-release` | value | Target release version (semver or vNEXT for unreleased work) | No | `@libar-docs-release v0.1.0` | -| `@libar-docs-brief` | value | Path to pattern brief markdown | No | `@libar-docs-brief docs/briefs/decider-pattern.md` | -| `@libar-docs-depends-on` | csv | Roadmap dependencies (pattern or phase names) | No | `@libar-docs-depends-on EventStore, CommandBus` | -| `@libar-docs-enables` | csv | Patterns this enables | No | `@libar-docs-enables SagaOrchestrator, ProjectionBuilder` | -| `@libar-docs-implements` | csv | Patterns this code file realizes (realization relationship) | No | `@libar-docs-implements EventStoreDurability, IdempotentAppend` | -| `@libar-docs-extends` | value | Base pattern this pattern extends (generalization relationship) | No | `@libar-docs-extends ProjectionCategories` | -| `@libar-docs-quarter` | value | Delivery quarter for timeline tracking | No | `@libar-docs-quarter Q1-2026` | -| `@libar-docs-completed` | value | Completion date (YYYY-MM-DD format) | No | `@libar-docs-completed 2026-01-08` | -| `@libar-docs-effort` | value | Estimated effort (4h, 2d, 1w format) | No | `@libar-docs-effort 2d` | -| `@libar-docs-effort-actual` | value | Actual effort spent (4h, 2d, 1w format) | No | `@libar-docs-effort-actual 3d` | -| `@libar-docs-team` | value | Responsible team assignment | No | `@libar-docs-team platform` | -| `@libar-docs-workflow` | enum | Workflow discipline for process tracking | No | `@libar-docs-workflow implementation` | -| `@libar-docs-risk` | enum | Risk level for planning | No | `@libar-docs-risk medium` | -| `@libar-docs-priority` | enum | Priority level for roadmap ordering | No | `@libar-docs-priority high` | -| `@libar-docs-product-area` | value | Product area for PRD grouping | No | `@libar-docs-product-area PlatformCore` | -| `@libar-docs-user-role` | value | Target user persona for this feature | No | `@libar-docs-user-role Developer` | -| `@libar-docs-business-value` | value | Business value statement (hyphenated for tag format) | No | `@libar-docs-business-value eliminates-event-replay-complexity` | -| `@libar-docs-constraint` | value | Technical constraint affecting feature implementation | No | `@libar-docs-constraint requires-convex-backend` | -| `@libar-docs-adr` | value | ADR/PDR number for decision tracking | No | `@libar-docs-adr 015` | -| `@libar-docs-adr-status` | enum | ADR/PDR decision status | No | `@libar-docs-adr-status accepted` | -| `@libar-docs-adr-category` | value | ADR/PDR category (architecture, process, tooling) | No | `@libar-docs-adr-category architecture` | -| `@libar-docs-adr-supersedes` | value | ADR/PDR number this decision supersedes | No | `@libar-docs-adr-supersedes 012` | -| `@libar-docs-adr-superseded-by` | value | ADR/PDR number that supersedes this decision | No | `@libar-docs-adr-superseded-by 020` | -| `@libar-docs-adr-theme` | enum | Theme grouping for related decisions (from synthesis) | No | `@libar-docs-adr-theme persistence` | -| `@libar-docs-adr-layer` | enum | Evolutionary layer of the decision | No | `@libar-docs-adr-layer foundation` | -| `@libar-docs-level` | enum | Hierarchy level for epic->phase->task breakdown | No | `@libar-docs-level epic` | -| `@libar-docs-parent` | value | Parent pattern name in hierarchy (links tasks to phases, phases to epics) | No | `@libar-docs-parent AggregateArchitecture` | -| `@libar-docs-executable-specs` | csv | Links roadmap spec to package executable spec locations (PDR-007) | No | `@libar-docs-executable-specs platform-decider/tests/features/behavior` | -| `@libar-docs-roadmap-spec` | value | Links package spec back to roadmap pattern for traceability (PDR-007) | No | `@libar-docs-roadmap-spec DeciderPattern` | -| `@libar-docs-see-also` | csv | Related patterns for cross-reference without dependency implication | No | `@libar-docs-see-also AgentAsBoundedContext, CrossContextIntegration` | -| `@libar-docs-api-ref` | csv | File paths to implementation APIs (replaces 'See:' Markdown text in Rules) | No | `@libar-docs-api-ref @libar-dev/platform-core/src/durability/outbox.ts` | -| `@libar-docs-extract-shapes` | csv | TypeScript type names to extract from this file for documentation | No | `@libar-docs-extract-shapes DeciderInput, ValidationResult, ProcessViolation` | -| `@libar-docs-arch-role` | enum | Architectural role for diagram generation (component type) | No | `@libar-docs-arch-role projection` | -| `@libar-docs-arch-context` | value | Bounded context this component belongs to (for subgraph grouping) | No | `@libar-docs-arch-context orders` | -| `@libar-docs-arch-layer` | enum | Architectural layer for layered diagrams | No | `@libar-docs-arch-layer application` | -| `@libar-docs-target` | value | Target implementation path for stub files | No | `@libar-docs-target src/api/stub-resolver.ts` | -| `@libar-docs-since` | value | Design session that created this pattern | No | `@libar-docs-since DS-A` | -| `@libar-docs-convention` | csv | Convention domains for reference document generation from decision records | No | `@libar-docs-convention fsm-rules, testing-policy` | - -## Aggregation Tags - -| Tag | Target Document | Purpose | -| ---------------------- | --------------------------- | ------------------------------------------- | -| `@libar-docs-overview` | OVERVIEW.md | Architecture overview patterns | -| `@libar-docs-decision` | DECISIONS.md | ADR-style decisions (auto-numbered) | -| `@libar-docs-intro` | (template placeholder only) | Package introduction (template placeholder) | - -## Format Options - -Used in template placeholders: `{{@libar-docs-core format=X}}` - -- `full` -- `list` -- `summary` diff --git a/docs-inbox/session-prompt-generator-architecture-review.md b/docs-inbox/session-prompt-generator-architecture-review.md index d3fb3051..3cf40919 100644 --- a/docs-inbox/session-prompt-generator-architecture-review.md +++ b/docs-inbox/session-prompt-generator-architecture-review.md @@ -90,13 +90,13 @@ The gap is **convention injection** — loading relevant rules from decision rec ## 4. Taxonomy Extension Evaluation -### `@libar-docs-convention` (P0) — Recommended with refinement +### `@architect-convention` (P0) — Recommended with refinement -This is useful. Decision records already have `@libar-docs-adr-category` (process/architecture/tooling), but that's too coarse. A convention like "Gherkin-only testing" and a convention like "FSM transition rules" both have `adr-category:process` but serve different prompt sections. +This is useful. Decision records already have `@architect-adr-category` (process/architecture/tooling), but that's too coarse. A convention like "Gherkin-only testing" and a convention like "FSM transition rules" both have `adr-category:process` but serve different prompt sections. -**Recommendation:** Add `@libar-docs-convention` as `csv` format. Values like `testing-policy`, `lint-rules`, `fsm-rules`, `cli-patterns`, `pattern-naming`. This is orthogonal to `adr-category`. +**Recommendation:** Add `@architect-convention` as `csv` format. Values like `testing-policy`, `lint-rules`, `fsm-rules`, `cli-patterns`, `pattern-naming`. This is orthogonal to `adr-category`. -### `@libar-docs-session-type` (P1) — Recommended but optional +### `@architect-session-type` (P1) — Recommended but optional Filtering conventions by session type is valuable. ADR-004 (Gherkin-only testing) applies to implementation sessions but not design sessions. However, this can be computed from the convention topic rather than tagged explicitly: @@ -109,7 +109,7 @@ Filtering conventions by session type is valuable. ADR-004 (Gherkin-only testing If the mapping is stable, hardcode it in the assembler. If it changes frequently, tag it. For now, I'd hardcode it and add the tag later if needed (YAGNI). -### `@libar-docs-prompt-section` (P2) — Not recommended +### `@architect-prompt-section` (P2) — Not recommended The Source Mapping system already supports `THIS DECISION (Rule: RuleName)` for extracting specific Rule blocks. This tag is redundant with existing infrastructure. @@ -154,7 +154,7 @@ function assembleSessionPrompt(api, dataset, options): 4. return { ...bundle, conventions, scopeResult } ``` -Step 3 is the only new thing: filter `dataset.patterns` for decision records with `@libar-docs-convention` tags, extract their Rule block content, group by convention topic. +Step 3 is the only new thing: filter `dataset.patterns` for decision records with `@architect-convention` tags, extract their Rule block content, group by convention topic. `★ Insight ─────────────────────────────────────` **The recipe system's real value — declarative content structure — can be preserved without using the recipe pipeline.** Define the prompt section ordering in a simple config or constant (which conventions go in which order, for which session types). This gives you the auditability of a recipe without the rendering overhead. The "recipe" is just a data structure, not a Gherkin feature file. @@ -166,9 +166,9 @@ Step 3 is the only new thing: filter `dataset.patterns` for decision records wit ### Step 1: Extract conventions into decision records (same as proposed) -Create ADR-009 (Coding Conventions), ADR-010 (CLI Patterns), ADR-011 (Pattern Naming). Tag existing ADRs with `@libar-docs-convention`. +Create ADR-009 (Coding Conventions), ADR-010 (CLI Patterns), ADR-011 (Pattern Naming). Tag existing ADRs with `@architect-convention`. -This is independently valuable — it makes conventions queryable via `pnpm process:query -- decisions`. +This is independently valuable — it makes conventions queryable via `pnpm architect:query -- decisions`. ### Step 2: Add `convention` tag to taxonomy @@ -198,7 +198,7 @@ The formatter: Add to `src/cli/process-api.ts` following the established CLI pattern. ```bash -pnpm process:query -- session-prompt DataAPIDesignSessionSupport --type implement +pnpm architect:query -- session-prompt DataAPIDesignSessionSupport --type implement ``` --- @@ -255,7 +255,7 @@ This is auditable, version-controlled, and doesn't require a template engine or ## Summary Recommendation 1. **Do** extract conventions into decision records (proposed Step 1) — this is the highest-value change -2. **Do** add `@libar-docs-convention` to the taxonomy (proposed P0) +2. **Do** add `@architect-convention` to the taxonomy (proposed P0) 3. **Don't** build a template engine — extend the existing assembler/formatter pattern instead 4. **Don't** route prompts through the recipe/markdown pipeline — use the text output path (ADR-008) 5. **Do** follow the `scope-validator.ts` / `handoff-generator.ts` pattern for the new module diff --git a/docs-inbox/session-prompt-generator-brief.md b/docs-inbox/session-prompt-generator-brief.md index eb9d20d7..2e5def11 100644 --- a/docs-inbox/session-prompt-generator-brief.md +++ b/docs-inbox/session-prompt-generator-brief.md @@ -1,7 +1,7 @@ # Pattern Brief: Session Prompt Generator > **Status:** Ready for Planning Session -> **Scope:** New capability for `@libar-dev/delivery-process` +> **Scope:** New capability for `@libar-dev/architect` > **Phase:** TBD (after DataAPIDesignSessionSupport) > **Depends on:** DataAPIDesignSessionSupport (completed), ProcessStateAPI (completed) @@ -29,8 +29,8 @@ Generate complete session prompts by composing: Expose via a new CLI subcommand: ```bash -pnpm process:query -- session-prompt --type implement -pnpm process:query -- session-prompt --type design +pnpm architect:query -- session-prompt --type implement +pnpm architect:query -- session-prompt --type design ``` --- @@ -97,33 +97,33 @@ ProcessStateAPI queries -----------------+ | `formatContextBundle()` | Yes | Text rendering with `=== SECTION ===` markers | | MasterDataset patterns | Yes | Decision records are already extracted as patterns | -**Only truly new piece:** Convention extraction — filter `dataset.patterns` for decision records with `@libar-docs-convention` tags, extract their Rule block content, group by topic. +**Only truly new piece:** Convention extraction — filter `dataset.patterns` for decision records with `@architect-convention` tags, extract their Rule block content, group by topic. --- ## Taxonomy Extension -### Required: `@libar-docs-convention` (csv format) +### Required: `@architect-convention` (csv format) -Classifies decision records as convention sources. Orthogonal to existing `@libar-docs-adr-category` (which is too coarse — "process" covers both testing policy and FSM rules). +Classifies decision records as convention sources. Orthogonal to existing `@architect-adr-category` (which is too coarse — "process" covers both testing policy and FSM rules). **Values:** `testing-policy`, `lint-rules`, `fsm-rules`, `cli-patterns`, `pattern-naming`, `session-workflow`, `output-format` **Example on existing decision records:** ```gherkin -@libar-docs-adr:004 -@libar-docs-convention:testing-policy +@architect-adr:004 +@architect-convention:testing-policy Feature: ADR-004 Gherkin-Only Testing ``` ```gherkin -@libar-docs-adr:008 -@libar-docs-convention:output-format +@architect-adr:008 +@architect-convention:output-format Feature: ADR-008 Text Output Path ``` -### Deferred: `@libar-docs-session-type` (csv format) +### Deferred: `@architect-session-type` (csv format) Filtering conventions by session type. Can be hardcoded initially since the mapping is stable: @@ -139,7 +139,7 @@ Filtering conventions by session type. Can be hardcoded initially since the mapp If this mapping changes frequently, promote to a taxonomy tag. Until then, YAGNI. -### Not Recommended: `@libar-docs-prompt-section` +### Not Recommended: `@architect-prompt-section` Redundant with existing Source Mapping `THIS DECISION (Rule: RuleName)` extraction. The assembler knows prompt structure programmatically — it doesn't need tags to discover it. @@ -176,14 +176,14 @@ CLAUDE.md retains its role as the entry point, but convention sections become ** ### Phase A: Convention Infrastructure -| Deliverable | Location | Tests | -| --------------------------------------- | --------------------------------------------------------------------- | ------------------ | -| Add `convention` tag to taxonomy | `src/taxonomy/registry-builder.ts` | Yes (unit) | -| Tag existing ADRs with convention | `delivery-process/decisions/adr-004,006,008.feature` | No (metadata only) | -| Create ADR-009 Coding Conventions | `delivery-process/decisions/adr-009-coding-conventions.feature` | No (spec only) | -| Create ADR-010 CLI Patterns | `delivery-process/decisions/adr-010-cli-patterns.feature` | No (spec only) | -| Create ADR-011 Pattern Naming | `delivery-process/decisions/adr-011-pattern-naming.feature` | No (spec only) | -| Create ADR-012 vitest-cucumber Patterns | `delivery-process/decisions/adr-012-vitest-cucumber-patterns.feature` | No (spec only) | +| Deliverable | Location | Tests | +| --------------------------------------- | -------------------------------------------------------------- | ------------------ | +| Add `convention` tag to taxonomy | `src/taxonomy/registry-builder.ts` | Yes (unit) | +| Tag existing ADRs with convention | `architect/decisions/adr-004,006,008.feature` | No (metadata only) | +| Create ADR-009 Coding Conventions | `architect/decisions/adr-009-coding-conventions.feature` | No (spec only) | +| Create ADR-010 CLI Patterns | `architect/decisions/adr-010-cli-patterns.feature` | No (spec only) | +| Create ADR-011 Pattern Naming | `architect/decisions/adr-011-pattern-naming.feature` | No (spec only) | +| Create ADR-012 vitest-cucumber Patterns | `architect/decisions/adr-012-vitest-cucumber-patterns.feature` | No (spec only) | ### Phase B: Convention Extraction @@ -215,7 +215,7 @@ CLAUDE.md retains its role as the entry point, but convention sections become ** ### DD-2: Convention Tags Over Session-Type Tags -**Decision:** Add `@libar-docs-convention` taxonomy tag. Defer `@libar-docs-session-type` — hardcode the convention-to-session mapping initially. +**Decision:** Add `@architect-convention` taxonomy tag. Defer `@architect-session-type` — hardcode the convention-to-session mapping initially. **Rationale:** The convention→session mapping is stable and small (7 conventions x 3 session types). A taxonomy tag adds maintenance burden for a mapping that rarely changes. Promote to a tag if the mapping grows or changes frequently. @@ -223,7 +223,7 @@ CLAUDE.md retains its role as the entry point, but convention sections become ** **Decision:** Conventions live in decision records (ADR/PDR), not in a separate convention format. -**Rationale:** Decision records already exist, are already extracted by the pipeline, already support Rule blocks with structured content, and are already queryable via `pnpm process:query -- decisions`. No new file format or extraction path needed. +**Rationale:** Decision records already exist, are already extracted by the pipeline, already support Rule blocks with structured content, and are already queryable via `pnpm architect:query -- decisions`. No new file format or extraction path needed. ### DD-4: Co-located Formatter Pattern @@ -238,7 +238,7 @@ CLAUDE.md retains its role as the entry point, but convention sections become ** **Rationale:** - Phase A alone makes conventions queryable via `decisions` command -- Phase A + B enables `pnpm process:query -- conventions --topic lint-rules` +- Phase A + B enables `pnpm architect:query -- conventions --topic lint-rules` - Phase A + B + C enables the full `session-prompt` subcommand No phase depends on all previous phases being perfect. @@ -304,8 +304,8 @@ Pattern: DataAPIDesignSessionSupport | Phase: 44 | Status: active When this feature is complete, the following should be true: -1. `pnpm process:query -- session-prompt --type implement` produces a complete implementation prompt -2. `pnpm process:query -- session-prompt --type design` produces a complete design prompt +1. `pnpm architect:query -- session-prompt --type implement` produces a complete implementation prompt +2. `pnpm architect:query -- session-prompt --type design` produces a complete design prompt 3. Convention content comes from decision records, not hardcoded strings 4. Adding a new convention = creating/tagging a decision record (no code changes to prompt generator) 5. Output uses `=== SECTION ===` text format (ADR-008 aligned) @@ -318,7 +318,7 @@ When this feature is complete, the following should be true: This brief is ready for a **Planning Session** to create the roadmap spec: ``` -delivery-process/specs/SessionPromptGenerator.feature +architect/specs/SessionPromptGenerator.feature ``` If the design decisions above are accepted, the design session can be skipped (DD-1 through DD-5 cover the major architectural choices). If any decisions need revision, run a design session first to explore alternatives. @@ -334,8 +334,8 @@ This Brief -> Planning Session -> Implementation Session (Phase A) **Context gathering for the planning session:** ```bash -pnpm process:query -- overview -pnpm process:query -- arch coverage -pnpm process:query -- tags -pnpm process:query -- decisions DataAPIDesignSessionSupport +pnpm architect:query -- overview +pnpm architect:query -- arch coverage +pnpm architect:query -- tags +pnpm architect:query -- decisions DataAPIDesignSessionSupport ``` diff --git a/docs-inbox/session-prompt-generator-manual.md b/docs-inbox/session-prompt-generator-manual.md index c24c19b4..d9dcafc9 100644 --- a/docs-inbox/session-prompt-generator-manual.md +++ b/docs-inbox/session-prompt-generator-manual.md @@ -19,26 +19,26 @@ Run these commands BEFORE reading any files. They replace explore agents for nav ```bash # 1. Implementation context bundle (deliverables, FSM state, deps) -pnpm process:query -- context DataAPIDesignSessionSupport --session implement +pnpm architect:query -- context DataAPIDesignSessionSupport --session implement # 2. Design stubs with target paths and resolution status -pnpm process:query -- stubs DataAPIDesignSessionSupport +pnpm architect:query -- stubs DataAPIDesignSessionSupport # 3. Dependency chain — confirm all deps are completed -pnpm process:query -- dep-tree DataAPIDesignSessionSupport +pnpm architect:query -- dep-tree DataAPIDesignSessionSupport # 4. Design decisions from stubs (DD-1 through DD-7) -pnpm process:query -- decisions DataAPIDesignSessionSupport +pnpm architect:query -- decisions DataAPIDesignSessionSupport # 5. How the completed context-assembler is wired (reusable helpers) -pnpm process:query -- arch neighborhood DataAPIContextAssembly +pnpm architect:query -- arch neighborhood DataAPIContextAssembly # 6. Existing implementation files for scope-validator target path -pnpm process:query -- files DataAPIDesignSessionSupport --related +pnpm architect:query -- files DataAPIDesignSessionSupport --related # 7. Verify no naming conflicts before creating patterns -pnpm process:query -- search ScopeValidator -pnpm process:query -- search HandoffGenerator +pnpm architect:query -- search ScopeValidator +pnpm architect:query -- search HandoffGenerator ``` Only use file reads for comprehension (how existing code works internally) — not for navigation (what exists and how it relates). @@ -47,19 +47,19 @@ Only use file reads for comprehension (how existing code works internally) — n After the API commands, read these for implementation patterns: -| File | Why | -| ------------------------------------------------------------------------------- | ---------------------------------------------------------- | -| Design stubs (2 files in `delivery-process/stubs/DataAPIDesignSessionSupport/`) | Approved types + function signatures | -| `delivery-process/decisions/pdr-002-session-workflow-commands.feature` | DD-1 through DD-7 design decisions | -| `delivery-process/specs/data-api-session-support.feature` | Spec with deliverables and scenarios | -| `src/api/context-assembler.ts` | Reusable helpers: `requirePattern()`, `resolveFsm()` | -| `src/api/context-formatter.ts` | `=== MARKERS ===` text formatting conventions | -| `src/cli/process-api.ts` | CLI subcommand wiring pattern (how to add new subcommands) | -| `src/validation/dod-validator.ts` | `isDeliverableComplete()` for handoff completion logic | +| File | Why | +| ------------------------------------------------------------------------ | ---------------------------------------------------------- | +| Design stubs (2 files in `architect/stubs/DataAPIDesignSessionSupport/`) | Approved types + function signatures | +| `architect/decisions/pdr-002-session-workflow-commands.feature` | DD-1 through DD-7 design decisions | +| `architect/specs/data-api-session-support.feature` | Spec with deliverables and scenarios | +| `src/api/context-assembler.ts` | Reusable helpers: `requirePattern()`, `resolveFsm()` | +| `src/api/context-formatter.ts` | `=== MARKERS ===` text formatting conventions | +| `src/cli/process-api.ts` | CLI subcommand wiring pattern (how to add new subcommands) | +| `src/validation/dod-validator.ts` | `isDeliverableComplete()` for handoff completion logic | ### Execution order (CRITICAL) -1. **Transition spec to `active` FIRST** — change `@libar-docs-status:roadmap` → `@libar-docs-status:active` in the spec file. Commit this change alone before writing any implementation code. +1. **Transition spec to `active` FIRST** — change `@architect-status:roadmap` → `@architect-status:active` in the spec file. Commit this change alone before writing any implementation code. 2. **Implement deliverables in dependency order:** - Scope validation logic (`src/api/scope-validator.ts`) — core functions, no CLI @@ -81,20 +81,20 @@ After each deliverable, verify using Process API commands: ```bash # After implementing scope-validator.ts — verify it's scanned -pnpm process:query -- search ScopeValidator +pnpm architect:query -- search ScopeValidator # After wiring CLI — verify subcommands work -pnpm process:query -- context DataAPIDesignSessionSupport --session implement +pnpm architect:query -- context DataAPIDesignSessionSupport --session implement # After implementing handoff-generator.ts -pnpm process:query -- stubs DataAPIDesignSessionSupport # should show targetExists: true +pnpm architect:query -- stubs DataAPIDesignSessionSupport # should show targetExists: true # After transitioning to completed — verify FSM -pnpm process:query -- pattern DataAPIDesignSessionSupport --fields status -pnpm process:query -- status # completion % should increase +pnpm architect:query -- pattern DataAPIDesignSessionSupport --fields status +pnpm architect:query -- status # completion % should increase # Final validation — the new commands should work on themselves -pnpm process:query -- overview # should reflect updated status +pnpm architect:query -- overview # should reflect updated status ``` ### Lint rules to remember @@ -115,7 +115,7 @@ pnpm process:query -- overview # should reflect updated status ### Pattern naming -Check `delivery-process/specs/*.feature` before choosing `@libar-docs-pattern` names in TypeScript. Implementation files must use a DIFFERENT pattern name + `@libar-docs-implements DataAPIDesignSessionSupport` to avoid conflicts with the Gherkin spec's pattern name. +Check `architect/specs/*.feature` before choosing `@architect-pattern` names in TypeScript. Implementation files must use a DIFFERENT pattern name + `@architect-implements DataAPIDesignSessionSupport` to avoid conflicts with the Gherkin spec's pattern name. --- diff --git a/docs-live/ARCHITECTURE.md b/docs-live/ARCHITECTURE.md index 94987235..284a33fb 100644 --- a/docs-live/ARCHITECTURE.md +++ b/docs-live/ARCHITECTURE.md @@ -48,7 +48,7 @@ graph TB RegexBuilders["RegexBuilders[infrastructure]"] ProjectConfigSchema["ProjectConfigSchema[infrastructure]"] SourceMerger["SourceMerger[service]"] - DeliveryProcessFactory["DeliveryProcessFactory[service]"] + ArchitectFactory["ArchitectFactory[service]"] DefineConfig["DefineConfig[infrastructure]"] ConfigLoader["ConfigLoader[infrastructure]"] end @@ -122,9 +122,9 @@ graph TB ProcessAPICLIImpl --> FuzzyMatcherImpl ProcessAPICLIImpl --> OutputPipelineImpl OutputPipelineImpl --> PatternSummarizerImpl - ConfigResolver --> DeliveryProcessFactory - DeliveryProcessFactory --> RegexBuilders - ConfigLoader --> DeliveryProcessFactory + ConfigResolver --> ArchitectFactory + ArchitectFactory --> RegexBuilders + ConfigLoader --> ArchitectFactory PatternSummarizerImpl --> ProcessStateAPI ScopeValidatorImpl --> ProcessStateAPI ScopeValidatorImpl --> MasterDataset @@ -172,168 +172,168 @@ graph TB All components with architecture annotations: -| Component | Context | Role | Layer | Source File | -| ----------------------------------------------------------------- | ---------- | -------------- | -------------- | ---------------------------------------------------------------------------- | -| 🚧 Pattern Helpers | api | - | domain | src/api/pattern-helpers.ts | -| ✅ Master Dataset | api | read-model | domain | src/validation-schemas/master-dataset.ts | -| 🚧 Arch Queries Impl | api | service | domain | src/api/arch-queries.ts | -| 🚧 Context Assembler Impl | api | service | application | src/api/context-assembler.ts | -| 🚧 Context Formatter Impl | api | service | application | src/api/context-formatter.ts | -| 🚧 Coverage Analyzer Impl | api | service | application | src/api/coverage-analyzer.ts | -| 🚧 Fuzzy Matcher Impl | api | service | application | src/api/fuzzy-match.ts | -| ✅ Handoff Generator Impl | api | service | application | src/api/handoff-generator.ts | -| 🚧 Pattern Summarizer Impl | api | service | application | src/api/summarize.ts | -| 🚧 Process State API | api | service | application | src/api/process-state.ts | -| ✅ Scope Validator Impl | api | service | application | src/api/scope-validator.ts | -| ✅ CLI Schema | cli | - | domain | src/cli/cli-schema.ts | -| 🚧 Dataset Cache | cli | infrastructure | infrastructure | src/cli/dataset-cache.ts | -| 🚧 Output Pipeline Impl | cli | service | application | src/cli/output-pipeline.ts | -| 🚧 Process API CLI Impl | cli | service | application | src/cli/process-api.ts | -| 🚧 Repl Mode | cli | service | application | src/cli/repl.ts | -| ✅ Configuration Defaults | config | - | domain | src/config/defaults.ts | -| ✅ Configuration Presets | config | - | domain | src/config/presets.ts | -| ✅ Configuration Types | config | - | domain | src/config/types.ts | -| 🚧 Project Config Types | config | - | domain | src/config/project-config.ts | -| ✅ Config Loader | config | infrastructure | infrastructure | src/config/config-loader.ts | -| 🚧 Define Config | config | infrastructure | infrastructure | src/config/define-config.ts | -| 🚧 Project Config Schema | config | infrastructure | infrastructure | src/config/project-config-schema.ts | -| ✅ Regex Builders | config | infrastructure | infrastructure | src/config/regex-builders.ts | -| ✅ Workflow Loader | config | infrastructure | infrastructure | src/config/workflow-loader.ts | -| 🚧 Config Resolver | config | service | application | src/config/resolve-config.ts | -| ✅ Delivery Process Factory | config | service | application | src/config/factory.ts | -| 🚧 Source Merger | config | service | application | src/config/merge-sources.ts | -| ✅ Document Extractor | extractor | service | application | src/extractor/doc-extractor.ts | -| ✅ Dual Source Extractor | extractor | service | application | src/extractor/dual-source-extractor.ts | -| ✅ Gherkin Extractor | extractor | service | application | src/extractor/gherkin-extractor.ts | -| Cli Recipe Generator | generator | - | application | src/generators/built-in/cli-recipe-generator.ts | -| ✅ Context Inference Impl | generator | - | application | src/generators/pipeline/context-inference.ts | -| 🚧 Git Branch Diff | generator | - | infrastructure | src/git/branch-diff.ts | -| 🚧 Git Helpers | generator | - | infrastructure | src/git/helpers.ts | -| 🚧 Git Module | generator | - | infrastructure | src/git/index.ts | -| 🚧 Git Name Status Parser | generator | - | infrastructure | src/git/name-status.ts | -| ✅ Process Api Reference Generator | generator | - | application | src/generators/built-in/process-api-reference-generator.ts | -| 🚧 Transform Types | generator | - | application | src/generators/pipeline/transform-types.ts | -| ✅ Content Deduplicator | generator | infrastructure | infrastructure | src/generators/content-deduplicator.ts | -| 🚧 File Cache | generator | infrastructure | infrastructure | src/cache/file-cache.ts | -| ✅ Source Mapper | generator | infrastructure | infrastructure | src/generators/source-mapper.ts | -| ✅ Codec Based Generator | generator | service | application | src/generators/codec-based.ts | -| ✅ Decision Doc Generator | generator | service | application | src/generators/built-in/decision-doc-generator.ts | -| 🚧 Design Review Generator | generator | service | application | src/generators/built-in/design-review-generator.ts | -| ✅ Documentation Generation Orchestrator | generator | service | application | src/generators/orchestrator.ts | -| 🚧 Relationship Resolver | generator | service | application | src/generators/pipeline/relationship-resolver.ts | -| 🚧 Sequence Transform Utils | generator | service | application | src/generators/pipeline/sequence-utils.ts | -| ✅ Transform Dataset | generator | service | application | src/generators/pipeline/transform-dataset.ts | -| 🚧 Process Guard Decider | lint | decider | application | src/lint/process-guard/decider.ts | -| ✅ Lint Engine | lint | service | application | src/lint/engine.ts | -| ✅ Lint Rules | lint | service | application | src/lint/rules.ts | -| loadPreambleFromMarkdown — Shared Markdown-to-SectionBlock Parser | renderer | - | domain | src/renderable/load-preamble.ts | -| ✅ Mermaid Diagram Utils | renderer | - | - | src/renderable/codecs/diagram-utils.ts | -| ✅ Architecture Codec | renderer | projection | application | src/renderable/codecs/architecture.ts | -| 🚧 Composite Codec | renderer | projection | application | src/renderable/codecs/composite.ts | -| ✅ Decision Doc Codec | renderer | projection | application | src/renderable/codecs/decision-doc.ts | -| 🚧 Design Review Codec | renderer | projection | application | src/renderable/codecs/design-review.ts | -| ✅ Patterns Codec | renderer | projection | application | src/renderable/codecs/patterns.ts | -| ✅ Session Codec | renderer | projection | application | src/renderable/codecs/session.ts | -| ✅ Renderable Document | renderer | read-model | domain | src/renderable/schema.ts | -| ✅ Document Generator | renderer | service | application | src/renderable/generate.ts | -| ✅ Universal Renderer | renderer | service | application | src/renderable/render.ts | -| ✅ Gherkin AST Parser | scanner | infrastructure | infrastructure | src/scanner/gherkin-ast-parser.ts | -| ✅ Gherkin Scanner | scanner | infrastructure | infrastructure | src/scanner/gherkin-scanner.ts | -| ✅ Pattern Scanner | scanner | infrastructure | infrastructure | src/scanner/pattern-scanner.ts | -| ✅ TypeScript AST Parser | scanner | infrastructure | infrastructure | src/scanner/ast-parser.ts | -| ✅ Category Definitions | taxonomy | read-model | domain | src/taxonomy/categories.ts | -| ✅ Tag Registry Builder | taxonomy | service | domain | src/taxonomy/registry-builder.ts | -| 🚧 FSM Validator | validation | decider | application | src/validation/fsm/validator.ts | -| 🚧 FSM States | validation | read-model | domain | src/validation/fsm/states.ts | -| 🚧 FSM Transitions | validation | read-model | domain | src/validation/fsm/transitions.ts | -| ✅ Anti Pattern Detector | validation | service | application | src/validation/anti-patterns.ts | -| ✅ DoD Validator | validation | service | application | src/validation/dod-validator.ts | -| 📋 ADR 001 Taxonomy Canonical Values | - | - | - | delivery-process/decisions/adr-001-taxonomy-canonical-values.feature | -| ✅ ADR 002 Gherkin Only Testing | - | - | - | delivery-process/decisions/adr-002-gherkin-only-testing.feature | -| 📋 ADR 003 Source First Pattern Architecture | - | - | - | delivery-process/decisions/adr-003-source-first-pattern-architecture.feature | -| ✅ ADR 005 Codec Based Markdown Rendering | - | - | - | delivery-process/decisions/adr-005-codec-based-markdown-rendering.feature | -| ✅ ADR 006 Single Read Model Architecture | - | - | - | delivery-process/decisions/adr-006-single-read-model-architecture.feature | -| ✅ Adr Document Codec | - | - | - | src/renderable/codecs/adr.ts | -| 🚧 API Module | - | - | - | src/api/index.ts | -| ✅ Built In Generators | - | - | - | src/generators/built-in/index.ts | -| ✅ Business Rules Codec | - | - | - | src/renderable/codecs/business-rules.ts | -| CategoryDefinition | - | - | - | src/taxonomy/categories.ts | -| 🚧 Claude Module Codec | - | - | - | src/renderable/codecs/claude-module.ts | -| 📋 Cli Behavior Testing | - | - | - | delivery-process/specs/cli-behavior-testing.feature | -| ✅ CLI Error Handler | - | - | - | src/cli/error-handler.ts | -| ✅ CLI Version Helper | - | - | - | src/cli/version.ts | -| ✅ Codec Base Options | - | - | - | src/renderable/codecs/types/base.ts | -| ✅ Codec Generator Registration | - | - | - | src/generators/built-in/codec-generators.ts | -| ✅ Config Based Workflow Definition | - | - | - | delivery-process/specs/config-based-workflow-definition.feature | -| 🚧 Deliverable Status Taxonomy | - | - | - | src/taxonomy/deliverable-status.ts | -| 🚧 Deliverable Status Taxonomy Testing | - | - | - | tests/features/types/deliverable-status.feature | -| 🚧 Derive Process State | - | - | - | src/lint/process-guard/derive-state.ts | -| 🚧 Detect Changes | - | - | - | src/lint/process-guard/detect-changes.ts | -| ✅ Documentation Generator CLI | - | - | - | src/cli/generate-docs.ts | -| ✅ Document Codecs | - | - | - | src/renderable/codecs/index.ts | -| ✅ DoD Validation Types | - | - | - | src/validation/types.ts | -| 📋 Effort Variance Tracking | - | - | - | delivery-process/specs/effort-variance-tracking.feature | -| ✅ Error Factories | - | - | - | tests/features/types/error-factories.feature | -| ✅ Error Factory Types | - | - | - | src/types/errors.ts | -| ✅ Error Handling Unification | - | - | - | tests/features/behavior/error-handling.feature | -| 🚧 File Cache Testing | - | - | - | tests/features/utils/file-cache.feature | -| ✅ Format Types | - | - | - | src/taxonomy/format-types.ts | -| 🚧 FSM Module | - | - | - | src/validation/fsm/index.ts | -| ✅ Generator Registry | - | - | - | src/generators/registry.ts | -| ✅ Generator Types | - | - | - | src/generators/types.ts | -| ✅ Hierarchy Levels | - | - | - | src/taxonomy/hierarchy-levels.ts | -| ✅ Index Codec | - | - | - | src/renderable/codecs/index-codec.ts | -| ✅ Kebab Case Slugs | - | - | - | tests/features/behavior/kebab-case-slugs.feature | -| ✅ Layer Inference | - | - | - | src/extractor/layer-inference.ts | -| ✅ Layer Types | - | - | - | src/taxonomy/layer-types.ts | -| ✅ Lint Module | - | - | - | src/lint/index.ts | -| ✅ Lint Patterns CLI | - | - | - | src/cli/lint-patterns.ts | -| 🚧 Lint Process CLI | - | - | - | src/cli/lint-process.ts | -| 📋 Living Roadmap CLI | - | - | - | delivery-process/specs/living-roadmap-cli.feature | -| ✅ Merge Patterns | - | - | - | src/generators/pipeline/merge-patterns.ts | -| ✅ Mvp Workflow Implementation | - | - | - | delivery-process/specs/mvp-workflow-implementation.feature | -| ✅ Normalized Status | - | - | - | src/taxonomy/normalized-status.ts | -| 🚧 Normalized Status Testing | - | - | - | tests/features/types/normalized-status.feature | -| ✅ Orchestrator Pipeline Factory Migration | - | - | - | delivery-process/specs/orchestrator-pipeline-factory-migration.feature | -| ✅ Pipeline Factory | - | - | - | src/generators/pipeline/build-pipeline.ts | -| ✅ Pipeline Module | - | - | - | src/generators/pipeline/index.ts | -| ✅ Planning Codecs | - | - | - | src/renderable/codecs/planning.ts | -| ✅ Pr Changes Codec | - | - | - | src/renderable/codecs/pr-changes.ts | -| ✅ Process API Layered Extraction | - | - | - | delivery-process/specs/process-api-layered-extraction.feature | -| 🚧 Process Guard Module | - | - | - | src/lint/process-guard/index.ts | -| ✅ Process Guard Testing | - | - | - | tests/features/validation/process-guard.feature | -| 🚧 Process Guard Types | - | - | - | src/lint/process-guard/types.ts | -| 🚧 Process State Types | - | - | - | src/api/types.ts | -| 🚧 Reference Document Codec | - | - | - | src/renderable/codecs/reference.ts | -| 🚧 Reference Generator Registration | - | - | - | src/generators/built-in/reference-generators.ts | -| ✅ Renderable Document Model(RDM) | - | - | - | src/renderable/index.ts | -| ✅ Renderable Utils | - | - | - | src/renderable/utils.ts | -| ✅ Reporting Codecs | - | - | - | src/renderable/codecs/reporting.ts | -| ✅ Requirements Codec | - | - | - | src/renderable/codecs/requirements.ts | -| ✅ Result Monad | - | - | - | tests/features/types/result-monad.feature | -| ✅ Result Monad Types | - | - | - | src/types/result.ts | -| ✅ Rich Content Helpers | - | - | - | src/renderable/codecs/helpers.ts | -| ✅ Risk Levels | - | - | - | src/taxonomy/risk-levels.ts | -| ✅ Rules Query Module | - | - | - | src/api/rules-query.ts | -| SectionBlock | - | - | - | src/renderable/schema.ts | -| 📋 Session File Cleanup | - | - | - | delivery-process/specs/session-file-cleanup.feature | -| ✅ Session File Lifecycle | - | - | - | tests/features/behavior/session-file-lifecycle.feature | -| ✅ Session Guides Module Source | - | - | - | delivery-process/specs/session-guides-module-source.feature | -| ✅ Session Handoffs | - | - | - | tests/features/behavior/session-handoffs.feature | -| ✅ Shape Extractor | - | - | - | src/extractor/shape-extractor.ts | -| ✅ Shared Codec Schema | - | - | - | src/renderable/codecs/shared-schema.ts | -| ✅ Source Mapping Validator | - | - | - | src/generators/source-mapping-validator.ts | -| ✅ Status Values | - | - | - | src/taxonomy/status-values.ts | -| 📋 Step Definition Completion | - | - | - | delivery-process/specs/step-definition-completion.feature | -| ✅ String Utils | - | - | - | tests/features/utils/string-utils.feature | -| 🚧 Stub Resolver Impl | - | - | - | src/api/stub-resolver.ts | -| 🚧 Tag Registry Builder Testing | - | - | - | tests/features/types/tag-registry-builder.feature | -| ⏸️ Tag Taxonomy CLI | - | - | - | src/cli/generate-tag-taxonomy.ts | -| ✅ Taxonomy Codec | - | - | - | src/renderable/codecs/taxonomy.ts | -| ✅ Timeline Codec | - | - | - | src/renderable/codecs/timeline.ts | -| ✅ Validate Patterns CLI | - | - | - | src/cli/validate-patterns.ts | -| ✅ Validation Module | - | - | - | src/validation/index.ts | -| ✅ Validation Rules Codec | - | - | - | src/renderable/codecs/validation-rules.ts | -| ✅ Validator Read Model Consolidation | - | - | - | delivery-process/specs/validator-read-model-consolidation.feature | -| ✅ Warning Collector | - | - | - | src/generators/warning-collector.ts | -| 📋 Convention Annotation Example — DD-3 Decision | - | decider | - | delivery-process/stubs/error-guide-codec/convention-annotation-example.ts | +| Component | Context | Role | Layer | Source File | +| ----------------------------------------------------------------- | ---------- | -------------- | -------------- | --------------------------------------------------------------------- | +| 🚧 Pattern Helpers | api | - | domain | src/api/pattern-helpers.ts | +| ✅ Master Dataset | api | read-model | domain | src/validation-schemas/master-dataset.ts | +| 🚧 Arch Queries Impl | api | service | domain | src/api/arch-queries.ts | +| 🚧 Context Assembler Impl | api | service | application | src/api/context-assembler.ts | +| 🚧 Context Formatter Impl | api | service | application | src/api/context-formatter.ts | +| 🚧 Coverage Analyzer Impl | api | service | application | src/api/coverage-analyzer.ts | +| 🚧 Fuzzy Matcher Impl | api | service | application | src/api/fuzzy-match.ts | +| ✅ Handoff Generator Impl | api | service | application | src/api/handoff-generator.ts | +| 🚧 Pattern Summarizer Impl | api | service | application | src/api/summarize.ts | +| 🚧 Process State API | api | service | application | src/api/process-state.ts | +| ✅ Scope Validator Impl | api | service | application | src/api/scope-validator.ts | +| ✅ CLI Schema | cli | - | domain | src/cli/cli-schema.ts | +| 🚧 Dataset Cache | cli | infrastructure | infrastructure | src/cli/dataset-cache.ts | +| 🚧 Output Pipeline Impl | cli | service | application | src/cli/output-pipeline.ts | +| 🚧 Process API CLI Impl | cli | service | application | src/cli/process-api.ts | +| 🚧 Repl Mode | cli | service | application | src/cli/repl.ts | +| ✅ Configuration Defaults | config | - | domain | src/config/defaults.ts | +| ✅ Configuration Presets | config | - | domain | src/config/presets.ts | +| ✅ Configuration Types | config | - | domain | src/config/types.ts | +| 🚧 Project Config Types | config | - | domain | src/config/project-config.ts | +| ✅ Config Loader | config | infrastructure | infrastructure | src/config/config-loader.ts | +| 🚧 Define Config | config | infrastructure | infrastructure | src/config/define-config.ts | +| 🚧 Project Config Schema | config | infrastructure | infrastructure | src/config/project-config-schema.ts | +| ✅ Regex Builders | config | infrastructure | infrastructure | src/config/regex-builders.ts | +| ✅ Workflow Loader | config | infrastructure | infrastructure | src/config/workflow-loader.ts | +| 🚧 Config Resolver | config | service | application | src/config/resolve-config.ts | +| ✅ Delivery Process Factory | config | service | application | src/config/factory.ts | +| 🚧 Source Merger | config | service | application | src/config/merge-sources.ts | +| ✅ Document Extractor | extractor | service | application | src/extractor/doc-extractor.ts | +| ✅ Dual Source Extractor | extractor | service | application | src/extractor/dual-source-extractor.ts | +| ✅ Gherkin Extractor | extractor | service | application | src/extractor/gherkin-extractor.ts | +| Cli Recipe Generator | generator | - | application | src/generators/built-in/cli-recipe-generator.ts | +| ✅ Context Inference Impl | generator | - | application | src/generators/pipeline/context-inference.ts | +| 🚧 Git Branch Diff | generator | - | infrastructure | src/git/branch-diff.ts | +| 🚧 Git Helpers | generator | - | infrastructure | src/git/helpers.ts | +| 🚧 Git Module | generator | - | infrastructure | src/git/index.ts | +| 🚧 Git Name Status Parser | generator | - | infrastructure | src/git/name-status.ts | +| ✅ Process Api Reference Generator | generator | - | application | src/generators/built-in/process-api-reference-generator.ts | +| 🚧 Transform Types | generator | - | application | src/generators/pipeline/transform-types.ts | +| ✅ Content Deduplicator | generator | infrastructure | infrastructure | src/generators/content-deduplicator.ts | +| 🚧 File Cache | generator | infrastructure | infrastructure | src/cache/file-cache.ts | +| ✅ Source Mapper | generator | infrastructure | infrastructure | src/generators/source-mapper.ts | +| ✅ Codec Based Generator | generator | service | application | src/generators/codec-based.ts | +| ✅ Decision Doc Generator | generator | service | application | src/generators/built-in/decision-doc-generator.ts | +| 🚧 Design Review Generator | generator | service | application | src/generators/built-in/design-review-generator.ts | +| ✅ Documentation Generation Orchestrator | generator | service | application | src/generators/orchestrator.ts | +| 🚧 Relationship Resolver | generator | service | application | src/generators/pipeline/relationship-resolver.ts | +| 🚧 Sequence Transform Utils | generator | service | application | src/generators/pipeline/sequence-utils.ts | +| ✅ Transform Dataset | generator | service | application | src/generators/pipeline/transform-dataset.ts | +| 🚧 Process Guard Decider | lint | decider | application | src/lint/process-guard/decider.ts | +| ✅ Lint Engine | lint | service | application | src/lint/engine.ts | +| ✅ Lint Rules | lint | service | application | src/lint/rules.ts | +| loadPreambleFromMarkdown — Shared Markdown-to-SectionBlock Parser | renderer | - | domain | src/renderable/load-preamble.ts | +| ✅ Mermaid Diagram Utils | renderer | - | - | src/renderable/codecs/diagram-utils.ts | +| ✅ Architecture Codec | renderer | projection | application | src/renderable/codecs/architecture.ts | +| 🚧 Composite Codec | renderer | projection | application | src/renderable/codecs/composite.ts | +| ✅ Decision Doc Codec | renderer | projection | application | src/renderable/codecs/decision-doc.ts | +| 🚧 Design Review Codec | renderer | projection | application | src/renderable/codecs/design-review.ts | +| ✅ Patterns Codec | renderer | projection | application | src/renderable/codecs/patterns.ts | +| ✅ Session Codec | renderer | projection | application | src/renderable/codecs/session.ts | +| ✅ Renderable Document | renderer | read-model | domain | src/renderable/schema.ts | +| ✅ Document Generator | renderer | service | application | src/renderable/generate.ts | +| ✅ Universal Renderer | renderer | service | application | src/renderable/render.ts | +| ✅ Gherkin AST Parser | scanner | infrastructure | infrastructure | src/scanner/gherkin-ast-parser.ts | +| ✅ Gherkin Scanner | scanner | infrastructure | infrastructure | src/scanner/gherkin-scanner.ts | +| ✅ Pattern Scanner | scanner | infrastructure | infrastructure | src/scanner/pattern-scanner.ts | +| ✅ TypeScript AST Parser | scanner | infrastructure | infrastructure | src/scanner/ast-parser.ts | +| ✅ Category Definitions | taxonomy | read-model | domain | src/taxonomy/categories.ts | +| ✅ Tag Registry Builder | taxonomy | service | domain | src/taxonomy/registry-builder.ts | +| 🚧 FSM Validator | validation | decider | application | src/validation/fsm/validator.ts | +| 🚧 FSM States | validation | read-model | domain | src/validation/fsm/states.ts | +| 🚧 FSM Transitions | validation | read-model | domain | src/validation/fsm/transitions.ts | +| ✅ Anti Pattern Detector | validation | service | application | src/validation/anti-patterns.ts | +| ✅ DoD Validator | validation | service | application | src/validation/dod-validator.ts | +| 📋 ADR 001 Taxonomy Canonical Values | - | - | - | architect/decisions/adr-001-taxonomy-canonical-values.feature | +| ✅ ADR 002 Gherkin Only Testing | - | - | - | architect/decisions/adr-002-gherkin-only-testing.feature | +| 📋 ADR 003 Source First Pattern Architecture | - | - | - | architect/decisions/adr-003-source-first-pattern-architecture.feature | +| ✅ ADR 005 Codec Based Markdown Rendering | - | - | - | architect/decisions/adr-005-codec-based-markdown-rendering.feature | +| ✅ ADR 006 Single Read Model Architecture | - | - | - | architect/decisions/adr-006-single-read-model-architecture.feature | +| ✅ Adr Document Codec | - | - | - | src/renderable/codecs/adr.ts | +| 🚧 API Module | - | - | - | src/api/index.ts | +| ✅ Built In Generators | - | - | - | src/generators/built-in/index.ts | +| ✅ Business Rules Codec | - | - | - | src/renderable/codecs/business-rules.ts | +| CategoryDefinition | - | - | - | src/taxonomy/categories.ts | +| 🚧 Claude Module Codec | - | - | - | src/renderable/codecs/claude-module.ts | +| 📋 Cli Behavior Testing | - | - | - | architect/specs/cli-behavior-testing.feature | +| ✅ CLI Error Handler | - | - | - | src/cli/error-handler.ts | +| ✅ CLI Version Helper | - | - | - | src/cli/version.ts | +| ✅ Codec Base Options | - | - | - | src/renderable/codecs/types/base.ts | +| ✅ Codec Generator Registration | - | - | - | src/generators/built-in/codec-generators.ts | +| ✅ Config Based Workflow Definition | - | - | - | architect/specs/config-based-workflow-definition.feature | +| 🚧 Deliverable Status Taxonomy | - | - | - | src/taxonomy/deliverable-status.ts | +| 🚧 Deliverable Status Taxonomy Testing | - | - | - | tests/features/types/deliverable-status.feature | +| 🚧 Derive Process State | - | - | - | src/lint/process-guard/derive-state.ts | +| 🚧 Detect Changes | - | - | - | src/lint/process-guard/detect-changes.ts | +| ✅ Documentation Generator CLI | - | - | - | src/cli/generate-docs.ts | +| ✅ Document Codecs | - | - | - | src/renderable/codecs/index.ts | +| ✅ DoD Validation Types | - | - | - | src/validation/types.ts | +| 📋 Effort Variance Tracking | - | - | - | architect/specs/effort-variance-tracking.feature | +| ✅ Error Factories | - | - | - | tests/features/types/error-factories.feature | +| ✅ Error Factory Types | - | - | - | src/types/errors.ts | +| ✅ Error Handling Unification | - | - | - | tests/features/behavior/error-handling.feature | +| 🚧 File Cache Testing | - | - | - | tests/features/utils/file-cache.feature | +| ✅ Format Types | - | - | - | src/taxonomy/format-types.ts | +| 🚧 FSM Module | - | - | - | src/validation/fsm/index.ts | +| ✅ Generator Registry | - | - | - | src/generators/registry.ts | +| ✅ Generator Types | - | - | - | src/generators/types.ts | +| ✅ Hierarchy Levels | - | - | - | src/taxonomy/hierarchy-levels.ts | +| ✅ Index Codec | - | - | - | src/renderable/codecs/index-codec.ts | +| ✅ Kebab Case Slugs | - | - | - | tests/features/behavior/kebab-case-slugs.feature | +| ✅ Layer Inference | - | - | - | src/extractor/layer-inference.ts | +| ✅ Layer Types | - | - | - | src/taxonomy/layer-types.ts | +| ✅ Lint Module | - | - | - | src/lint/index.ts | +| ✅ Lint Patterns CLI | - | - | - | src/cli/lint-patterns.ts | +| 🚧 Lint Process CLI | - | - | - | src/cli/lint-process.ts | +| 📋 Living Roadmap CLI | - | - | - | architect/specs/living-roadmap-cli.feature | +| ✅ Merge Patterns | - | - | - | src/generators/pipeline/merge-patterns.ts | +| ✅ Mvp Workflow Implementation | - | - | - | architect/specs/mvp-workflow-implementation.feature | +| ✅ Normalized Status | - | - | - | src/taxonomy/normalized-status.ts | +| 🚧 Normalized Status Testing | - | - | - | tests/features/types/normalized-status.feature | +| ✅ Orchestrator Pipeline Factory Migration | - | - | - | architect/specs/orchestrator-pipeline-factory-migration.feature | +| ✅ Pipeline Factory | - | - | - | src/generators/pipeline/build-pipeline.ts | +| ✅ Pipeline Module | - | - | - | src/generators/pipeline/index.ts | +| ✅ Planning Codecs | - | - | - | src/renderable/codecs/planning.ts | +| ✅ Pr Changes Codec | - | - | - | src/renderable/codecs/pr-changes.ts | +| ✅ Process API Layered Extraction | - | - | - | architect/specs/process-api-layered-extraction.feature | +| 🚧 Process Guard Module | - | - | - | src/lint/process-guard/index.ts | +| ✅ Process Guard Testing | - | - | - | tests/features/validation/process-guard.feature | +| 🚧 Process Guard Types | - | - | - | src/lint/process-guard/types.ts | +| 🚧 Process State Types | - | - | - | src/api/types.ts | +| 🚧 Reference Document Codec | - | - | - | src/renderable/codecs/reference.ts | +| 🚧 Reference Generator Registration | - | - | - | src/generators/built-in/reference-generators.ts | +| ✅ Renderable Document Model(RDM) | - | - | - | src/renderable/index.ts | +| ✅ Renderable Utils | - | - | - | src/renderable/utils.ts | +| ✅ Reporting Codecs | - | - | - | src/renderable/codecs/reporting.ts | +| ✅ Requirements Codec | - | - | - | src/renderable/codecs/requirements.ts | +| ✅ Result Monad | - | - | - | tests/features/types/result-monad.feature | +| ✅ Result Monad Types | - | - | - | src/types/result.ts | +| ✅ Rich Content Helpers | - | - | - | src/renderable/codecs/helpers.ts | +| ✅ Risk Levels | - | - | - | src/taxonomy/risk-levels.ts | +| ✅ Rules Query Module | - | - | - | src/api/rules-query.ts | +| SectionBlock | - | - | - | src/renderable/schema.ts | +| 📋 Session File Cleanup | - | - | - | architect/specs/session-file-cleanup.feature | +| ✅ Session File Lifecycle | - | - | - | tests/features/behavior/session-file-lifecycle.feature | +| ✅ Session Guides Module Source | - | - | - | architect/specs/session-guides-module-source.feature | +| ✅ Session Handoffs | - | - | - | tests/features/behavior/session-handoffs.feature | +| ✅ Shape Extractor | - | - | - | src/extractor/shape-extractor.ts | +| ✅ Shared Codec Schema | - | - | - | src/renderable/codecs/shared-schema.ts | +| ✅ Source Mapping Validator | - | - | - | src/generators/source-mapping-validator.ts | +| ✅ Status Values | - | - | - | src/taxonomy/status-values.ts | +| 📋 Step Definition Completion | - | - | - | architect/specs/step-definition-completion.feature | +| ✅ String Utils | - | - | - | tests/features/utils/string-utils.feature | +| 🚧 Stub Resolver Impl | - | - | - | src/api/stub-resolver.ts | +| 🚧 Tag Registry Builder Testing | - | - | - | tests/features/types/tag-registry-builder.feature | +| ⏸️ Tag Taxonomy CLI | - | - | - | src/cli/generate-tag-taxonomy.ts | +| ✅ Taxonomy Codec | - | - | - | src/renderable/codecs/taxonomy.ts | +| ✅ Timeline Codec | - | - | - | src/renderable/codecs/timeline.ts | +| ✅ Validate Patterns CLI | - | - | - | src/cli/validate-patterns.ts | +| ✅ Validation Module | - | - | - | src/validation/index.ts | +| ✅ Validation Rules Codec | - | - | - | src/renderable/codecs/validation-rules.ts | +| ✅ Validator Read Model Consolidation | - | - | - | architect/specs/validator-read-model-consolidation.feature | +| ✅ Warning Collector | - | - | - | src/generators/warning-collector.ts | +| 📋 Convention Annotation Example — DD-3 Decision | - | decider | - | architect/stubs/error-guide-codec/convention-annotation-example.ts | diff --git a/docs-live/CHANGELOG-GENERATED.md b/docs-live/CHANGELOG-GENERATED.md index 56e79ccb..a997a15e 100644 --- a/docs-live/CHANGELOG-GENERATED.md +++ b/docs-live/CHANGELOG-GENERATED.md @@ -18,9 +18,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Git Module**: Shared git utilities used by both generators and lint layers. - **Git Helpers**: Low-level helpers for safe git command execution and input sanitization. - **Git Branch Diff**: Provides lightweight git diff operations for determining which files changed relative to a base branch. -- **Config Resolver**: Resolves a raw `DeliveryProcessProjectConfig` into a fully-resolved `ResolvedConfig` with all defaults applied, stubs... -- **Project Config Types**: Unified project configuration for the delivery-process package. -- **Project Config Schema**: Zod validation schema for `DeliveryProcessProjectConfig`. +- **Config Resolver**: Resolves a raw `ArchitectProjectConfig` into a fully-resolved `ResolvedConfig` with all defaults applied, stubs... +- **Project Config Types**: Unified project configuration for the Architect package. +- **Project Config Schema**: Zod validation schema for `ArchitectProjectConfig`. - **Source Merger**: Computes effective sources for a specific generator by applying per-generator overrides to the base resolved sources. - **Define Config**: Identity function for type-safe project configuration. - **Repl Mode**: Loads the pipeline once and accepts multiple queries on stdin. @@ -51,8 +51,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Claude Module Codec**: :Generation Transforms MasterDataset into RenderableDocuments for CLAUDE.md module generation. - **Process Guard Types**: :FSMValidator Defines types for the process guard linter including: - Process state derived from file annotations -... - **Process Guard Module**: :FSMValidator,DeriveProcessState,DetectChanges,ProcessGuardDecider Enforces delivery process rules by validating... -- **Detect Changes**: Detects changes from git diff including: - Modified, added, deleted files - Status transitions (@libar-docs-status... -- **Derive Process State**: :GherkinScanner,FSMValidator Derives process state from @libar-docs-\* annotations in files. +- **Detect Changes**: Detects changes from git diff including: - Modified, added, deleted files - Status transitions (@architect-status... +- **Derive Process State**: :GherkinScanner,FSMValidator Derives process state from @architect-\* annotations in files. - **Process Guard Decider**: :FSMValidator,DeriveProcessState,DetectChanges Pure function that validates changes against process rules. - **Reference Generator Registration**: Registers all reference document generators. - **Design Review Generator**: :Generation Generates design review documents for patterns with sequence annotations. @@ -86,8 +86,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Fuzzy Match Tests**: Validates tiered fuzzy matching: exact > prefix > substring > Levenshtein. - **Context Formatter Tests**: Tests for formatContextBundle(), formatDepTree(), formatFileReadingList(), and formatOverview() plain text rendering... - **Context Assembler Tests**: Tests for assembleContext(), buildDepTree(), buildFileReadingList(), and buildOverview() pure functions that operate... -- **Uses Tag Testing**: Tests extraction and processing of @libar-docs-uses and @libar-docs-used-by relationship tags from TypeScript files. -- **Depends On Tag Testing**: Tests extraction of @libar-docs-depends-on and @libar-docs-enables relationship tags from Gherkin files. +- **Uses Tag Testing**: Tests extraction and processing of @architect-uses and @architect-used-by relationship tags from TypeScript files. +- **Depends On Tag Testing**: Tests extraction of @architect-depends-on and @architect-enables relationship tags from Gherkin files. --- @@ -99,7 +99,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Process Guard Linter**: During planning and implementation sessions, accidental modifications occur: - Specs outside the intended scope get... - **Phase State Machine Validation**: Phase lifecycle state transitions are not enforced programmatically despite being documented in PROCESS_SETUP.md. - **Pattern Relationship Model**: Problem: The delivery process lacks a comprehensive relationship model between artifacts. -- **Mvp Workflow Implementation**: PDR-005 defines a 4-state workflow FSM (`roadmap, active, completed, deferred`) but the delivery-process package... +- **Mvp Workflow Implementation**: PDR-005 defines a 4-state workflow FSM (`roadmap, active, completed, deferred`) but the Architect package... - **Gherkin Rules Support**: Feature files were limited to flat scenario lists. --- @@ -108,7 +108,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). ### Added -- **Public API**: Main entry point for the @libar-dev/delivery-process package. +- **Public API**: Main entry point for the @libar-dev/architect package. - **Index Preamble Configuration — DD-3, DD-4 Decisions**: Decision DD-3 (Audience paths: preamble vs annotation-derived): Use full preamble for audience reading paths. - **IndexCodec Factory — DD-1 Implementation Stub**: Creates the IndexCodec as a Zod codec (MasterDataset -> RenderableDocument). - **IndexCodecOptions — DD-1, DD-5 Decisions**: Decision DD-1 (New IndexCodec vs extend existing): Create a new IndexCodec registered in CodecRegistry, NOT a... @@ -116,31 +116,31 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Tag Registry Configuration**: Defines the structure and validation for tag taxonomy configuration. - **Output Schemas**: Zod schemas for JSON output formats used by CLI tools. - **Master Dataset**: Defines the schema for a pre-computed dataset that holds all extracted patterns along with derived views (by status,... -- **Extracted Shape Schema**: Zod schema for TypeScript type definitions extracted from source files via the @libar-docs-extract-shapes tag. +- **Extracted Shape Schema**: Zod schema for TypeScript type definitions extracted from source files via the @architect-extract-shapes tag. - **Extracted Pattern Schema**: Zod schema for validating complete extracted patterns with code, metadata, relationships, and source information. - **Dual Source Schemas**: Zod schemas for dual-source extraction types. -- **Doc Directive Schema**: Zod schemas for validating parsed @libar-docs-\* directives from JSDoc comments. +- **Doc Directive Schema**: Zod schemas for validating parsed @architect-\* directives from JSDoc comments. - **Codec Utils**: Provides factory functions for creating type-safe JSON parsing and serialization pipelines using Zod schemas. - **Result Monad Types**: Explicit error handling via discriminated union. - **Error Factory Types**: Structured, discriminated error types with factory functions. -- **String Utilities**: Provides shared utilities for string manipulation used across the delivery-process package, including slugification... -- **Utils Module**: Common helper functions used across the delivery-process package. +- **String Utilities**: Provides shared utilities for string manipulation used across the Architect package, including slugification... +- **Utils Module**: Common helper functions used across the Architect package. - **Pattern Id Generator**: Generates unique, deterministic pattern IDs based on file path and line number. - **Collection Utilities**: Provides shared utilities for working with arrays and collections, such as grouping items by a key function. - **DoD Validation Types**: Types and schemas for Definition of Done (DoD) validation and anti-pattern detection. - **Validation Module**: Barrel export for validation module providing: - Definition of Done (DoD) validation for completed phases -... - **DoD Validator**: Validates that completed phases meet Definition of Done criteria: 1. - **Anti Pattern Detector**: Detects violations of the dual-source documentation architecture and process hygiene issues that lead to... -- **Pattern Scanner**: Discovers TypeScript files matching glob patterns and filters to only those with `@libar-docs` opt-in. +- **Pattern Scanner**: Discovers TypeScript files matching glob patterns and filters to only those with `@architect` opt-in. - **Gherkin Scanner**: Scans .feature files for pattern metadata encoded in Gherkin tags. - **Gherkin AST Parser**: Parses Gherkin feature files using @cucumber/gherkin and extracts structured data including feature metadata, tags,... -- **TypeScript AST Parser**: Parses TypeScript source files using @typescript-eslint/typescript-estree to extract @libar-docs-\* directives with... +- **TypeScript AST Parser**: Parses TypeScript source files using @typescript-eslint/typescript-estree to extract @architect-\* directives with... - **Renderable Utils**: Utility functions for document codecs. - **Renderable Document**: Universal intermediate format for all generated documentation. - **Universal Renderer**: Converts RenderableDocument to output strings. - **Renderable Document Model(RDM)**: Unified document generation using codecs and a universal renderer. - **Document Generator**: Simplified document generation using codecs. -- **Lint Rules**: Defines lint rules that check @libar-docs-\* directives for completeness and quality. +- **Lint Rules**: Defines lint rules that check @architect-\* directives for completeness and quality. - **Lint Module**: Provides lint rules and engine for pattern annotation quality checking. - **Lint Engine**: Orchestrates lint rule execution against parsed directives. - **Warning Collector**: Provides a unified system for capturing, categorizing, and reporting non-fatal issues during document generation. @@ -154,15 +154,15 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Shape Extractor**: Extracts TypeScript type definitions (interfaces, type aliases, enums, function signatures) from source files for... - **Layer Inference**: Infers feature file layer (timeline, domain, integration, e2e, component) from directory path patterns. - **Gherkin Extractor**: Transforms scanned Gherkin feature files into ExtractedPattern objects for inclusion in generated documentation. -- **Dual Source Extractor**: Extracts pattern metadata from both TypeScript code stubs (@libar-docs-_) and Gherkin feature files (@libar-docs-_),... +- **Dual Source Extractor**: Extracts pattern metadata from both TypeScript code stubs (@architect-_) and Gherkin feature files (@architect-_),... - **Document Extractor**: Converts scanned file data into complete ExtractedPattern objects with unique IDs, inferred names, categories, and... - **Workflow Loader**: Provides the default 6-phase workflow as an inline constant and loads custom workflow overrides from JSON files via... - **Configuration Types**: Type definitions for the delivery process configuration system. - **Regex Builders**: Type-safe regex factory functions for tag detection and normalization. - **Configuration Presets**: Predefined configuration presets for common use cases. - **Delivery Process Factory**: Main factory function for creating configured delivery process instances. -- **Configuration Defaults**: Centralized default constants for the delivery-process package. -- **Config Loader**: Discovers and loads `delivery-process.config.ts` files for hierarchical configuration. +- **Configuration Defaults**: Centralized default constants for the Architect package. +- **Config Loader**: Discovers and loads `architect.config.ts` files for hierarchical configuration. - **CLI Version Helper**: Reads package version from package.json for CLI --version flag. - **Validate Patterns CLI**: Cross-validates TypeScript patterns vs Gherkin feature files. - **Lint Patterns CLI**: Validates pattern annotations for quality and completeness. @@ -208,7 +208,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Context Inference Impl**: Auto-infers bounded context from file paths using configurable rules. - **Pipeline Factory**: Invariant: `buildMasterDataset()` is the shared factory for Steps 1-8 of the architecture pipeline and returns... - **Codec Base Options**: Shared types, interfaces, and utilities for all document codecs. -- **ADR 006 Single Read Model Architecture**: The delivery-process package applies event sourcing to itself: git is the event store, annotated source files are... +- **ADR 006 Single Read Model Architecture**: The Architect package applies event sourcing to itself: git is the event store, annotated source files are... - **ADR 005 Codec Based Markdown Rendering**: The documentation generator needs to transform structured pattern data (MasterDataset) into markdown files. - **ADR 002 Gherkin Only Testing**: A package that generates documentation from `.feature` files had dual test approaches: 97 legacy `.test.ts` files... - **Validator Read Model Consolidation**: `validate-patterns.ts` is the only feature consumer that bypasses the MasterDataset. @@ -235,7 +235,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Docs Consolidation Strategy**: 14 manually-maintained docs (~5,400 lines in `docs/`) duplicate information that already exists in annotated source... - **Doc Generation Proof Of Concept**: Status: SUPERSEDED - This POC has been implemented. - **Declaration Level Shape Tagging**: The current shape extraction system operates at file granularity. -- **Data API Stub Integration**: Design sessions produce code stubs in `delivery-process/stubs/` with rich metadata: `@target` (destination file... +- **Data API Stub Integration**: Design sessions produce code stubs in `architect/stubs/` with rich metadata: `@target` (destination file... - **Data API Design Session Support**: Starting a design or implementation session requires manually compiling elaborate context prompts. - **Data API Platform Integration**: The process-api CLI requires subprocess invocation for every query, adding shell overhead and preventing stateful... - **Data API Output Shaping**: The ProcessStateAPI CLI returns raw `ExtractedPattern` objects via `JSON.stringify`. @@ -243,7 +243,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Data API CLI Ergonomics**: The process-api CLI runs the full pipeline (scan, extract, transform) on every invocation, taking 2-5 seconds. - **Data API Architecture Queries**: The current `arch` subcommand provides basic queries (roles, context, layer, graph) but lacks deeper analysis needed... - **Cross Cutting Document Inclusion**: The reference doc codec assembles content from four sources, each with its own selection mechanism: conventionTags... -- **Config Based Workflow Definition**: Every `pnpm process:query` and `pnpm docs:*` invocation prints: `Failed to load default workflow (6-phase-standard):... +- **Config Based Workflow Definition**: Every `pnpm architect:query` and `pnpm docs:*` invocation prints: `Failed to load default workflow (6-phase-standard):... - **Codec Driven Reference Generation**: Each reference document (Process Guard, Taxonomy, Validation, etc.) required a hand-coded recipe feature that... - **Cli Recipe Codec**: `docs/PROCESS-API.md` (~509 lines) retains ~460 lines of editorial prose after Phase 43 (ProcessApiHybridGeneration)... - **Claude Module Generation**: Problem: CLAUDE.md modules are hand-written markdown files that drift from source code over time. @@ -263,9 +263,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Gherkin Ast Parser**: The Gherkin AST parser extracts feature metadata, scenarios, and steps from .feature files for timeline generation... - **File Discovery**: The file discovery system uses glob patterns to find TypeScript files for documentation extraction. - **Doc String Media Type**: DocString language hints (mediaType) should be preserved through the parsing pipeline from feature files to rendered... -- **Ast Parser Relationships Edges**: The AST Parser extracts @libar-docs-\* directives from TypeScript source files using the TypeScript compiler API. -- **Ast Parser Metadata**: The AST Parser extracts @libar-docs-\* directives from TypeScript source files using the TypeScript compiler API. -- **Ast Parser Exports**: The AST Parser extracts @libar-docs-\* directives from TypeScript source files using the TypeScript compiler API. +- **Ast Parser Relationships Edges**: The AST Parser extracts @architect-\* directives from TypeScript source files using the TypeScript compiler API. +- **Ast Parser Metadata**: The AST Parser extracts @architect-\* directives from TypeScript source files using the TypeScript compiler API. +- **Ast Parser Exports**: The AST Parser extracts @architect-\* directives from TypeScript source files using the TypeScript compiler API. - **Rule Keyword Po C**: This feature tests whether vitest-cucumber supports the Rule keyword for organizing scenarios under business rules. - **Lint Rule Individual Testing**: Individual lint rules that check parsed directives for completeness. - **Lint Rule Advanced Testing**: Complex lint rule logic and collection-level behavior. @@ -280,7 +280,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Shape Extraction Types Testing**: Validates the shape extraction system that extracts TypeScript type definitions (interfaces, type aliases, enums,... - **Shape Extraction Rendering Testing**: Validates the shape extraction system that extracts TypeScript type definitions (interfaces, type aliases, enums,... - **Extraction Pipeline Enhancements Testing**: Validates extraction pipeline capabilities for ReferenceDocShowcase: function signature surfacing, full... -- **Dual Source Extractor Testing**: Extracts and combines pattern metadata from both TypeScript code stubs (@libar-docs-) and Gherkin feature files... +- **Dual Source Extractor Testing**: Extracts and combines pattern metadata from both TypeScript code stubs (@architect-) and Gherkin feature files... - **Declaration Level Shape Tagging Testing**: Tests the discoverTaggedShapes function that scans TypeScript source code for declarations annotated with the... - **Warning Collector Testing**: The warning collector provides a unified system for capturing, categorizing, and reporting non-fatal issues during... - **Validation Rules Codec Testing**: Validates the Validation Rules Codec that transforms MasterDataset into a RenderableDocument for Process Guard... @@ -295,10 +295,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Source Merging**: mergeSourcesForGenerator computes effective sources for a specific generator by applying per-generator overrides to... - **Project Config Loader**: loadProjectConfig loads and resolves configuration from file, supporting both new-style defineConfig and legacy... - **Preset System**: Presets provide pre-configured taxonomies for different project types. -- **Define Config Testing**: The defineConfig identity function and DeliveryProcessProjectConfigSchema provide type-safe configuration authoring... -- **Configuration API**: The createDeliveryProcess factory provides a type-safe way to configure the delivery process with custom tag prefixes... -- **Config Resolution**: resolveProjectConfig transforms a raw DeliveryProcessProjectConfig into a fully resolved ResolvedConfig with all... -- **Config Loader Testing**: The config loader discovers and loads `delivery-process.config.ts` files for hierarchical configuration, enabling... +- **Define Config Testing**: The defineConfig identity function and ArchitectProjectConfigSchema provide type-safe configuration authoring... +- **Configuration API**: The createArchitect factory provides a type-safe way to configure the delivery process with custom tag prefixes... +- **Config Resolution**: resolveProjectConfig transforms a raw ArchitectProjectConfig into a fully resolved ResolvedConfig with all... +- **Config Loader Testing**: The config loader discovers and loads `architect.config.ts` files for hierarchical configuration, enabling... - **Process State API Testing**: Programmatic interface for querying delivery process state. - **Validate Patterns Cli**: Command-line interface for cross-validating TypeScript patterns vs Gherkin feature files. - **Process Api Cli Subcommands**: Discovery subcommands: list, search, context assembly, tags/sources, extended arch, unannotated. @@ -325,7 +325,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Implementation Link Path Normalization**: Links to implementation files in generated pattern documents should have correct relative paths. - **Extract Summary**: The extractSummary function transforms multi-line pattern descriptions into concise, single-line summaries suitable... - **Error Handling Unification**: All CLI commands and extractors should use the DocError discriminated union pattern for consistent, structured error... -- **Directive Detection**: Pure functions that detect @libar-docs directives in TypeScript source code. +- **Directive Detection**: Pure functions that detect @architect directives in TypeScript source code. - **Description Quality Foundation**: Enhanced documentation generation with human-readable names, behavior file verification, and numbered acceptance... - **Description Header Normalization**: Pattern descriptions should not create duplicate headers when rendered. - **Context Inference**: Patterns in standard directories (src/validation/, src/scanner/) should automatically receive architecture context... @@ -334,8 +334,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Handoff Generator Tests**: Multi-session work loses critical state between sessions when handoff documentation is manual or forgotten. - **Mermaid Relationship Rendering**: Tests for rendering all relationship types in Mermaid dependency graphs with distinct visual styles per relationship... - **Linter Validation Testing**: Tests for lint rules that validate relationship integrity, detect conflicts, and ensure bidirectional traceability... -- **Implements Tag Processing**: Tests for the @libar-docs-implements tag which links implementation files to their corresponding roadmap pattern... -- **Extends Tag Testing**: Tests for the @libar-docs-extends tag which establishes generalization relationships between patterns (pattern... +- **Implements Tag Processing**: Tests for the @architect-implements tag which links implementation files to their corresponding roadmap pattern... +- **Extends Tag Testing**: Tests for the @architect-extends tag which establishes generalization relationships between patterns (pattern... - **Process Api Reference Tests**: Verifies that the declarative CLI schema drives reference table generation and stays in sync with the parser... - **Layered Diagram Generation**: As a documentation generator I want to generate layered architecture diagrams from metadata So that system... - **Arch Generator Registration**: As a CLI user I want an architecture generator registered in the generator registry So that I can run pnpm... @@ -358,7 +358,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). - **Planning Codec Testing**: The planning codecs (PlanningChecklistCodec, SessionPlanCodec, SessionFindingsCodec) transform MasterDataset into... - **Generated Doc Quality Tests**: Tests for the four quality fixes in GeneratedDocQuality (Phase 38): duplicate table removal, Generation compact... - **Dedent Helper**: The dedent helper function normalizes indentation in code blocks extracted from DocStrings. -- **Convention Extractor Testing**: Extracts convention content from MasterDataset decision records tagged with @libar-docs-convention. +- **Convention Extractor Testing**: Extracts convention content from MasterDataset decision records tagged with @architect-convention. - **Composite Codec Testing**: Assembles reference documents from multiple codec outputs by concatenating RenderableDocument sections. --- diff --git a/docs-live/INDEX.md b/docs-live/INDEX.md index de1c65de..d09da165 100644 --- a/docs-live/INDEX.md +++ b/docs-live/INDEX.md @@ -1,6 +1,6 @@ # Documentation Index -**Purpose:** Navigate the full documentation set for @libar-dev/delivery-process. Use section links for targeted reading. +**Purpose:** Navigate the full documentation set for @libar-dev/architect. Use section links for targeted reading. --- @@ -8,7 +8,7 @@ | Field | Value | | ----------------- | ----------------------------------------------------- | -| **Package** | @libar-dev/delivery-process | +| **Package** | @libar-dev/architect | | **Purpose** | Code-first documentation and delivery process toolkit | | **Patterns** | 386 tracked (258 completed, 74 active, 54 planned) | | **Product Areas** | 7 | diff --git a/docs-live/PRODUCT-AREAS.md b/docs-live/PRODUCT-AREAS.md index a27ebd37..6c592588 100644 --- a/docs-live/PRODUCT-AREAS.md +++ b/docs-live/PRODUCT-AREAS.md @@ -19,11 +19,11 @@ The annotation system is the ingestion boundary — it transforms annotated Type > **How do I configure the tool?** -Configuration is the entry boundary — it transforms a user-authored `delivery-process.config.ts` file into a fully resolved `DeliveryProcessInstance` that powers the entire pipeline. The flow is: `defineConfig()` provides type-safe authoring (Vite convention, zero validation), `ConfigLoader` discovers and loads the file, `ProjectConfigSchema` validates via Zod, `ConfigResolver` applies defaults and merges stubs into sources, and `DeliveryProcessFactory` builds the final instance with `TagRegistry` and `RegexBuilders`. Three presets define escalating taxonomy complexity — from 3 categories (`generic`, `libar-generic`) to 21 (`ddd-es-cqrs`). `SourceMerger` computes per-generator source overrides, enabling generators like changelog to pull from different feature sets than the base config. +Configuration is the entry boundary — it transforms a user-authored `architect.config.ts` file into a fully resolved `ArchitectInstance` that powers the entire pipeline. The flow is: `defineConfig()` provides type-safe authoring (Vite convention, zero validation), `ConfigLoader` discovers and loads the file, `ProjectConfigSchema` validates via Zod, `ConfigResolver` applies defaults and merges stubs into sources, and `ArchitectFactory` builds the final instance with `TagRegistry` and `RegexBuilders`. Three presets define escalating taxonomy complexity — from 3 categories (`generic`, `libar-generic`) to 21 (`ddd-es-cqrs`). `SourceMerger` computes per-generator source overrides, enabling generators like changelog to pull from different feature sets than the base config. **11 patterns** — 8 completed, 0 active, 3 planned -**Key patterns:** DeliveryProcessFactory, ConfigLoader, ConfigResolver, DefineConfig, ConfigurationPresets, SourceMerger +**Key patterns:** ArchitectFactory, ConfigLoader, ConfigResolver, DefineConfig, ConfigurationPresets, SourceMerger ## [Generation](product-areas/GENERATION.md) @@ -39,7 +39,7 @@ The generation pipeline transforms annotated source code into markdown documents > **How is the workflow enforced?** -Validation is the enforcement boundary — it ensures that every change to annotated source files respects the delivery lifecycle rules defined by the FSM, protection levels, and scope constraints. The system operates in three layers: the FSM validator checks status transitions against a 4-state directed graph, the Process Guard orchestrates commit-time validation using a Decider pattern (state derived from annotations, not stored separately), and the lint engine provides pluggable rule execution with pretty and JSON output. Anti-pattern detection enforces dual-source ownership boundaries — `@libar-docs-uses` belongs on TypeScript, `@libar-docs-depends-on` belongs on Gherkin — preventing cross-domain tag confusion that causes documentation drift. Definition of Done validation ensures completed patterns have all deliverables marked done and at least one acceptance-criteria scenario. +Validation is the enforcement boundary — it ensures that every change to annotated source files respects the delivery lifecycle rules defined by the FSM, protection levels, and scope constraints. The system operates in three layers: the FSM validator checks status transitions against a 4-state directed graph, the Process Guard orchestrates commit-time validation using a Decider pattern (state derived from annotations, not stored separately), and the lint engine provides pluggable rule execution with pretty and JSON output. Anti-pattern detection enforces dual-source ownership boundaries — `@architect-uses` belongs on TypeScript, `@architect-depends-on` belongs on Gherkin — preventing cross-domain tag confusion that causes documentation drift. Definition of Done validation ensures completed patterns have all deliverables marked done and at least one acceptance-criteria scenario. **25 patterns** — 16 completed, 3 active, 6 planned @@ -103,7 +103,7 @@ C4Context System(ConfigResolver, "ConfigResolver") System(ConfigurationPresets, "ConfigurationPresets") System(SourceMerger, "SourceMerger") - System(DeliveryProcessFactory, "DeliveryProcessFactory") + System(ArchitectFactory, "ArchitectFactory") System(DefineConfig, "DefineConfig") System(ConfigLoader, "ConfigLoader") } @@ -134,15 +134,15 @@ C4Context System_Ext(DocGenerationProofOfConcept, "DocGenerationProofOfConcept") System_Ext(DataAPIStubIntegration, "DataAPIStubIntegration") Rel(ConfigResolver, ProjectConfigTypes, "uses") - Rel(ConfigResolver, DeliveryProcessFactory, "uses") + Rel(ConfigResolver, ArchitectFactory, "uses") Rel(ConfigResolver, ConfigurationDefaults, "uses") Rel(ConfigurationPresets, ConfigurationTypes, "uses") Rel(SourceMerger, ProjectConfigTypes, "uses") - Rel(DeliveryProcessFactory, ConfigurationTypes, "uses") - Rel(DeliveryProcessFactory, ConfigurationPresets, "uses") - Rel(DeliveryProcessFactory, RegexBuilders, "uses") + Rel(ArchitectFactory, ConfigurationTypes, "uses") + Rel(ArchitectFactory, ConfigurationPresets, "uses") + Rel(ArchitectFactory, RegexBuilders, "uses") Rel(DefineConfig, ProjectConfigTypes, "uses") - Rel(ConfigLoader, DeliveryProcessFactory, "uses") + Rel(ConfigLoader, ArchitectFactory, "uses") Rel(ConfigLoader, ConfigurationTypes, "uses") Rel(CompositeCodec, ReferenceDocShowcase, "implements") Rel(ADR003SourceFirstPatternArchitecture, ADR001TaxonomyCanonicalValues, "depends on") @@ -182,7 +182,7 @@ graph LR ConfigResolver("ConfigResolver") ConfigurationPresets["ConfigurationPresets"] SourceMerger("SourceMerger") - DeliveryProcessFactory("DeliveryProcessFactory") + ArchitectFactory("ArchitectFactory") DefineConfig[/"DefineConfig"/] ConfigLoader[/"ConfigLoader"/] end @@ -215,15 +215,15 @@ graph LR DataAPIStubIntegration["DataAPIStubIntegration"]:::neighbor end ConfigResolver -->|uses| ProjectConfigTypes - ConfigResolver -->|uses| DeliveryProcessFactory + ConfigResolver -->|uses| ArchitectFactory ConfigResolver -->|uses| ConfigurationDefaults ConfigurationPresets -->|uses| ConfigurationTypes SourceMerger -->|uses| ProjectConfigTypes - DeliveryProcessFactory -->|uses| ConfigurationTypes - DeliveryProcessFactory -->|uses| ConfigurationPresets - DeliveryProcessFactory -->|uses| RegexBuilders + ArchitectFactory -->|uses| ConfigurationTypes + ArchitectFactory -->|uses| ConfigurationPresets + ArchitectFactory -->|uses| RegexBuilders DefineConfig -->|uses| ProjectConfigTypes - ConfigLoader -->|uses| DeliveryProcessFactory + ConfigLoader -->|uses| ArchitectFactory ConfigLoader -->|uses| ConfigurationTypes CompositeCodec ..->|implements| ReferenceDocShowcase ADR003SourceFirstPatternArchitecture -.->|depends on| ADR001TaxonomyCanonicalValues diff --git a/docs-live/TAXONOMY.md b/docs-live/TAXONOMY.md index 8564b12e..d12ca163 100644 --- a/docs-live/TAXONOMY.md +++ b/docs-live/TAXONOMY.md @@ -9,7 +9,7 @@ **3 categories** | **60 metadata tags** | **3 aggregation tags** -Current configuration uses `@libar-docs-` prefix with `@libar-docs` file opt-in. +Current configuration uses `@architect-` prefix with `@architect` file opt-in. | Component | Count | Description | | ---------------- | ----- | ------------------------------------ | @@ -39,93 +39,93 @@ Tags for enriching patterns with additional metadata. ### Core Tags -| Tag | Format | Purpose | Required | Example | -| --------- | ------------ | -------------------------------------------- | -------- | ------------------------------------------------------ | -| `pattern` | value | Explicit pattern name | Yes | `@libar-docs-pattern CommandOrchestrator` | -| `status` | enum | Work item lifecycle status (per PDR-005 FSM) | No | `@libar-docs-status roadmap` | -| `core` | flag | Marks as essential/must-know pattern | No | `@libar-docs-core` | -| `usecase` | quoted-value | Use case association | No | `@libar-docs-usecase "When handling command failures"` | +| Tag | Format | Purpose | Required | Example | +| --------- | ------------ | -------------------------------------------- | -------- | ----------------------------------------------------- | +| `pattern` | value | Explicit pattern name | Yes | `@architect-pattern CommandOrchestrator` | +| `status` | enum | Work item lifecycle status (per PDR-005 FSM) | No | `@architect-status roadmap` | +| `core` | flag | Marks as essential/must-know pattern | No | `@architect-core` | +| `usecase` | quoted-value | Use case association | No | `@architect-usecase "When handling command failures"` | ### Relationship Tags -| Tag | Format | Purpose | Required | Example | -| ------------ | ------ | -------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------- | -| `uses` | csv | Patterns this depends on | No | `@libar-docs-uses CommandBus, EventStore` | -| `used-by` | csv | Patterns that depend on this | No | `@libar-docs-used-by SagaOrchestrator` | -| `depends-on` | csv | Roadmap dependencies (pattern or phase names) | No | `@libar-docs-depends-on EventStore, CommandBus` | -| `enables` | csv | Patterns this enables | No | `@libar-docs-enables SagaOrchestrator, ProjectionBuilder` | -| `implements` | csv | Patterns this code file realizes (realization relationship) | No | `@libar-docs-implements EventStoreDurability, IdempotentAppend` | -| `extends` | value | Base pattern this pattern extends (generalization relationship) | No | `@libar-docs-extends ProjectionCategories` | -| `see-also` | csv | Related patterns for cross-reference without dependency implication | No | `@libar-docs-see-also AgentAsBoundedContext, CrossContextIntegration` | -| `api-ref` | csv | File paths to implementation APIs (replaces 'See:' Markdown text in Rules) | No | `@libar-docs-api-ref @libar-dev/platform-core/src/durability/outbox.ts` | +| Tag | Format | Purpose | Required | Example | +| ------------ | ------ | -------------------------------------------------------------------------- | -------- | ---------------------------------------------------------------------- | +| `uses` | csv | Patterns this depends on | No | `@architect-uses CommandBus, EventStore` | +| `used-by` | csv | Patterns that depend on this | No | `@architect-used-by SagaOrchestrator` | +| `depends-on` | csv | Roadmap dependencies (pattern or phase names) | No | `@architect-depends-on EventStore, CommandBus` | +| `enables` | csv | Patterns this enables | No | `@architect-enables SagaOrchestrator, ProjectionBuilder` | +| `implements` | csv | Patterns this code file realizes (realization relationship) | No | `@architect-implements EventStoreDurability, IdempotentAppend` | +| `extends` | value | Base pattern this pattern extends (generalization relationship) | No | `@architect-extends ProjectionCategories` | +| `see-also` | csv | Related patterns for cross-reference without dependency implication | No | `@architect-see-also AgentAsBoundedContext, CrossContextIntegration` | +| `api-ref` | csv | File paths to implementation APIs (replaces 'See:' Markdown text in Rules) | No | `@architect-api-ref @libar-dev/platform-core/src/durability/outbox.ts` | ### Timeline Tags -| Tag | Format | Purpose | Required | Example | -| --------------- | ------ | ------------------------------------------------------------ | -------- | ------------------------------------- | -| `phase` | number | Roadmap phase number (unified across monorepo) | No | `@libar-docs-phase 14` | -| `release` | value | Target release version (semver or vNEXT for unreleased work) | No | `@libar-docs-release v0.1.0` | -| `quarter` | value | Delivery quarter for timeline tracking | No | `@libar-docs-quarter Q1-2026` | -| `completed` | value | Completion date (YYYY-MM-DD format) | No | `@libar-docs-completed 2026-01-08` | -| `effort` | value | Estimated effort (4h, 2d, 1w format) | No | `@libar-docs-effort 2d` | -| `effort-actual` | value | Actual effort spent (4h, 2d, 1w format) | No | `@libar-docs-effort-actual 3d` | -| `team` | value | Responsible team assignment | No | `@libar-docs-team platform` | -| `workflow` | enum | Workflow discipline for process tracking | No | `@libar-docs-workflow implementation` | -| `risk` | enum | Risk level for planning | No | `@libar-docs-risk medium` | -| `priority` | enum | Priority level for roadmap ordering | No | `@libar-docs-priority high` | +| Tag | Format | Purpose | Required | Example | +| --------------- | ------ | ------------------------------------------------------------ | -------- | ------------------------------------ | +| `phase` | number | Roadmap phase number (unified across monorepo) | No | `@architect-phase 14` | +| `release` | value | Target release version (semver or vNEXT for unreleased work) | No | `@architect-release v0.1.0` | +| `quarter` | value | Delivery quarter for timeline tracking | No | `@architect-quarter Q1-2026` | +| `completed` | value | Completion date (YYYY-MM-DD format) | No | `@architect-completed 2026-01-08` | +| `effort` | value | Estimated effort (4h, 2d, 1w format) | No | `@architect-effort 2d` | +| `effort-actual` | value | Actual effort spent (4h, 2d, 1w format) | No | `@architect-effort-actual 3d` | +| `team` | value | Responsible team assignment | No | `@architect-team platform` | +| `workflow` | enum | Workflow discipline for process tracking | No | `@architect-workflow implementation` | +| `risk` | enum | Risk level for planning | No | `@architect-risk medium` | +| `priority` | enum | Priority level for roadmap ordering | No | `@architect-priority high` | ### ADR Tags -| Tag | Format | Purpose | Required | Example | -| ------------------- | ------ | ----------------------------------------------------- | -------- | --------------------------------------- | -| `adr` | value | ADR/PDR number for decision tracking | No | `@libar-docs-adr 015` | -| `adr-status` | enum | ADR/PDR decision status | No | `@libar-docs-adr-status accepted` | -| `adr-category` | value | ADR/PDR category (architecture, process, tooling) | No | `@libar-docs-adr-category architecture` | -| `adr-supersedes` | value | ADR/PDR number this decision supersedes | No | `@libar-docs-adr-supersedes 012` | -| `adr-superseded-by` | value | ADR/PDR number that supersedes this decision | No | `@libar-docs-adr-superseded-by 020` | -| `adr-theme` | enum | Theme grouping for related decisions (from synthesis) | No | `@libar-docs-adr-theme persistence` | -| `adr-layer` | enum | Evolutionary layer of the decision | No | `@libar-docs-adr-layer foundation` | +| Tag | Format | Purpose | Required | Example | +| ------------------- | ------ | ----------------------------------------------------- | -------- | -------------------------------------- | +| `adr` | value | ADR/PDR number for decision tracking | No | `@architect-adr 015` | +| `adr-status` | enum | ADR/PDR decision status | No | `@architect-adr-status accepted` | +| `adr-category` | value | ADR/PDR category (architecture, process, tooling) | No | `@architect-adr-category architecture` | +| `adr-supersedes` | value | ADR/PDR number this decision supersedes | No | `@architect-adr-supersedes 012` | +| `adr-superseded-by` | value | ADR/PDR number that supersedes this decision | No | `@architect-adr-superseded-by 020` | +| `adr-theme` | enum | Theme grouping for related decisions (from synthesis) | No | `@architect-adr-theme persistence` | +| `adr-layer` | enum | Evolutionary layer of the decision | No | `@architect-adr-layer foundation` | ### Architecture Tags -| Tag | Format | Purpose | Required | Example | -| -------------- | ------ | ----------------------------------------------------------------- | -------- | ------------------------------------ | -| `arch-role` | enum | Architectural role for diagram generation (component type) | No | `@libar-docs-arch-role projection` | -| `arch-context` | value | Bounded context this component belongs to (for subgraph grouping) | No | `@libar-docs-arch-context orders` | -| `arch-layer` | enum | Architectural layer for layered diagrams | No | `@libar-docs-arch-layer application` | +| Tag | Format | Purpose | Required | Example | +| -------------- | ------ | ----------------------------------------------------------------- | -------- | ----------------------------------- | +| `arch-role` | enum | Architectural role for diagram generation (component type) | No | `@architect-arch-role projection` | +| `arch-context` | value | Bounded context this component belongs to (for subgraph grouping) | No | `@architect-arch-context orders` | +| `arch-layer` | enum | Architectural layer for layered diagrams | No | `@architect-arch-layer application` | ### Other Tags -| Tag | Format | Purpose | Required | Example | -| ------------------------ | ------------ | -------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------- | -| `brief` | value | Path to pattern brief markdown | No | `@libar-docs-brief docs/briefs/decider-pattern.md` | -| `product-area` | value | Product area for PRD grouping | No | `@libar-docs-product-area PlatformCore` | -| `user-role` | value | Target user persona for this feature | No | `@libar-docs-user-role Developer` | -| `business-value` | value | Business value statement (hyphenated for tag format) | No | `@libar-docs-business-value eliminates-event-replay-complexity` | -| `constraint` | value | Technical constraint affecting feature implementation | No | `@libar-docs-constraint requires-convex-backend` | -| `level` | enum | Hierarchy level for epic->phase->task breakdown | No | `@libar-docs-level epic` | -| `parent` | value | Parent pattern name in hierarchy (links tasks to phases, phases to epics) | No | `@libar-docs-parent AggregateArchitecture` | -| `title` | quoted-value | Human-readable display title (supports quoted values with spaces) | No | `@libar-docs-title:"Process Guard Linter"` | -| `executable-specs` | csv | Links roadmap spec to package executable spec locations (PDR-007) | No | `@libar-docs-executable-specs platform-decider/tests/features/behavior` | -| `roadmap-spec` | value | Links package spec back to roadmap pattern for traceability (PDR-007) | No | `@libar-docs-roadmap-spec DeciderPattern` | -| `behavior-file` | value | Path to behavior test feature file for traceability | No | `@libar-docs-behavior-file behavior/my-pattern.feature` | -| `discovered-gap` | value | Gap identified during session retrospective | No | `@libar-docs-discovered-gap missing-error-handling` | -| `discovered-improvement` | value | Improvement identified during session retrospective | No | `@libar-docs-discovered-improvement cache-invalidation` | -| `discovered-risk` | value | Risk identified during session retrospective | No | `@libar-docs-discovered-risk data-loss-on-migration` | -| `discovered-learning` | value | Learning captured during session retrospective | No | `@libar-docs-discovered-learning convex-mutation-limits` | -| `extract-shapes` | csv | TypeScript type names to extract from this file for documentation | No | `@libar-docs-extract-shapes DeciderInput, ValidationResult, ProcessViolation` | -| `shape` | value | Marks declaration as documentable shape, optionally with group name | No | `@libar-docs-shape api-types` | -| `include` | csv | Cross-cutting document inclusion for content routing and diagram scoping | No | `@libar-docs-include reference-sample,codec-system` | -| `target` | value | Target implementation path for stub files | No | `@libar-docs-target src/api/stub-resolver.ts` | -| `since` | value | Design session that created this pattern | No | `@libar-docs-since DS-A` | -| `convention` | csv | Convention domains for reference document generation from decision records | No | `@libar-docs-convention fsm-rules, testing-policy` | -| `claude-module` | value | Module identifier for CLAUDE.md module generation (becomes filename) | No | `@libar-docs-claude-module process-guard` | -| `claude-section` | enum | Target section directory in \_claude-md/ for module output | No | `@libar-docs-claude-section delivery-process` | -| `claude-tags` | csv | Variation filtering tags for modular-claude-md inclusion | No | `@libar-docs-claude-tags core-mandatory, delivery-process` | -| `sequence-orchestrator` | value | Identifies the coordinator module for sequence diagram generation | No | `@libar-docs-sequence-orchestrator:init-cli` | -| `sequence-step` | number | Explicit execution ordering number for sequence diagram steps | No | `@libar-docs-sequence-step:1` | -| `sequence-module` | csv | Maps Rule to deliverable module(s) for sequence diagram participants | No | `@libar-docs-sequence-module:detect-context` | -| `sequence-error` | flag | Marks scenario as error/alternative path in sequence diagram | No | `@libar-docs-sequence-error` | +| Tag | Format | Purpose | Required | Example | +| ------------------------ | ------------ | -------------------------------------------------------------------------- | -------- | ---------------------------------------------------------------------------- | +| `brief` | value | Path to pattern brief markdown | No | `@architect-brief docs/briefs/decider-pattern.md` | +| `product-area` | value | Product area for PRD grouping | No | `@architect-product-area PlatformCore` | +| `user-role` | value | Target user persona for this feature | No | `@architect-user-role Developer` | +| `business-value` | value | Business value statement (hyphenated for tag format) | No | `@architect-business-value eliminates-event-replay-complexity` | +| `constraint` | value | Technical constraint affecting feature implementation | No | `@architect-constraint requires-convex-backend` | +| `level` | enum | Hierarchy level for epic->phase->task breakdown | No | `@architect-level epic` | +| `parent` | value | Parent pattern name in hierarchy (links tasks to phases, phases to epics) | No | `@architect-parent AggregateArchitecture` | +| `title` | quoted-value | Human-readable display title (supports quoted values with spaces) | No | `@architect-title:"Process Guard Linter"` | +| `executable-specs` | csv | Links roadmap spec to package executable spec locations (PDR-007) | No | `@architect-executable-specs platform-decider/tests/features/behavior` | +| `roadmap-spec` | value | Links package spec back to roadmap pattern for traceability (PDR-007) | No | `@architect-roadmap-spec DeciderPattern` | +| `behavior-file` | value | Path to behavior test feature file for traceability | No | `@architect-behavior-file behavior/my-pattern.feature` | +| `discovered-gap` | value | Gap identified during session retrospective | No | `@architect-discovered-gap missing-error-handling` | +| `discovered-improvement` | value | Improvement identified during session retrospective | No | `@architect-discovered-improvement cache-invalidation` | +| `discovered-risk` | value | Risk identified during session retrospective | No | `@architect-discovered-risk data-loss-on-migration` | +| `discovered-learning` | value | Learning captured during session retrospective | No | `@architect-discovered-learning convex-mutation-limits` | +| `extract-shapes` | csv | TypeScript type names to extract from this file for documentation | No | `@architect-extract-shapes DeciderInput, ValidationResult, ProcessViolation` | +| `shape` | value | Marks declaration as documentable shape, optionally with group name | No | `@architect-shape api-types` | +| `include` | csv | Cross-cutting document inclusion for content routing and diagram scoping | No | `@architect-include reference-sample,codec-system` | +| `target` | value | Target implementation path for stub files | No | `@architect-target src/api/stub-resolver.ts` | +| `since` | value | Design session that created this pattern | No | `@architect-since DS-A` | +| `convention` | csv | Convention domains for reference document generation from decision records | No | `@architect-convention fsm-rules, testing-policy` | +| `claude-module` | value | Module identifier for CLAUDE.md module generation (becomes filename) | No | `@architect-claude-module process-guard` | +| `claude-section` | enum | Target section directory in \_claude-md/ for module output | No | `@architect-claude-section delivery-process` | +| `claude-tags` | csv | Variation filtering tags for modular-claude-md inclusion | No | `@architect-claude-tags core-mandatory, delivery-process` | +| `sequence-orchestrator` | value | Identifies the coordinator module for sequence diagram generation | No | `@architect-sequence-orchestrator:init-cli` | +| `sequence-step` | number | Explicit execution ordering number for sequence diagram steps | No | `@architect-sequence-step:1` | +| `sequence-module` | csv | Maps Rule to deliverable module(s) for sequence diagram participants | No | `@architect-sequence-module:detect-context` | +| `sequence-error` | flag | Marks scenario as error/alternative path in sequence diagram | No | `@architect-sequence-error` | [Full metadata tag reference](taxonomy/metadata-tags.md) @@ -147,14 +147,14 @@ Tags that route patterns to specific aggregated documents. How tag values are parsed and validated. -| Format | Description | Example | -| -------------- | ----------------------------------- | -------------------------------------- | -| `value` | Simple string value | `@libar-docs-pattern MyPattern` | -| `enum` | Constrained to predefined values | `@libar-docs-status roadmap` | -| `quoted-value` | String in quotes (preserves spaces) | `@libar-docs-usecase "When X happens"` | -| `csv` | Comma-separated values | `@libar-docs-uses A, B, C` | -| `number` | Numeric value | `@libar-docs-phase 14` | -| `flag` | Boolean presence (no value) | `@libar-docs-core` | +| Format | Description | Example | +| -------------- | ----------------------------------- | ------------------------------------- | +| `value` | Simple string value | `@architect-pattern MyPattern` | +| `enum` | Constrained to predefined values | `@architect-status roadmap` | +| `quoted-value` | String in quotes (preserves spaces) | `@architect-usecase "When X happens"` | +| `csv` | Comma-separated values | `@architect-uses A, B, C` | +| `number` | Numeric value | `@architect-phase 14` | +| `flag` | Boolean presence (no value) | `@architect-core` | [Format type details](taxonomy/format-types.md) @@ -164,11 +164,11 @@ How tag values are parsed and validated. Available configuration presets. -| Preset | Tag Prefix | Categories | Use Case | -| --------------- | -------------- | ---------- | --------------------------------------- | -| `generic` | `@docs-` | 3 | Simple projects with @docs- prefix | -| `libar-generic` | `@libar-docs-` | 3 | Default preset with @libar-docs- prefix | -| `ddd-es-cqrs` | `@libar-docs-` | 21 | Full DDD/ES/CQRS taxonomy | +| Preset | Tag Prefix | Categories | Use Case | +| --------------- | ------------- | ---------- | -------------------------------------- | +| `generic` | `@docs-` | 3 | Simple projects with @docs- prefix | +| `libar-generic` | `@architect-` | 3 | Default preset with @architect- prefix | +| `ddd-es-cqrs` | `@architect-` | 21 | Full DDD/ES/CQRS taxonomy | --- diff --git a/docs-live/VALIDATION-RULES.md b/docs-live/VALIDATION-RULES.md index ed2a67fc..4b082141 100644 --- a/docs-live/VALIDATION-RULES.md +++ b/docs-live/VALIDATION-RULES.md @@ -74,16 +74,16 @@ Protection levels determine what modifications are allowed per status. ```bash # Pre-commit (default mode) -lint-process --staged +architect-guard --staged # CI pipeline with strict mode -lint-process --all --strict +architect-guard --all --strict # Override session scope checking -lint-process --staged --ignore-session +architect-guard --staged --ignore-session # Debug: show derived process state -lint-process --staged --show-state +architect-guard --staged --show-state ``` ### Options @@ -110,10 +110,10 @@ lint-process --staged --show-state Override mechanisms for exceptional situations. -| Situation | Solution | Example | -| ---------------------------- | --------------------- | ---------------------------------------- | -| Fix bug in completed spec | Add unlock reason tag | `@libar-docs-unlock-reason:'Fix-typo'` | -| Modify outside session scope | Use ignore flag | `lint-process --staged --ignore-session` | -| CI treats warnings as errors | Use strict flag | `lint-process --all --strict` | +| Situation | Solution | Example | +| ---------------------------- | --------------------- | ------------------------------------------- | +| Fix bug in completed spec | Add unlock reason tag | `@architect-unlock-reason:'Fix-typo'` | +| Modify outside session scope | Use ignore flag | `architect-guard --staged --ignore-session` | +| CI treats warnings as errors | Use strict flag | `architect-guard --all --strict` | --- diff --git a/docs-live/_claude-md/annotation/annotation-reference.md b/docs-live/_claude-md/annotation/annotation-reference.md index 511d25c1..c5a8b12a 100644 --- a/docs-live/_claude-md/annotation/annotation-reference.md +++ b/docs-live/_claude-md/annotation/annotation-reference.md @@ -2,7 +2,7 @@ #### Getting Started -Every file that participates in the annotation system must have a `@libar-docs` opt-in marker. Files without this marker are invisible to the scanner. +Every file that participates in the annotation system must have a `@architect` opt-in marker. Files without this marker are invisible to the scanner. ##### File-Level Opt-In @@ -10,10 +10,10 @@ Every file that participates in the annotation system must have a `@libar-docs` ```typescript /** - * @libar-docs - * @libar-docs-pattern MyPattern - * @libar-docs-status roadmap - * @libar-docs-uses EventStore, CommandBus + * @architect + * @architect-pattern MyPattern + * @architect-status roadmap + * @architect-uses EventStore, CommandBus * * ## My Pattern - Description */ @@ -22,10 +22,10 @@ Every file that participates in the annotation system must have a `@libar-docs` **Gherkin** -- file-level tags before `Feature:`: ```gherkin -@libar-docs -@libar-docs-pattern:MyPattern -@libar-docs-status:roadmap -@libar-docs-phase:14 +@architect +@architect-pattern:MyPattern +@architect-status:roadmap +@architect-phase:14 Feature: My Pattern **Problem:** @@ -34,11 +34,11 @@ Feature: My Pattern ##### Tag Prefix by Preset -| Preset | Prefix | Categories | Use Case | -| ------------------------- | -------------- | ---------- | ----------------------------- | -| `libar-generic` (default) | `@libar-docs-` | 3 | Simple projects | -| `ddd-es-cqrs` | `@libar-docs-` | 21 | DDD/Event Sourcing monorepos | -| `generic` | `@docs-` | 3 | Simple projects, short prefix | +| Preset | Prefix | Categories | Use Case | +| ------------------------- | ------------- | ---------- | ----------------------------- | +| `libar-generic` (default) | `@architect-` | 3 | Simple projects | +| `ddd-es-cqrs` | `@architect-` | 21 | DDD/Event Sourcing monorepos | +| `generic` | `@docs-` | 3 | Simple projects, short prefix | ##### Dual-Source Ownership @@ -57,8 +57,8 @@ List specific declaration names in the file-level JSDoc: ```typescript /** - * @libar-docs - * @libar-docs-extract-shapes MasterDatasetSchema, StatusGroupsSchema + * @architect + * @architect-extract-shapes MasterDatasetSchema, StatusGroupsSchema */ ``` @@ -68,8 +68,8 @@ Names appear in the generated output in the order listed. ```typescript /** - * @libar-docs - * @libar-docs-extract-shapes * + * @architect + * @architect-extract-shapes * */ ``` @@ -77,17 +77,17 @@ Wildcard must be the sole value -- `*, Foo` is invalid. ##### Mode 3: Declaration-Level Tagging -Tag individual declarations with `@libar-docs-shape`, optionally with a group name: +Tag individual declarations with `@architect-shape`, optionally with a group name: ```typescript -/** @libar-docs-shape api-types */ +/** @architect-shape api-types */ export interface CommandInput { readonly aggregateId: string; readonly payload: unknown; } ``` -The optional group name (`api-types`) enables filtering in diagram scopes and product area documents via `@libar-docs-include`. +The optional group name (`api-types`) enables filtering in diagram scopes and product area documents via `@architect-include`. #### Critical Gotcha: Zod Schemas @@ -104,10 +104,10 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern MasterDataset - * @libar-docs-status completed - * @libar-docs-extract-shapes MasterDatasetSchema, StatusGroupsSchema, PhaseGroupSchema + * @architect + * @architect-pattern MasterDataset + * @architect-status completed + * @architect-extract-shapes MasterDatasetSchema, StatusGroupsSchema, PhaseGroupSchema */ ``` @@ -115,10 +115,10 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern DocumentGenerator - * @libar-docs-status completed - * @libar-docs-extract-shapes DocumentGenerator, GeneratorContext, GeneratorOutput + * @architect + * @architect-pattern DocumentGenerator + * @architect-status completed + * @architect-extract-shapes DocumentGenerator, GeneratorContext, GeneratorOutput */ ``` @@ -126,23 +126,23 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern TransformDataset - * @libar-docs-status completed - * @libar-docs-arch-context generator - * @libar-docs-arch-layer application - * @libar-docs-extract-shapes transformToMasterDataset, RuntimeMasterDataset + * @architect + * @architect-pattern TransformDataset + * @architect-status completed + * @architect-arch-context generator + * @architect-arch-layer application + * @architect-extract-shapes transformToMasterDataset, RuntimeMasterDataset */ ``` ##### Gherkin Feature Files ```gherkin -@libar-docs -@libar-docs-pattern:ProcessGuardLinter -@libar-docs-status:roadmap -@libar-docs-phase:99 -@libar-docs-depends-on:StateMachine,ValidationRules +@architect +@architect-pattern:ProcessGuardLinter +@architect-status:roadmap +@architect-phase:99 +@architect-depends-on:StateMachine,ValidationRules Feature: Process Guard Linter Background: Deliverables @@ -187,16 +187,16 @@ Tags are organized into 12 functional groups. For the complete reference with al ```bash # Tag usage inventory (counts per tag and value) -pnpm process:query -- tags +pnpm architect:query -- tags -# Find files missing @libar-docs opt-in marker -pnpm process:query -- unannotated --path src/types +# Find files missing @architect opt-in marker +pnpm architect:query -- unannotated --path src/types # File inventory by type (TS, Gherkin, Stubs) -pnpm process:query -- sources +pnpm architect:query -- sources # Full pattern JSON including extractedShapes -pnpm process:query -- query getPattern MyPattern +pnpm architect:query -- query getPattern MyPattern # Generate complete tag reference npx generate-tag-taxonomy -o TAG_TAXONOMY.md -f @@ -204,11 +204,11 @@ npx generate-tag-taxonomy -o TAG_TAXONOMY.md -f #### Common Issues -| Symptom | Cause | Fix | -| ------------------------------- | ----------------------------------- | ------------------------------------------------ | -| Pattern not in scanner output | Missing `@libar-docs` opt-in marker | Add file-level `@libar-docs` JSDoc/tag | -| Shape shows `z.infer<>` wrapper | Extracted type alias, not schema | Use schema constant name (e.g., `FooSchema`) | -| Shape not in product area doc | Missing `@libar-docs-product-area` | Add product-area tag to file-level annotation | -| Declaration-level shape missing | No `@libar-docs-shape` on decl | Add `@libar-docs-shape` JSDoc to the declaration | -| Tag value rejected | Wrong format or invalid enum value | Check format type in taxonomy reference | -| Anti-pattern validation error | Tag on wrong source type | Move tag to correct source (TS vs Gherkin) | +| Symptom | Cause | Fix | +| ------------------------------- | ---------------------------------- | ----------------------------------------------- | +| Pattern not in scanner output | Missing `@architect` opt-in marker | Add file-level `@architect` JSDoc/tag | +| Shape shows `z.infer<>` wrapper | Extracted type alias, not schema | Use schema constant name (e.g., `FooSchema`) | +| Shape not in product area doc | Missing `@architect-product-area` | Add product-area tag to file-level annotation | +| Declaration-level shape missing | No `@architect-shape` on decl | Add `@architect-shape` JSDoc to the declaration | +| Tag value rejected | Wrong format or invalid enum value | Check format type in taxonomy reference | +| Anti-pattern validation error | Tag on wrong source type | Move tag to correct source (TS vs Gherkin) | diff --git a/docs-live/_claude-md/architecture/reference-sample.md b/docs-live/_claude-md/architecture/reference-sample.md index dfad372c..c74ad668 100644 --- a/docs-live/_claude-md/architecture/reference-sample.md +++ b/docs-live/_claude-md/architecture/reference-sample.md @@ -52,14 +52,14 @@ **Invariant:** Every tag has one of 6 format types that determines how its value is parsed. -| Format | Parsing | Example | -| ------------ | ------------------------------ | ------------------------------ | -| flag | Boolean presence, no value | @libar-docs-core | -| value | Simple string | @libar-docs-pattern MyPattern | -| enum | Constrained to predefined list | @libar-docs-status completed | -| csv | Comma-separated values | @libar-docs-uses A, B, C | -| number | Numeric value | @libar-docs-phase 15 | -| quoted-value | Preserves spaces | @libar-docs-brief:'Multi word' | +| Format | Parsing | Example | +| ------------ | ------------------------------ | ----------------------------- | +| flag | Boolean presence, no value | @architect-core | +| value | Simple string | @architect-pattern MyPattern | +| enum | Constrained to predefined list | @architect-status completed | +| csv | Comma-separated values | @architect-uses A, B, C | +| number | Numeric value | @architect-phase 15 | +| quoted-value | Preserves spaces | @architect-brief:'Multi word' | #### Source ownership @@ -113,7 +113,7 @@ #### Behavior Specifications -##### DeliveryProcessFactory +##### ArchitectFactory ##### DefineConfig @@ -154,7 +154,7 @@ | Rule | Description | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | -| Completed files require unlock-reason to modify | **Invariant:** A completed spec file cannot be modified unless it carries an @libar-docs-unlock-reason tag.... | +| Completed files require unlock-reason to modify | **Invariant:** A completed spec file cannot be modified unless it carries an @architect-unlock-reason tag.... | | Status transitions must follow PDR-005 FSM | **Invariant:** Status changes must follow the directed graph: roadmap->active->completed, roadmap<->deferred,... | | Active specs cannot add new deliverables | **Invariant:** A spec in active status cannot have deliverables added that were not present when it entered active.... | | Files outside active session scope trigger warnings | **Invariant:** Files modified outside the active session's declared scope produce a session-scope warning.... | diff --git a/docs-live/_claude-md/authoring/gherkin-authoring-guide.md b/docs-live/_claude-md/authoring/gherkin-authoring-guide.md index 762b1ed8..0691339f 100644 --- a/docs-live/_claude-md/authoring/gherkin-authoring-guide.md +++ b/docs-live/_claude-md/authoring/gherkin-authoring-guide.md @@ -7,10 +7,10 @@ Roadmap specs define planned work with Problem/Solution descriptions and a Background deliverables table. ```gherkin -@libar-docs -@libar-docs-pattern:ProcessGuardLinter -@libar-docs-status:roadmap -@libar-docs-phase:99 +@architect +@architect-pattern:ProcessGuardLinter +@architect-status:roadmap +@architect-phase:99 Feature: Process Guard Linter **Problem:** @@ -34,9 +34,9 @@ Feature: Process Guard Linter **Key elements:** -- `@libar-docs` -- bare opt-in marker (required) -- `@libar-docs-pattern:Name` -- unique identifier (required) -- `@libar-docs-status:roadmap` -- FSM state +- `@architect` -- bare opt-in marker (required) +- `@architect-pattern:Name` -- unique identifier (required) +- `@architect-status:roadmap` -- FSM state - `**Problem:**` / `**Solution:**` -- extracted by generators - Background deliverables table -- tracks implementation progress @@ -98,7 +98,7 @@ Test features focus on behavior verification with section dividers for organizat ```gherkin @behavior @scanner-core -@libar-docs-pattern:ScannerCore +@architect-pattern:ScannerCore Feature: Scanner Core Integration Background: @@ -149,11 +149,11 @@ Use `"""typescript` for code blocks. Essential when content contains pipes or sp Scenario: Extract directive from TypeScript Given a file with content: """typescript - /** @libar-docs */ + /** @architect */ export function authenticate() {} """ When scanning the file - Then directive should have tag "@libar-docs-core" + Then directive should have tag "@architect-core" ``` #### Tag Conventions @@ -195,7 +195,7 @@ Feature files serve dual purposes: **executable specs** and **documentation sour | DocStrings (`"""typescript`) | Brief examples (5-10 lines), current/target state comparison | | Code stub reference | Complex APIs, interfaces, full implementations | -Code stubs are annotated TypeScript files with `throw new Error("not yet implemented")`, located in `delivery-process/stubs/{pattern-name}/`. +Code stubs are annotated TypeScript files with `throw new Error("not yet implemented")`, located in `architect/stubs/{pattern-name}/`. ##### Valid Rich Content @@ -223,15 +223,15 @@ Code stubs are annotated TypeScript files with `throw new Error("not yet impleme **Tag values cannot contain spaces.** Use hyphens: -| Invalid | Valid | -| -------------------------------- | ------------------------------- | -| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | -| `@libar-docs-pattern:My Pattern` | `@libar-docs-pattern:MyPattern` | +| Invalid | Valid | +| ------------------------------- | ------------------------------ | +| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | +| `@architect-pattern:My Pattern` | `@architect-pattern:MyPattern` | For values with spaces, use the `quoted-value` format where supported: ```gherkin -@libar-docs-usecase "When handling command failures" +@architect-usecase "When handling command failures" ``` #### Quick Reference diff --git a/docs-live/_claude-md/configuration/configuration-guide.md b/docs-live/_claude-md/configuration/configuration-guide.md index 7774bae1..7eb31280 100644 --- a/docs-live/_claude-md/configuration/configuration-guide.md +++ b/docs-live/_claude-md/configuration/configuration-guide.md @@ -2,15 +2,15 @@ #### Quick Reference -| Preset | Tag Prefix | Categories | Use Case | -| ----------------------------- | -------------- | ---------- | ------------------------------------ | -| **`libar-generic`** (default) | `@libar-docs-` | 3 | Simple projects (this package) | -| `generic` | `@docs-` | 3 | Simple projects with `@docs-` prefix | -| `ddd-es-cqrs` | `@libar-docs-` | 21 | DDD/Event Sourcing architectures | +| Preset | Tag Prefix | Categories | Use Case | +| ----------------------------- | ------------- | ---------- | ------------------------------------ | +| **`libar-generic`** (default) | `@architect-` | 3 | Simple projects (this package) | +| `generic` | `@docs-` | 3 | Simple projects with `@docs-` prefix | +| `ddd-es-cqrs` | `@architect-` | 21 | DDD/Event Sourcing architectures | ```typescript -// delivery-process.config.ts -import { defineConfig } from '@libar-dev/delivery-process/config'; +// architect.config.ts +import { defineConfig } from '@libar-dev/architect/config'; // Default: libar-generic preset (simple 3-category taxonomy) export default defineConfig({ @@ -29,7 +29,7 @@ export default defineConfig({ | Preset | Use When | Categories | | --------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------- | -| `libar-generic` | Simple projects, standard `@libar-docs-` prefix | 3 (core, api, infra) | +| `libar-generic` | Simple projects, standard `@architect-` prefix | 3 (core, api, infra) | | `generic` | Prefer shorter `@docs-` prefix | 3 (core, api, infra) | | `ddd-es-cqrs` | DDD architecture with bounded contexts, event sourcing, CQRS | 21 (domain, ddd, bounded-context, event-sourcing, decider, cqrs, saga, projection, etc.) | @@ -47,26 +47,26 @@ All entry points default to `libar-generic`: #### Unified Config File -The `defineConfig()` function centralizes taxonomy, sources, output, and generator overrides in a single `delivery-process.config.ts` file. CLI tools discover this file automatically. +The `defineConfig()` function centralizes taxonomy, sources, output, and generator overrides in a single `architect.config.ts` file. CLI tools discover this file automatically. ##### Discovery Order -1. Current directory: check `delivery-process.config.ts`, then `.js` +1. Current directory: check `architect.config.ts`, then `.js` 2. Walk up to repo root (`.git` folder), checking each directory -3. Fall back to libar-generic preset (3 categories, `@libar-docs-` prefix) +3. Fall back to libar-generic preset (3 categories, `@architect-` prefix) ##### Config File Format ```typescript -// delivery-process.config.ts -import { defineConfig } from '@libar-dev/delivery-process/config'; +// architect.config.ts +import { defineConfig } from '@libar-dev/architect/config'; export default defineConfig({ preset: 'libar-generic', sources: { typescript: ['src/**/*.ts'], - stubs: ['delivery-process/stubs/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + stubs: ['architect/stubs/**/*.ts'], + features: ['architect/specs/*.feature'], }, output: { directory: 'docs-generated', @@ -102,15 +102,15 @@ export default defineConfig({ preset: 'libar-generic', sources: { typescript: ['src/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + features: ['architect/specs/*.feature'], }, output: { directory: 'docs-generated', overwrite: true }, generatorOverrides: { changelog: { - additionalFeatures: ['delivery-process/decisions/*.feature'], + additionalFeatures: ['architect/decisions/*.feature'], }, 'doc-from-decision': { - replaceFeatures: ['delivery-process/decisions/*.feature'], + replaceFeatures: ['architect/decisions/*.feature'], }, }, }); @@ -127,7 +127,7 @@ export default defineConfig({ #### Monorepo Setup -```my-monorepo/ delivery-process.config.ts # Repo-level: ddd-es-cqrs packages/ my-package/ delivery-process.config.ts # Package-level: generic +```my-monorepo/ architect.config.ts # Repo-level: ddd-es-cqrs packages/ my-package/ architect.config.ts # Package-level: generic ``` @@ -187,7 +187,7 @@ export default defineConfig({ For tools that need to load configuration files: ```typescript -import { loadProjectConfig } from '@libar-dev/delivery-process/config'; +import { loadProjectConfig } from '@libar-dev/architect/config'; const result = await loadProjectConfig(process.cwd()); @@ -197,7 +197,7 @@ if (!result.ok) { } const resolved = result.value; -// resolved.instance - DeliveryProcessInstance (registry + regexBuilders) +// resolved.instance - ArchitectInstance (registry + regexBuilders) // resolved.project - ResolvedProjectConfig (sources, output, generators) // resolved.isDefault - true if no config file found // resolved.configPath - config file path (if found) @@ -206,7 +206,7 @@ const resolved = result.value; For per-generator source resolution: ```typescript -import { mergeSourcesForGenerator } from '@libar-dev/delivery-process/config'; +import { mergeSourcesForGenerator } from '@libar-dev/architect/config'; const effectiveSources = mergeSourcesForGenerator( resolved.project.sources, @@ -219,12 +219,12 @@ const effectiveSources = mergeSourcesForGenerator( #### Backward Compatibility -The legacy `createDeliveryProcess()` API is still exported and supported. Config files using the old format are detected automatically by `loadProjectConfig()` and wrapped in a `ResolvedConfig` with default project settings. +The legacy `createArchitect()` API is still exported and supported. Config files using the old format are detected automatically by `loadProjectConfig()` and wrapped in a `ResolvedConfig` with default project settings. ```typescript // Legacy format (still works) -import { createDeliveryProcess } from '@libar-dev/delivery-process'; -export default createDeliveryProcess({ preset: 'ddd-es-cqrs' }); +import { createArchitect } from '@libar-dev/architect'; +export default createArchitect({ preset: 'ddd-es-cqrs' }); ``` New projects should use `defineConfig()` for the unified configuration experience. diff --git a/docs-live/_claude-md/configuration/configuration-overview.md b/docs-live/_claude-md/configuration/configuration-overview.md index 3c573a63..8d93ed44 100644 --- a/docs-live/_claude-md/configuration/configuration-overview.md +++ b/docs-live/_claude-md/configuration/configuration-overview.md @@ -1,37 +1,37 @@ ### Configuration Overview -**How do I configure the tool?** Configuration is the entry boundary — it transforms a user-authored `delivery-process.config.ts` file into a fully resolved `DeliveryProcessInstance` that powers the entire pipeline. The flow is: `defineConfig()` provides type-safe authoring (Vite convention, zero validation), `ConfigLoader` discovers and loads the file, `ProjectConfigSchema` validates via Zod, `ConfigResolver` applies defaults and merges stubs into sources, and `DeliveryProcessFactory` builds the final instance with `TagRegistry` and `RegexBuilders`. Three presets define escalating taxonomy complexity — from 3 categories (`generic`, `libar-generic`) to 21 (`ddd-es-cqrs`). `SourceMerger` computes per-generator source overrides, enabling generators like changelog to pull from different feature sets than the base config. +**How do I configure the tool?** Configuration is the entry boundary — it transforms a user-authored `architect.config.ts` file into a fully resolved `ArchitectInstance` that powers the entire pipeline. The flow is: `defineConfig()` provides type-safe authoring (Vite convention, zero validation), `ConfigLoader` discovers and loads the file, `ProjectConfigSchema` validates via Zod, `ConfigResolver` applies defaults and merges stubs into sources, and `ArchitectFactory` builds the final instance with `TagRegistry` and `RegexBuilders`. Three presets define escalating taxonomy complexity — from 3 categories (`generic`, `libar-generic`) to 21 (`ddd-es-cqrs`). `SourceMerger` computes per-generator source overrides, enabling generators like changelog to pull from different feature sets than the base config. #### Key Invariants -- Preset-based taxonomy: `generic` (3 categories, `@docs-`), `libar-generic` (3 categories, `@libar-docs-`), `ddd-es-cqrs` (21 categories, full DDD). Presets replace base categories entirely — they define prefix, categories, and metadata tags as a unit -- Resolution pipeline: defineConfig() → ConfigLoader → ProjectConfigSchema (Zod) → ConfigResolver → DeliveryProcessFactory → DeliveryProcessInstance. Each stage has a single responsibility +- Preset-based taxonomy: `generic` (3 categories, `@docs-`), `libar-generic` (3 categories, `@architect-`), `ddd-es-cqrs` (21 categories, full DDD). Presets replace base categories entirely — they define prefix, categories, and metadata tags as a unit +- Resolution pipeline: defineConfig() → ConfigLoader → ProjectConfigSchema (Zod) → ConfigResolver → ArchitectFactory → ArchitectInstance. Each stage has a single responsibility - Stubs merged at resolution time: Stub directory globs are appended to typescript sources, making stubs transparent to the downstream pipeline - Source override composition: SourceMerger applies per-generator overrides (`replaceFeatures`, `additionalFeatures`, `additionalInput`) to base sources. Exclude is always inherited from base -**Components:** Config (WorkflowLoader, ConfigurationTypes, ConfigResolver, RegexBuilders, ProjectConfigTypes, ProjectConfigSchema, ConfigurationPresets, SourceMerger, DeliveryProcessFactory, DefineConfig, ConfigurationDefaults, ConfigLoader) +**Components:** Config (WorkflowLoader, ConfigurationTypes, ConfigResolver, RegexBuilders, ProjectConfigTypes, ProjectConfigSchema, ConfigurationPresets, SourceMerger, ArchitectFactory, DefineConfig, ConfigurationDefaults, ConfigLoader) #### API Types -| Type | Kind | -| ---------------------------- | --------- | -| DeliveryProcessConfig | interface | -| DeliveryProcessInstance | interface | -| RegexBuilders | interface | -| DeliveryProcessProjectConfig | interface | -| SourcesConfig | interface | -| OutputConfig | interface | -| GeneratorSourceOverride | interface | -| ResolvedProjectConfig | interface | -| ResolvedSourcesConfig | interface | -| CreateDeliveryProcessOptions | interface | -| ConfigDiscoveryResult | interface | -| ConfigLoadError | interface | -| ResolvedConfig | type | -| PresetName | type | -| ConfigLoadResult | type | -| createRegexBuilders | function | -| createDeliveryProcess | function | -| findConfigFile | function | -| loadConfig | function | -| formatConfigError | function | +| Type | Kind | +| ----------------------- | --------- | +| ArchitectConfig | interface | +| ArchitectInstance | interface | +| RegexBuilders | interface | +| ArchitectProjectConfig | interface | +| SourcesConfig | interface | +| OutputConfig | interface | +| GeneratorSourceOverride | interface | +| ResolvedProjectConfig | interface | +| ResolvedSourcesConfig | interface | +| CreateArchitectOptions | interface | +| ConfigDiscoveryResult | interface | +| ConfigLoadError | interface | +| ResolvedConfig | type | +| PresetName | type | +| ConfigLoadResult | type | +| createRegexBuilders | function | +| createArchitect | function | +| findConfigFile | function | +| loadConfig | function | +| formatConfigError | function | diff --git a/docs-live/_claude-md/generation/generation-overview.md b/docs-live/_claude-md/generation/generation-overview.md index b24bd8f6..f5c28fe3 100644 --- a/docs-live/_claude-md/generation/generation-overview.md +++ b/docs-live/_claude-md/generation/generation-overview.md @@ -10,7 +10,7 @@ - Config-driven generation: A single `ReferenceDocConfig` produces a complete document. Content sources compose in fixed order: conventions, diagrams, shapes, behaviors - RenderableDocument IR: Codecs express intent ("this is a table"), the renderer handles syntax ("pipe-delimited markdown"). Switching output format requires only a new renderer - Composition order: Reference docs compose four content layers in fixed order. Product area docs compose five layers: intro, conventions, diagrams, shapes, business rules -- Shape extraction: TypeScript shapes (`interface`, `type`, `enum`, `function`, `const`) are extracted by declaration-level `@libar-docs-shape` tags. Shapes include source text, JSDoc, type parameters, and property documentation +- Shape extraction: TypeScript shapes (`interface`, `type`, `enum`, `function`, `const`) are extracted by declaration-level `@architect-shape` tags. Shapes include source text, JSDoc, type parameters, and property documentation - Generator registration: Generators self-register via `registerGenerator()`. The orchestrator runs them in registration order. Each generator owns its output files and codec configuration #### API Types diff --git a/docs-live/_claude-md/process/process-overview.md b/docs-live/_claude-md/process/process-overview.md index 68d95e25..8ac4354c 100644 --- a/docs-live/_claude-md/process/process-overview.md +++ b/docs-live/_claude-md/process/process-overview.md @@ -4,7 +4,7 @@ #### Key Invariants -- TypeScript source owns pattern identity: `@libar-docs-pattern` in TypeScript defines the pattern. Tier 1 specs are ephemeral working documents +- TypeScript source owns pattern identity: `@architect-pattern` in TypeScript defines the pattern. Tier 1 specs are ephemeral working documents - 7 canonical product-area values: Annotation, Configuration, Generation, Validation, DataAPI, CoreTypes, Process — reader-facing sections, not source modules - Two distinct status domains: Pattern FSM status (4 values) vs. deliverable status (6 values). Never cross domains - Session types define capabilities: planning creates specs, design creates stubs, implementation writes code. Each session type has a fixed input/output contract enforced by convention @@ -74,14 +74,14 @@ **Invariant:** Every tag has one of 6 format types that determines how its value is parsed. -| Format | Parsing | Example | -| ------------ | ------------------------------ | ------------------------------ | -| flag | Boolean presence, no value | @libar-docs-core | -| value | Simple string | @libar-docs-pattern MyPattern | -| enum | Constrained to predefined list | @libar-docs-status completed | -| csv | Comma-separated values | @libar-docs-uses A, B, C | -| number | Numeric value | @libar-docs-phase 15 | -| quoted-value | Preserves spaces | @libar-docs-brief:'Multi word' | +| Format | Parsing | Example | +| ------------ | ------------------------------ | ----------------------------- | +| flag | Boolean presence, no value | @architect-core | +| value | Simple string | @architect-pattern MyPattern | +| enum | Constrained to predefined list | @architect-status completed | +| csv | Comma-separated values | @architect-uses A, B, C | +| number | Numeric value | @architect-phase 15 | +| quoted-value | Preserves spaces | @architect-brief:'Multi word' | #### Source ownership diff --git a/docs-live/_claude-md/validation/process-guard.md b/docs-live/_claude-md/validation/process-guard.md index cec83ae5..f38355d0 100644 --- a/docs-live/_claude-md/validation/process-guard.md +++ b/docs-live/_claude-md/validation/process-guard.md @@ -24,9 +24,9 @@ | Situation | Solution | Example | | ----------------------------- | ---------------------------------- | --------------------------------------------- | -| Fix bug in completed spec | Add `@*-unlock-reason:'reason'` | `@libar-docs-unlock-reason:'Fix typo'` | -| Modify outside session scope | `--ignore-session` flag | `lint-process --staged --ignore-session` | -| CI treats warnings as errors | `--strict` flag | `lint-process --all --strict` | +| Fix bug in completed spec | Add `@*-unlock-reason:'reason'` | `@architect-unlock-reason:'Fix typo'` | +| Modify outside session scope | `--ignore-session` flag | `architect-guard --staged --ignore-session` | +| CI treats warnings as errors | `--strict` flag | `architect-guard --all --strict` | | Skip workflow (legacy import) | Multiple transitions in one commit | Set `roadmap` then `completed` in same commit | #### CLI Usage @@ -64,11 +64,11 @@ lint-process [options] ##### Examples ```bash -lint-process --staged # Pre-commit hook (recommended) -lint-process --all --strict # CI pipeline with strict mode -lint-process --file specs/my-feature.feature # Validate specific file -lint-process --staged --show-state # Debug: see derived state -lint-process --staged --ignore-session # Override session scope +architect-guard --staged # Pre-commit hook (recommended) +architect-guard --all --strict # CI pipeline with strict mode +architect-guard --file specs/my-feature.feature # Validate specific file +architect-guard --staged --show-state # Debug: see derived state +architect-guard --staged --ignore-session # Override session scope ``` #### Pre-commit Setup @@ -79,7 +79,7 @@ Configure Process Guard as a pre-commit hook using Husky. #!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh" -npx lint-process --staged +npx architect-guard --staged ``` ##### package.json Scripts @@ -87,8 +87,8 @@ npx lint-process --staged ```json { "scripts": { - "lint:process": "lint-process --staged", - "lint:process:ci": "lint-process --all --strict" + "lint:process": "architect-guard --staged", + "lint:process:ci": "architect-guard --all --strict" } } ``` @@ -104,7 +104,7 @@ import { validateChanges, hasErrors, summarizeResult, -} from '@libar-dev/delivery-process/lint'; +} from '@libar-dev/architect/lint'; // 1. Derive state from annotations const state = (await deriveProcessState({ baseDir: '.' })).value; @@ -147,11 +147,11 @@ Process Guard uses the Decider pattern: pure functions with no I/O. **Invariant:** Completed specs are immutable without an explicit unlock reason. The unlock reason must be at least 10 characters and cannot be a placeholder. -| Situation | Solution | Example | -| -------------------------- | ---------------------------------- | --------------------------------------------------- | -| Fix typo in completed spec | Add unlock reason tag | `@libar-docs-unlock-reason:Fix-typo-in-FSM-diagram` | -| Spec needs rework | Create new spec instead | New feature file with `roadmap` status | -| Legacy import | Multiple transitions in one commit | Set `roadmap` then `completed` | +| Situation | Solution | Example | +| -------------------------- | ---------------------------------- | -------------------------------------------------- | +| Fix typo in completed spec | Add unlock reason tag | `@architect-unlock-reason:Fix-typo-in-FSM-diagram` | +| Spec needs rework | Create new spec instead | New feature file with `roadmap` status | +| Legacy import | Multiple transitions in one commit | Set `roadmap` then `completed` | #### invalid-status-transition diff --git a/docs-live/_claude-md/validation/validation-overview.md b/docs-live/_claude-md/validation/validation-overview.md index b927aa87..0d8c1713 100644 --- a/docs-live/_claude-md/validation/validation-overview.md +++ b/docs-live/_claude-md/validation/validation-overview.md @@ -1,10 +1,10 @@ ### Validation Overview -**How is the workflow enforced?** Validation is the enforcement boundary — it ensures that every change to annotated source files respects the delivery lifecycle rules defined by the FSM, protection levels, and scope constraints. The system operates in three layers: the FSM validator checks status transitions against a 4-state directed graph, the Process Guard orchestrates commit-time validation using a Decider pattern (state derived from annotations, not stored separately), and the lint engine provides pluggable rule execution with pretty and JSON output. Anti-pattern detection enforces dual-source ownership boundaries — `@libar-docs-uses` belongs on TypeScript, `@libar-docs-depends-on` belongs on Gherkin — preventing cross-domain tag confusion that causes documentation drift. Definition of Done validation ensures completed patterns have all deliverables marked done and at least one acceptance-criteria scenario. +**How is the workflow enforced?** Validation is the enforcement boundary — it ensures that every change to annotated source files respects the delivery lifecycle rules defined by the FSM, protection levels, and scope constraints. The system operates in three layers: the FSM validator checks status transitions against a 4-state directed graph, the Process Guard orchestrates commit-time validation using a Decider pattern (state derived from annotations, not stored separately), and the lint engine provides pluggable rule execution with pretty and JSON output. Anti-pattern detection enforces dual-source ownership boundaries — `@architect-uses` belongs on TypeScript, `@architect-depends-on` belongs on Gherkin — preventing cross-domain tag confusion that causes documentation drift. Definition of Done validation ensures completed patterns have all deliverables marked done and at least one acceptance-criteria scenario. #### Key Invariants -- Protection levels: `roadmap`/`deferred` = none (fully editable), `active` = scope-locked (no new deliverables), `completed` = hard-locked (requires `@libar-docs-unlock-reason`) +- Protection levels: `roadmap`/`deferred` = none (fully editable), `active` = scope-locked (no new deliverables), `completed` = hard-locked (requires `@architect-unlock-reason`) - Valid FSM transitions: Only roadmap→active, roadmap→deferred, active→completed, active→roadmap, deferred→roadmap. Completed is terminal - Decider pattern: All validation is (state, changes, options) → result. State is derived from annotations, not maintained separately - Dual-source ownership: Anti-pattern detection enforces tag boundaries — `uses` on TypeScript (runtime deps), `depends-on`/`quarter`/`team` on Gherkin (planning metadata). Violations are flagged before they cause documentation drift diff --git a/docs-live/_claude-md/validation/validation-tools-guide.md b/docs-live/_claude-md/validation/validation-tools-guide.md index 0ed8986c..ead31b71 100644 --- a/docs-live/_claude-md/validation/validation-tools-guide.md +++ b/docs-live/_claude-md/validation/validation-tools-guide.md @@ -16,17 +16,17 @@ Need cross-source or DoD validation? Yes -> validate-patterns Running pre-commit hook? - lint-process --staged (default) + architect-guard --staged (default) ``` #### Command Summary -| Command | Purpose | When to Use | -| ------------------- | --------------------------------- | --------------------------------------------- | -| `lint-patterns` | Annotation quality | Ensure patterns have required tags | -| `lint-steps` | vitest-cucumber compatibility | After writing/modifying feature or step files | -| `lint-process` | FSM workflow enforcement | Pre-commit hooks, CI pipelines | -| `validate-patterns` | Cross-source + DoD + anti-pattern | Release validation, comprehensive | +| Command | Purpose | When to Use | +| ------------------------- | --------------------------------- | --------------------------------------------- | +| `architect-lint-patterns` | Annotation quality | Ensure patterns have required tags | +| `architect-lint-steps` | vitest-cucumber compatibility | After writing/modifying feature or step files | +| `architect-guard` | FSM workflow enforcement | Pre-commit hooks, CI pipelines | +| `architect-validate` | Cross-source + DoD + anti-pattern | Release validation, comprehensive | #### lint-patterns @@ -113,8 +113,8 @@ pnpm lint:steps --strict # CI FSM validation for delivery workflow. Enforces status transitions and protection levels. ```bash -npx lint-process --staged # Pre-commit (default) -npx lint-process --all --strict # CI pipeline +npx architect-guard --staged # Pre-commit (default) +npx architect-guard --all --strict # CI pipeline ``` **What it validates:** @@ -189,8 +189,8 @@ For patterns with `completed` status, checks: "lint:patterns": "lint-patterns -i 'src/**/*.ts'", "lint:steps": "lint-steps", "lint:steps:ci": "lint-steps --strict", - "lint:process": "lint-process --staged", - "lint:process:ci": "lint-process --all --strict", + "lint:process": "architect-guard --staged", + "lint:process:ci": "architect-guard --all --strict", "validate:all": "validate-patterns -i 'src/**/*.ts' -F 'specs/**/*.feature' --dod --anti-patterns" } } @@ -199,7 +199,7 @@ For patterns with `completed` status, checks: ##### Pre-commit Hook ```bash -npx lint-process --staged +npx architect-guard --staged ``` ##### GitHub Actions @@ -229,14 +229,14 @@ All validation tools expose programmatic APIs: ```typescript // Pattern linting -import { lintFiles, hasFailures } from '@libar-dev/delivery-process/lint'; +import { lintFiles, hasFailures } from '@libar-dev/architect/lint'; // Step linting -import { runStepLint, STEP_LINT_RULES } from '@libar-dev/delivery-process/lint'; +import { runStepLint, STEP_LINT_RULES } from '@libar-dev/architect/lint'; // Process guard -import { deriveProcessState, validateChanges } from '@libar-dev/delivery-process/lint'; +import { deriveProcessState, validateChanges } from '@libar-dev/architect/lint'; // Anti-patterns and DoD -import { detectAntiPatterns, validateDoD } from '@libar-dev/delivery-process/validation'; +import { detectAntiPatterns, validateDoD } from '@libar-dev/architect/validation'; ``` diff --git a/docs-live/_claude-md/workflow/session-workflow-guide.md b/docs-live/_claude-md/workflow/session-workflow-guide.md index 7eac2d4b..ad1923df 100644 --- a/docs-live/_claude-md/workflow/session-workflow-guide.md +++ b/docs-live/_claude-md/workflow/session-workflow-guide.md @@ -18,7 +18,7 @@ Use this flowchart to determine which session type to run. Implementation sessions MUST follow this strict 5-step sequence. Skipping steps causes Process Guard rejection at commit time. 1. **Transition to `active` FIRST** (before any code changes) -2. **Create executable spec stubs** (if `@libar-docs-executable-specs` present) +2. **Create executable spec stubs** (if `@architect-executable-specs` present) 3. **For each deliverable:** implement, test, update status to `complete` 4. **Transition to `completed`** (only when ALL deliverables done) 5. **Regenerate docs:** `pnpm docs:all` @@ -39,8 +39,8 @@ Implementation sessions MUST follow this strict 5-step sequence. Skipping steps ##### Context Gathering ```bash -pnpm process:query -- overview # Project health -pnpm process:query -- list --status roadmap --names-only # Available patterns +pnpm architect:query -- overview # Project health +pnpm architect:query -- list --status roadmap --names-only # Available patterns ``` ##### Planning Checklist @@ -50,7 +50,7 @@ pnpm process:query -- list --status roadmap --names-only # Available patter - [ ] **Structure the feature** with Problem/Solution, tags, deliverables table - [ ] **Convert constraints to Rule: blocks** with Invariant/Rationale - [ ] **Add scenarios** per Rule: 1 happy-path + 1 validation minimum -- [ ] **Set executable specs location** via `@libar-docs-executable-specs` tag +- [ ] **Set executable specs location** via `@architect-executable-specs` tag ##### Planning Do NOT @@ -65,9 +65,9 @@ pnpm process:query -- list --status roadmap --names-only # Available patter ##### Context Gathering ```bash -pnpm process:query -- context --session design # Full context bundle -pnpm process:query -- dep-tree # Dependency chain -pnpm process:query -- stubs # Existing design stubs +pnpm architect:query -- context --session design # Full context bundle +pnpm architect:query -- dep-tree # Dependency chain +pnpm architect:query -- stubs # Existing design stubs ``` ##### When to Use Design Sessions @@ -80,12 +80,12 @@ pnpm process:query -- stubs # Existing design ##### Design Checklist -- [ ] **Record decisions** as PDR `.feature` files in `delivery-process/decisions/` +- [ ] **Record decisions** as PDR `.feature` files in `architect/decisions/` - [ ] **Document options** with at least 2-3 approaches and pros/cons - [ ] **Get approval** from user on recommended approach -- [ ] **Create code stubs** in `delivery-process/stubs/{pattern-name}/` +- [ ] **Create code stubs** in `architect/stubs/{pattern-name}/` - [ ] **Verify stub identifier spelling** before committing -- [ ] **List canonical helpers** in `@libar-docs-uses` tags +- [ ] **List canonical helpers** in `@architect-uses` tags ##### Design Do NOT @@ -111,8 +111,8 @@ pnpm process:query -- stubs # Existing design For multi-session work, capture state at session boundaries using the Process Data API. ```bash -pnpm process:query -- handoff --pattern -pnpm process:query -- handoff --pattern --git # include recent commits +pnpm architect:query -- handoff --pattern +pnpm architect:query -- handoff --pattern --git # include recent commits ``` #### Quick Reference: FSM Protection @@ -138,4 +138,4 @@ pnpm process:query -- handoff --pattern --git # include recent c | Implementation sessions follow FSM-enforced execution order | **Invariant:** Implementation sessions must follow a strict 5-step execution order.
Transition to active must... | | FSM errors have documented fixes | **Invariant:** Every Process Guard error code has a defined cause and fix. The
error codes, causes, and fixes... | | Handoff captures session-end state for continuity | **Invariant:** Multi-session work requires handoff documentation generated from
the Process Data API. Handoff... | -| ClaudeModuleGeneration is the generation mechanism | **Invariant:** Phase 39 depends on ClaudeModuleGeneration (Phase 25). Adding
`@libar-docs-claude-module` and... | +| ClaudeModuleGeneration is the generation mechanism | **Invariant:** Phase 39 depends on ClaudeModuleGeneration (Phase 25). Adding
`@architect-claude-module` and... | diff --git a/docs-live/business-rules/annotation.md b/docs-live/business-rules/annotation.md index 54a75a2d..ce08c697 100644 --- a/docs-live/business-rules/annotation.md +++ b/docs-live/business-rules/annotation.md @@ -12,7 +12,7 @@ ### Ast Parser Exports -_The AST Parser extracts @libar-docs-_ directives from TypeScript source files\* +_The AST Parser extracts @architect-_ directives from TypeScript source files\* --- @@ -44,7 +44,7 @@ _ast-parser-exports.feature_ ### Ast Parser Metadata -_The AST Parser extracts @libar-docs-_ directives from TypeScript source files\* +_The AST Parser extracts @architect-_ directives from TypeScript source files\* --- @@ -96,7 +96,7 @@ _ast-parser-metadata.feature_ ### Ast Parser Relationships Edges -_The AST Parser extracts @libar-docs-_ directives from TypeScript source files\* +_The AST Parser extracts @architect-_ directives from TypeScript source files\* --- @@ -108,10 +108,10 @@ _The AST Parser extracts @libar-docs-_ directives from TypeScript source files\* **Verified by:** -- Extract @libar-docs-uses with single value -- Extract @libar-docs-uses with comma-separated values -- Extract @libar-docs-used-by with single value -- Extract @libar-docs-used-by with comma-separated values +- Extract @architect-uses with single value +- Extract @architect-uses with comma-separated values +- Extract @architect-used-by with single value +- Extract @architect-used-by with comma-separated values - Extract both uses and usedBy from same directive - NOT capture uses/usedBy values in description - Not set uses/usedBy when no relationship tags exist @@ -126,7 +126,7 @@ _The AST Parser extracts @libar-docs-_ directives from TypeScript source files\* **Verified by:** -- Skip comments without @libar-docs-\* tags +- Skip comments without @architect-\* tags - Skip invalid directive with incomplete tag - Handle malformed TypeScript gracefully - Handle empty file gracefully @@ -290,7 +290,7 @@ _declaration-level-shape-tagging.feature_ ### Depends On Tag -_Tests extraction of @libar-docs-depends-on and @libar-docs-enables_ +_Tests extraction of @architect-depends-on and @architect-enables_ --- @@ -375,16 +375,16 @@ _- Full AST parsing of every TypeScript file is expensive and slow_ --- -#### hasDocDirectives detects @libar-docs-\* section directives +#### hasDocDirectives detects @architect-\* section directives -> **Invariant:** hasDocDirectives must return true if and only if the source contains at least one @libar-docs-{suffix} directive (case-sensitive, @ required, suffix required). +> **Invariant:** hasDocDirectives must return true if and only if the source contains at least one @architect-{suffix} directive (case-sensitive, @ required, suffix required). > > **Rationale:** This is the first-pass filter in the scanner pipeline; false negatives cause patterns to be silently missed, while false positives only waste AST parsing time. **Verified by:** -- Detect @libar-docs-core directive in JSDoc block -- Detect various @libar-docs-\* directives +- Detect @architect-core directive in JSDoc block +- Detect various @architect-\* directives - Detect directive anywhere in file content - Detect multiple directives on same line - Detect directive in inline comment @@ -394,24 +394,24 @@ _- Full AST parsing of every TypeScript file is expensive and slow_ --- -#### hasFileOptIn detects file-level @libar-docs marker +#### hasFileOptIn detects file-level @architect marker -> **Invariant:** hasFileOptIn must return true if and only if the source contains a bare @libar-docs tag (not followed by a hyphen) inside a JSDoc block comment; line comments and @libar-docs-\* suffixed tags must not match. +> **Invariant:** hasFileOptIn must return true if and only if the source contains a bare @architect tag (not followed by a hyphen) inside a JSDoc block comment; line comments and @architect-\* suffixed tags must not match. > -> **Rationale:** File-level opt-in is the gate for including a file in the scanner pipeline; confusing @libar-docs-core (a section tag) with @libar-docs (file opt-in) would either miss files or over-include them. +> **Rationale:** File-level opt-in is the gate for including a file in the scanner pipeline; confusing @architect-core (a section tag) with @architect (file opt-in) would either miss files or over-include them. **Verified by:** -- Detect @libar-docs in JSDoc block comment -- Detect @libar-docs with description on same line -- Detect @libar-docs in multi-line JSDoc -- Detect @libar-docs anywhere in file -- Detect @libar-docs combined with section tags +- Detect @architect in JSDoc block comment +- Detect @architect with description on same line +- Detect @architect in multi-line JSDoc +- Detect @architect anywhere in file +- Detect @architect combined with section tags - Return false when only section tags present - Return false for multiple section tags without opt-in - Return false for empty content in hasFileOptIn -- Return false for @libar-docs in line comment -- Not confuse @libar-docs-\* with @libar-docs opt-in +- Return false for @architect in line comment +- Not confuse @architect-\* with @architect opt-in _directive-detection.feature_ @@ -546,7 +546,7 @@ _dual-source-extraction.feature_ ### Extends Tag -_Tests for the @libar-docs-extends tag which establishes generalization_ +_Tests for the @architect-extends tag which establishes generalization_ --- @@ -764,7 +764,7 @@ _gherkin-parser.feature_ ### Implements Tag Processing -_Tests for the @libar-docs-implements tag which links implementation files_ +_Tests for the @architect-implements tag which links implementation files_ --- @@ -854,7 +854,7 @@ _- Manual layer annotation in every feature file is tedious and error-prone_ - Detect timeline features from /timeline/ path - Detect timeline features regardless of parent directories -- Detect timeline features in delivery-process package +- Detect timeline features in Architect package --- @@ -1118,16 +1118,16 @@ _- Need to scan entire codebases for documentation directives efficiently_ #### File opt-in requirement gates scanning -> **Invariant:** Only files containing a standalone @libar-docs marker (not @libar-docs-\*) are eligible for directive extraction. +> **Invariant:** Only files containing a standalone @architect marker (not @architect-\*) are eligible for directive extraction. > > **Rationale:** Without opt-in gating, every TypeScript file in the monorepo would be parsed, wasting processing time on files that have no documentation directives. **Verified by:** - Handle files with quick directive check optimization -- Skip files without @libar-docs file-level opt-in -- Not confuse @libar-docs-\* with @libar-docs opt-in -- Detect @libar-docs opt-in combined with section tags +- Skip files without @architect file-level opt-in +- Not confuse @architect-\* with @architect opt-in +- Detect @architect opt-in combined with section tags _scanner-core.feature_ @@ -1202,7 +1202,7 @@ _Validates the shape extraction system that extracts TypeScript type_ #### Annotation tags are stripped from extracted JSDoc while preserving standard tags -> **Invariant:** Extracted shapes never contain @libar-docs-\* annotation lines in their jsDoc field. +> **Invariant:** Extracted shapes never contain @architect-\* annotation lines in their jsDoc field. > > **Rationale:** Shape JSDoc is rendered in documentation output. Annotation tags are metadata for the extraction pipeline, not user-visible documentation content. @@ -1343,7 +1343,7 @@ _shape-extraction-types.feature_ ### Uses Tag -_Tests extraction and processing of @libar-docs-uses and @libar-docs-used-by_ +_Tests extraction and processing of @architect-uses and @architect-used-by_ --- diff --git a/docs-live/business-rules/configuration.md b/docs-live/business-rules/configuration.md index 99898fe6..31ccd964 100644 --- a/docs-live/business-rules/configuration.md +++ b/docs-live/business-rules/configuration.md @@ -309,9 +309,9 @@ _- New users need sensible defaults for their project type_ #### Libar generic preset provides minimal taxonomy with libar prefix -> **Invariant:** The libar-generic preset must provide exactly 3 categories with @libar-docs- prefix. +> **Invariant:** The libar-generic preset must provide exactly 3 categories with @architect- prefix. > -> **Rationale:** This package uses @libar-docs- prefix to avoid collisions with consumer projects' annotations. +> **Rationale:** This package uses @architect- prefix to avoid collisions with consumer projects' annotations. **Verified by:** @@ -381,13 +381,13 @@ _- Two config formats exist (new-style and legacy) that need unified loading_ #### Legacy config is loaded with backward compatibility -> **Invariant:** A file exporting createDeliveryProcess must be loaded and produce a valid resolved config. +> **Invariant:** A file exporting createArchitect must be loaded and produce a valid resolved config. > > **Rationale:** Backward compatibility prevents breaking existing consumers during migration to the new config format. **Verified by:** -- Legacy createDeliveryProcess export loads correctly +- Legacy createArchitect export loads correctly --- diff --git a/docs-live/business-rules/core-types.md b/docs-live/business-rules/core-types.md index cff0f955..e77686bb 100644 --- a/docs-live/business-rules/core-types.md +++ b/docs-live/business-rules/core-types.md @@ -233,7 +233,7 @@ _- Raw errors lack context (no file path, line number, or pattern name)_ - Errors include structured context - No console.warn bypasses error collection -- Skip feature files without @libar-docs opt-in +- Skip feature files without @architect opt-in --- diff --git a/docs-live/business-rules/data-api.md b/docs-live/business-rules/data-api.md index 90dd24f7..68a1a211 100644 --- a/docs-live/business-rules/data-api.md +++ b/docs-live/business-rules/data-api.md @@ -1105,7 +1105,7 @@ _Discovery subcommands: list, search, context assembly, tags/sources, extended a #### CLI unannotated subcommand finds files without annotations -> **Invariant:** The unannotated subcommand must return valid JSON listing every TypeScript file that lacks the `@libar-docs` opt-in marker. +> **Invariant:** The unannotated subcommand must return valid JSON listing every TypeScript file that lacks the `@architect` opt-in marker. > > **Rationale:** Files missing the opt-in marker are invisible to the scanner; without this subcommand, unannotated files silently drop out of generated documentation and validation. diff --git a/docs-live/business-rules/generation.md b/docs-live/business-rules/generation.md index e343917a..6619bf7d 100644 --- a/docs-live/business-rules/generation.md +++ b/docs-live/business-rules/generation.md @@ -322,7 +322,7 @@ _Validates that ARCHITECTURE.md retains its full reference content and that_ #### Four-Stage Pipeline section retains annotation format examples -> **Invariant:** The Four-Stage Pipeline section contains annotation format examples (e.g., @libar-docs-shape, extract-shapes) and appears before the Source Systems section in document order. +> **Invariant:** The Four-Stage Pipeline section contains annotation format examples (e.g., @architect-shape, extract-shapes) and appears before the Source Systems section in document order. > > **Rationale:** Annotation format examples in the pipeline section demonstrate the source-first architecture. Their ordering establishes the conceptual flow: pipeline stages first, then the source systems that feed them. @@ -2813,9 +2813,9 @@ _Tests the Implementations section rendering in pattern documents._ --- -#### Implementation files appear in pattern docs via @libar-docs-implements +#### Implementation files appear in pattern docs via @architect-implements -> **Invariant:** Any TypeScript file with a matching @libar-docs-implements tag must appear in the pattern document's Implementations section with a working file link. +> **Invariant:** Any TypeScript file with a matching @architect-implements tag must appear in the pattern document's Implementations section with a working file link. > > **Rationale:** Implementation discovery relies on tag-based linking — missing entries break traceability between specs and code. diff --git a/docs-live/business-rules/validation.md b/docs-live/business-rules/validation.md index 641eb046..b84c95de 100644 --- a/docs-live/business-rules/validation.md +++ b/docs-live/business-rules/validation.md @@ -18,7 +18,7 @@ _- Dependencies in features (should be code-only) cause drift_ #### Process metadata should not appear in TypeScript code -> **Invariant:** Process metadata tags (@libar-docs-status, @libar-docs-phase, etc.) must only appear in Gherkin feature files, never in TypeScript source code. +> **Invariant:** Process metadata tags (@architect-status, @architect-phase, etc.) must only appear in Gherkin feature files, never in TypeScript source code. > > **Rationale:** TypeScript owns runtime behavior while Gherkin owns delivery process metadata — mixing them creates dual-source conflicts and validation ambiguity. @@ -732,7 +732,7 @@ _- Completed specs modified without explicit unlock reason_ #### Completed files require unlock-reason to modify -> **Invariant:** A completed spec file cannot be modified unless it carries an @libar-docs-unlock-reason tag. +> **Invariant:** A completed spec file cannot be modified unless it carries an @architect-unlock-reason tag. > > **Rationale:** Completed work represents validated, shipped functionality — accidental modification risks regression. @@ -827,7 +827,7 @@ _Tests for the detectStatusTransitions function that parses git diff output._ #### Status transitions are detected from file-level tags -> **Invariant:** Status transitions must be detected by comparing @libar-docs-status tags at the file level between the old and new versions of a file. +> **Invariant:** Status transitions must be detected by comparing @architect-status tags at the file level between the old and new versions of a file. > > **Rationale:** File-level tags are the canonical source of pattern status — detecting transitions from tags ensures consistency with the FSM validator. diff --git a/docs-live/decisions/adr-001-taxonomy-canonical-values.md b/docs-live/decisions/adr-001-taxonomy-canonical-values.md index 68f55110..62c91f6b 100644 --- a/docs-live/decisions/adr-001-taxonomy-canonical-values.md +++ b/docs-live/decisions/adr-001-taxonomy-canonical-values.md @@ -106,7 +106,7 @@ These are the durable constants of the delivery process. - Canonical values are enforced Completed is a terminal state. Modifications require - `@libar-docs-unlock-reason` escape hatch. + `@architect-unlock-reason` escape hatch. ### Tag format types @@ -114,14 +114,14 @@ These are the durable constants of the delivery process. **Rationale:** Without explicit format types, parsers must guess value structure, leading to silent data corruption when CSV values are treated as single strings or numbers are treated as text. -| Format | Parsing | Example | -| ------------ | ------------------------------ | ------------------------------ | -| flag | Boolean presence, no value | @libar-docs-core | -| value | Simple string | @libar-docs-pattern MyPattern | -| enum | Constrained to predefined list | @libar-docs-status completed | -| csv | Comma-separated values | @libar-docs-uses A, B, C | -| number | Numeric value | @libar-docs-phase 15 | -| quoted-value | Preserves spaces | @libar-docs-brief:'Multi word' | +| Format | Parsing | Example | +| ------------ | ------------------------------ | ----------------------------- | +| flag | Boolean presence, no value | @architect-core | +| value | Simple string | @architect-pattern MyPattern | +| enum | Constrained to predefined list | @architect-status completed | +| csv | Comma-separated values | @architect-uses A, B, C | +| number | Numeric value | @architect-phase 15 | +| quoted-value | Preserves spaces | @architect-brief:'Multi word' | **Verified by:** diff --git a/docs-live/decisions/adr-002-gherkin-only-testing.md b/docs-live/decisions/adr-002-gherkin-only-testing.md index fa73e7f7..393fbf7f 100644 --- a/docs-live/decisions/adr-002-gherkin-only-testing.md +++ b/docs-live/decisions/adr-002-gherkin-only-testing.md @@ -17,7 +17,7 @@ test approaches: 97 legacy `.test.ts` files alongside Gherkin features. This undermined the core thesis that Gherkin IS sufficient for all testing. **Decision:** -Enforce strict Gherkin-only testing for the delivery-process package: +Enforce strict Gherkin-only testing for the Architect package: - All tests must be `.feature` files with step definitions - No new `.test.ts` files @@ -46,7 +46,7 @@ Enforce strict Gherkin-only testing for the delivery-process package: | Tests | .test.ts (hidden from docs) | .feature (visible in docs) | | Business rules | Manually maintained | Extracted from Rule blocks | | Acceptance criteria | Implicit in test code | Explicit @acceptance-criteria tags | -| Traceability | Manual cross-referencing | @libar-docs-implements links | +| Traceability | Manual cross-referencing | @architect-implements links | **Verified by:** diff --git a/docs-live/decisions/adr-003-source-first-pattern-architecture.md b/docs-live/decisions/adr-003-source-first-pattern-architecture.md index 6a59b141..3c068610 100644 --- a/docs-live/decisions/adr-003-source-first-pattern-architecture.md +++ b/docs-live/decisions/adr-003-source-first-pattern-architecture.md @@ -13,7 +13,7 @@ **Context:** The original annotation architecture assumed pattern definitions live -in tier 1 feature specs, with TypeScript code limited to `@libar-docs-implements`. +in tier 1 feature specs, with TypeScript code limited to `@architect-implements`. At scale this creates three problems: tier 1 specs become stale after implementation (only 39% of 44 specs have traceability to executable specs), retroactive annotation of existing code triggers merge conflicts, and duplicated Rules/Scenarios in tier 1 @@ -39,15 +39,15 @@ artifacts are annotated source code, executable specs, and decision specs. ### TypeScript source owns pattern identity -**Invariant:** A pattern is defined by `@libar-docs-pattern` in a TypeScript file — either a stub (pre-implementation) or source code (post-implementation). +**Invariant:** A pattern is defined by `@architect-pattern` in a TypeScript file — either a stub (pre-implementation) or source code (post-implementation). **Rationale:** If pattern identity lives in tier 1 specs, it becomes stale after implementation and diverges from the code that actually realizes the pattern. -| Phase | Location | Status | -| -------------- | -------------------------------------- | --------- | -| Design | `delivery-process/stubs/pattern-name/` | roadmap | -| Implementation | `src/path/to/module.ts` | active | -| Completed | `src/path/to/module.ts` | completed | +| Phase | Location | Status | +| -------------- | ------------------------------- | --------- | +| Design | `architect/stubs/pattern-name/` | roadmap | +| Implementation | `src/path/to/module.ts` | active | +| Completed | `src/path/to/module.ts` | completed | **Pattern Definition Lifecycle:** @@ -95,14 +95,14 @@ artifacts are annotated source code, executable specs, and decision specs. ### Implements is UML Realization (many-to-one) -**Invariant:** `@libar-docs-implements` declares a realization relationship. Multiple files can implement the same pattern. One file can implement multiple patterns (CSV format). +**Invariant:** `@architect-implements` declares a realization relationship. Multiple files can implement the same pattern. One file can implement multiple patterns (CSV format). **Rationale:** Without many-to-one realization, cross-cutting patterns that span multiple files cannot be traced back to a single canonical definition. -| Relationship | Tag | Cardinality | -| ------------ | ------------------------ | ----------------------- | -| Definition | `@libar-docs-pattern` | Exactly one per pattern | -| Realization | `@libar-docs-implements` | Many-to-one | +| Relationship | Tag | Cardinality | +| ------------ | ----------------------- | ----------------------- | +| Definition | `@architect-pattern` | Exactly one per pattern | +| Realization | `@architect-implements` | Many-to-one | **Verified by:** @@ -110,7 +110,7 @@ artifacts are annotated source code, executable specs, and decision specs. ### Single-definition constraint -**Invariant:** `@libar-docs-pattern:X` may appear in exactly one file across the entire codebase. The `mergePatterns()` conflict check in `orchestrator.ts` correctly enforces this. +**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. @@ -129,7 +129,7 @@ artifacts are annotated source code, executable specs, and decision specs. ### Reverse links preferred over forward links -**Invariant:** `@libar-docs-implements` (reverse: "I verify this pattern") is the primary traceability mechanism. `@libar-docs-executable-specs` (forward: "my tests live here") is retained but not required. +**Invariant:** `@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. **Rationale:** 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. diff --git a/docs-live/decisions/adr-006-single-read-model-architecture.md b/docs-live/decisions/adr-006-single-read-model-architecture.md index a762123e..f8a4be84 100644 --- a/docs-live/decisions/adr-006-single-read-model-architecture.md +++ b/docs-live/decisions/adr-006-single-read-model-architecture.md @@ -12,7 +12,7 @@ | Category | architecture | **Context:** -The delivery-process package applies event sourcing to itself: git is +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 — produced by a single-pass O(n) transformer with pre-computed views diff --git a/docs-live/decisions/adr-021-doc-generation-proof-of-concept.md b/docs-live/decisions/adr-021-doc-generation-proof-of-concept.md index a241b133..a8179f3c 100644 --- a/docs-live/decisions/adr-021-doc-generation-proof-of-concept.md +++ b/docs-live/decisions/adr-021-doc-generation-proof-of-concept.md @@ -14,7 +14,7 @@ **Status: SUPERSEDED** - This POC has been implemented. See: -- Convention-tagged decision records (ADR/PDR) with @libar-docs-convention tags +- Convention-tagged decision records (ADR/PDR) with @architect-convention tags - `docs-generated/ANNOTATION-GUIDE.md` - Comprehensive guide for fixing generated docs This decision establishes the pattern for generating technical documentation @@ -61,7 +61,7 @@ the PROOF OF CONCEPT (demonstrating the pattern works). **What We Have:** - The delivery-process package already has the required ingredients: + The Architect package already has the required ingredients: - Pattern extraction from TypeScript JSDoc and Gherkin tags - Rich content support (DocStrings, tables, code blocks in features) - Multi-source aggregation via tag taxonomy @@ -175,15 +175,15 @@ generate-docs --decisions 'specs/**/*.feature' --features 'tests/**/*.feature' - | THIS DECISION (Rule: X) | Extract specific Rule: block from current document | | THIS DECISION (DocString) | Extract fenced code blocks from current document | -| Extraction Method | Source Type | Action | -| -------------------------- | ------------------------ | ----------------------------------------------------- | -| Decision rule description | Decision (.feature) | Extract Rule: block content (Invariant, Rationale) | -| @extract-shapes tag | TypeScript (.ts) | Invoke shape extractor for @libar-docs-extract-shapes | -| Rule blocks | Behavior spec (.feature) | Extract Rule: names and descriptions | -| Scenario Outline Examples | Behavior spec (.feature) | Extract Examples tables as markdown | -| JSDoc section | TypeScript (.ts) | Extract markdown from JSDoc comments | -| createViolation() patterns | TypeScript (.ts) | Extract error message literals | -| Fenced code block | Decision (.feature) | Extract DocString code blocks with language | +| Extraction Method | Source Type | Action | +| -------------------------- | ------------------------ | ---------------------------------------------------- | +| Decision rule description | Decision (.feature) | Extract Rule: block content (Invariant, Rationale) | +| @extract-shapes tag | TypeScript (.ts) | Invoke shape extractor for @architect-extract-shapes | +| Rule blocks | Behavior spec (.feature) | Extract Rule: names and descriptions | +| Scenario Outline Examples | Behavior spec (.feature) | Extract Examples tables as markdown | +| JSDoc section | TypeScript (.ts) | Extract markdown from JSDoc comments | +| createViolation() patterns | TypeScript (.ts) | Extract error message literals | +| Fenced code block | Decision (.feature) | Extract DocString code blocks with language | **Table Format:** @@ -243,7 +243,7 @@ generate-docs --decisions 'specs/**/*.feature' --features 'tests/**/*.feature' - - Decision Rule descriptions become documentation sections -**Invariant:** Pre-implementation design stubs must reside in `delivery-process/stubs/`, never in `src/`. +**Invariant:** Pre-implementation design stubs must reside in `architect/stubs/`, never in `src/`. **Rationale:** Stubs in `src/` require ESLint exceptions, create confusion between production and design code, and risk accidental imports of unimplemented functions. @@ -255,18 +255,18 @@ generate-docs --decisions 'specs/**/*.feature' --features 'tests/**/*.feature' - | Import accidents | Other code might import unimplemented stubs | | Maintenance burden | Must track which files are stubs | -| Location | Content | When Moved to src/ | -| -------------------------------------- | --------------------------------------------- | ---------------------- | -| delivery-process/stubs/{pattern}/\*.ts | API shapes, interfaces, throw-not-implemented | Implementation session | -| src/\*_/_.ts | Production code only | Already there | +| Location | Content | When Moved to src/ | +| ------------------------------- | --------------------------------------------- | ---------------------- | +| architect/stubs/{pattern}/\*.ts | API shapes, interfaces, throw-not-implemented | Implementation session | +| src/\*_/_.ts | Production code only | Already there | -| Benefit | How | -| --------------------- | -------------------------------------------------------------------- | -| No ESLint exceptions | Stubs aren't in src/, no relaxation needed | -| Clear separation | delivery-process/stubs/ = design, src/ = production | -| Documentation source | Stubs with @extract-shapes generate API docs | -| Safe iteration | Can refine stub APIs without breaking anything | -| Implementation signal | Moving from delivery-process/stubs/ to src/ = implementation started | +| Benefit | How | +| --------------------- | ------------------------------------------------------------- | +| No ESLint exceptions | Stubs aren't in src/, no relaxation needed | +| Clear separation | architect/stubs/ = design, src/ = production | +| Documentation source | Stubs with @extract-shapes generate API docs | +| Safe iteration | Can refine stub APIs without breaking anything | +| Implementation signal | Moving from architect/stubs/ to src/ = implementation started | | Document | Decision Source | | ---------------------- | ----------------------------------------------- | @@ -299,17 +299,17 @@ generate-docs --decisions 'specs/**/*.feature' --features 'tests/**/*.feature' - **The Solution:** - Design stubs live in `delivery-process/stubs/`: + Design stubs live in `architect/stubs/`: **Design Stub Pattern:** ```typescript -// delivery-process/stubs/shape-extractor/shape-extractor.ts +// architect/stubs/shape-extractor/shape-extractor.ts /** - * @libar-docs - * @libar-docs-pattern ShapeExtractorStub - * @libar-docs-status roadmap + * @architect + * @architect-pattern ShapeExtractorStub + * @architect-status roadmap * * ## Shape Extractor - Design Stub * @@ -334,7 +334,7 @@ export function extractShapes( **Workflow:** - 1. **Design session:** Create stub in `delivery-process/stubs/{pattern-name}/` + 1. **Design session:** Create stub in `architect/stubs/{pattern-name}/` 2. **Iterate:** Refine API shapes, add JSDoc, test with docs generation 3. **Implementation session:** Move/copy to `src/`, implement real logic 4. **Stub becomes example:** Original stub stays as reference (optional) @@ -361,26 +361,26 @@ export function extractShapes( | docs/DOC-GENERATION-PROOF-OF-CONCEPT.md | Detailed reference | detailed | | \_claude-md/generated/doc-generation-proof-of-concept.md | AI context | summary | -| Section | Source File | Extraction Method | -| ----------------- | --------------------------------------------------- | -------------------------- | -| Intro & Context | THIS DECISION (Rule: Context above) | Decision rule description | -| How It Works | THIS DECISION (Rule: Decision above) | Decision rule description | -| Validation Rules | tests/features/validation/process-guard.feature | Rule blocks | -| Protection Levels | delivery-process/specs/process-guard-linter.feature | Scenario Outline Examples | -| Valid Transitions | delivery-process/specs/process-guard-linter.feature | Scenario Outline Examples | -| API Types | src/lint/process-guard/types.ts | @extract-shapes tag | -| Decider API | src/lint/process-guard/decider.ts | @extract-shapes tag | -| CLI Options | src/cli/lint-process.ts | JSDoc section | -| Error Messages | src/lint/process-guard/decider.ts | createViolation() patterns | -| Pre-commit Setup | THIS DECISION (DocString) | Fenced code block | -| Programmatic API | THIS DECISION (DocString) | Fenced code block | - -| Situation | Solution | Example | -| ----------------------------- | --------------------- | ----------------------------------------- | -| Fix bug in completed spec | Add unlock reason tag | `@libar-docs-unlock-reason:'Fix-typo'` | -| Modify outside session scope | Use ignore flag | `lint-process --staged --ignore-session` | -| CI treats warnings as errors | Use strict flag | `lint-process --all --strict` | -| Skip workflow (legacy import) | Multiple transitions | Set roadmap then completed in same commit | +| Section | Source File | Extraction Method | +| ----------------- | ----------------------------------------------- | -------------------------- | +| Intro & Context | THIS DECISION (Rule: Context above) | Decision rule description | +| How It Works | THIS DECISION (Rule: Decision above) | Decision rule description | +| Validation Rules | tests/features/validation/process-guard.feature | Rule blocks | +| Protection Levels | architect/specs/process-guard-linter.feature | Scenario Outline Examples | +| Valid Transitions | architect/specs/process-guard-linter.feature | Scenario Outline Examples | +| API Types | src/lint/process-guard/types.ts | @extract-shapes tag | +| Decider API | src/lint/process-guard/decider.ts | @extract-shapes tag | +| CLI Options | src/cli/lint-process.ts | JSDoc section | +| Error Messages | src/lint/process-guard/decider.ts | createViolation() patterns | +| Pre-commit Setup | THIS DECISION (DocString) | Fenced code block | +| Programmatic API | THIS DECISION (DocString) | Fenced code block | + +| Situation | Solution | Example | +| ----------------------------- | --------------------- | ------------------------------------------- | +| Fix bug in completed spec | Add unlock reason tag | `@architect-unlock-reason:'Fix-typo'` | +| Modify outside session scope | Use ignore flag | `architect-guard --staged --ignore-session` | +| CI treats warnings as errors | Use strict flag | `architect-guard --all --strict` | +| Skip workflow (legacy import) | Multiple transitions | Set roadmap then completed in same commit | **Process Guard docs are generated separately from `adr-006-process-guard.feature`.** @@ -395,7 +395,7 @@ export function extractShapes( File: `.husky/pre-commit` ```bash -npx lint-process --staged +npx architect-guard --staged ``` **Package.json Scripts:** @@ -403,8 +403,8 @@ npx lint-process --staged ```json { "scripts": { - "lint:process": "lint-process --staged", - "lint:process:ci": "lint-process --all --strict" + "lint:process": "architect-guard --staged", + "lint:process:ci": "architect-guard --all --strict" } } ``` @@ -418,7 +418,7 @@ import { validateChanges, hasErrors, summarizeResult, -} from '@libar-dev/delivery-process/lint'; +} from '@libar-dev/architect/lint'; // 1. Derive state from annotations const state = (await deriveProcessState({ baseDir: '.' })).value; diff --git a/docs-live/product-areas/ANNOTATION.md b/docs-live/product-areas/ANNOTATION.md index 22fd5e1b..3004be3a 100644 --- a/docs-live/product-areas/ANNOTATION.md +++ b/docs-live/product-areas/ANNOTATION.md @@ -116,9 +116,9 @@ interface TagRegistry { aggregationTags: readonly AggregationTagDefinitionForRegistry[]; /** Available format options for documentation output */ formatOptions: readonly string[]; - /** Prefix for all tags (e.g., "@libar-docs-") */ + /** Prefix for all tags (e.g., "@architect-") */ tagPrefix: string; - /** File-level opt-in marker tag (e.g., "@libar-docs") */ + /** File-level opt-in marker tag (e.g., "@architect") */ fileOptInTag: string; } ``` @@ -130,8 +130,8 @@ interface TagRegistry { | metadataTags | Metadata tag definitions with format, purpose, and validation rules | | aggregationTags | Aggregation tag definitions for document-level grouping | | formatOptions | Available format options for documentation output | -| tagPrefix | Prefix for all tags (e.g., "@libar-docs-") | -| fileOptInTag | File-level opt-in marker tag (e.g., "@libar-docs") | +| tagPrefix | Prefix for all tags (e.g., "@architect-") | +| fileOptInTag | File-level opt-in marker tag (e.g., "@architect") | ### MetadataTagDefinitionForRegistry (interface) @@ -151,7 +151,7 @@ interface MetadataTagDefinitionForRegistry { values?: readonly string[]; /** Default value applied when tag is not specified */ default?: string; - /** Example usage showing tag syntax (e.g., "@libar-docs-pattern MyPattern") */ + /** Example usage showing tag syntax (e.g., "@architect-pattern MyPattern") */ example?: string; /** Maps tag name to metadata object property name (defaults to kebab-to-camelCase) */ metadataKey?: string; @@ -169,7 +169,7 @@ interface MetadataTagDefinitionForRegistry { | repeatable | Whether this tag can appear multiple times on a single pattern | | values | Valid values for enum-type tags (undefined for non-enum formats) | | default | Default value applied when tag is not specified | -| example | Example usage showing tag syntax (e.g., "@libar-docs-pattern MyPattern") | +| example | Example usage showing tag syntax (e.g., "@architect-pattern MyPattern") | | metadataKey | Maps tag name to metadata object property name (defaults to kebab-to-camelCase) | | transform | Post-parse value transformer applied after format-based parsing | @@ -409,10 +409,10 @@ CATEGORY_TAGS = CATEGORIES.map((c) => c.tag) as readonly CategoryTag[]; ### Directive Detection -| Rule | Invariant | Rationale | -| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| hasDocDirectives detects @libar-docs-\* section directives | hasDocDirectives must return true if and only if the source contains at least one @libar-docs-{suffix} directive (case-sensitive, @ required, suffix required). | This is the first-pass filter in the scanner pipeline; false negatives cause patterns to be silently missed, while false positives only waste AST parsing time. | -| hasFileOptIn detects file-level @libar-docs marker | hasFileOptIn must return true if and only if the source contains a bare @libar-docs tag (not followed by a hyphen) inside a JSDoc block comment; line comments and @libar-docs-\* suffixed tags must not match. | File-level opt-in is the gate for including a file in the scanner pipeline; confusing @libar-docs-core (a section tag) with @libar-docs (file opt-in) would either miss files or over-include them. | +| Rule | Invariant | Rationale | +| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| hasDocDirectives detects @architect-\* section directives | hasDocDirectives must return true if and only if the source contains at least one @architect-{suffix} directive (case-sensitive, @ required, suffix required). | This is the first-pass filter in the scanner pipeline; false negatives cause patterns to be silently missed, while false positives only waste AST parsing time. | +| hasFileOptIn detects file-level @architect marker | hasFileOptIn must return true if and only if the source contains a bare @architect tag (not followed by a hyphen) inside a JSDoc block comment; line comments and @architect-\* suffixed tags must not match. | File-level opt-in is the gate for including a file in the scanner pipeline; confusing @architect-core (a section tag) with @architect (file opt-in) would either miss files or over-include them. | ### Doc String Media Type @@ -499,16 +499,16 @@ CATEGORY_TAGS = CATEGORIES.map((c) => c.tag) as readonly CategoryTag[]; ### Pattern Relationship Model -| Rule | Invariant | Rationale | -| --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Code files declare pattern realization via implements tag | Files with `@libar-docs-implements:PatternName,OtherPattern` are linked to the specified patterns without causing conflicts. Pattern definitions remain in roadmap specs; implementation files provide supplementary metadata. Multiple files can implement the same pattern, and one file can implement multiple patterns. | This mirrors UML's "realization" relationship where a class implements an interface. Code realizes the specification. Direction is code→spec (backward link). CSV format allows a single implementation file to realize multiple patterns when implementing a pattern family (e.g., durability primitives). | -| Pattern inheritance uses extends relationship tag | Files with `@libar-docs-extends:BasePattern` declare that they extend another pattern's capabilities. This is a generalization relationship where the extending pattern is a specialization of the base pattern. | Pattern families exist where specialized patterns build on base patterns. For example, `ReactiveProjections` extends `ProjectionCategories`. The extends relationship enables inheritance-based documentation and validates pattern hierarchy. | -| Technical dependencies use directed relationship tags | `@libar-docs-uses` declares outbound dependencies (what this pattern depends on). `@libar-docs-used-by` declares inbound dependencies (what depends on this pattern). Both are CSV format. | These represent technical coupling between patterns. The distinction matters for impact analysis: changing a pattern affects its `used-by` consumers but not its `uses` dependencies. | -| Roadmap sequencing uses ordering relationship tags | `@libar-docs-depends-on` declares what must be completed first (roadmap sequencing). `@libar-docs-enables` declares what this unlocks when completed. These are planning relationships, not technical dependencies. | Sequencing is about order of work, not runtime coupling. A pattern may depend on another being complete without using its code. | -| Cross-tier linking uses traceability tags (PDR-007) | `@libar-docs-executable-specs` on roadmap specs points to test locations. `@libar-docs-roadmap-spec` on package specs points back to the pattern. These create bidirectional traceability. | Two-tier architecture (PDR-007) separates planning specs from executable tests. Traceability tags maintain the connection for navigation and completeness checking. | -| Epic/Phase/Task hierarchy uses parent-child relationships | `@libar-docs-level` declares the hierarchy tier (epic, phase, task). `@libar-docs-parent` links to the containing pattern. This enables rollup progress tracking. | Large initiatives decompose into phases and tasks. The hierarchy allows progress aggregation (e.g., "Epic 80% complete based on child phases"). | -| All relationships appear in generated documentation | The PATTERNS.md dependency graph renders all relationship types with distinct visual styles. Pattern detail pages list all related artifacts grouped by relationship type. | Visualization makes the relationship model accessible. Different arrow styles distinguish relationship semantics at a glance. | -| Linter detects relationship violations | The pattern linter validates that all relationship targets exist, implements files don't have pattern tags, and bidirectional links are consistent. | Broken relationships cause confusion and incorrect generated docs. Early detection during linting prevents propagation of errors. | +| Rule | Invariant | Rationale | +| --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Code files declare pattern realization via implements tag | Files with `@architect-implements:PatternName,OtherPattern` are linked to the specified patterns without causing conflicts. Pattern definitions remain in roadmap specs; implementation files provide supplementary metadata. Multiple files can implement the same pattern, and one file can implement multiple patterns. | This mirrors UML's "realization" relationship where a class implements an interface. Code realizes the specification. Direction is code→spec (backward link). CSV format allows a single implementation file to realize multiple patterns when implementing a pattern family (e.g., durability primitives). | +| Pattern inheritance uses extends relationship tag | Files with `@architect-extends:BasePattern` declare that they extend another pattern's capabilities. This is a generalization relationship where the extending pattern is a specialization of the base pattern. | Pattern families exist where specialized patterns build on base patterns. For example, `ReactiveProjections` extends `ProjectionCategories`. The extends relationship enables inheritance-based documentation and validates pattern hierarchy. | +| Technical dependencies use directed relationship tags | `@architect-uses` declares outbound dependencies (what this pattern depends on). `@architect-used-by` declares inbound dependencies (what depends on this pattern). Both are CSV format. | These represent technical coupling between patterns. The distinction matters for impact analysis: changing a pattern affects its `used-by` consumers but not its `uses` dependencies. | +| Roadmap sequencing uses ordering relationship tags | `@architect-depends-on` declares what must be completed first (roadmap sequencing). `@architect-enables` declares what this unlocks when completed. These are planning relationships, not technical dependencies. | Sequencing is about order of work, not runtime coupling. A pattern may depend on another being complete without using its code. | +| Cross-tier linking uses traceability tags (PDR-007) | `@architect-executable-specs` on roadmap specs points to test locations. `@architect-roadmap-spec` on package specs points back to the pattern. These create bidirectional traceability. | Two-tier architecture (PDR-007) separates planning specs from executable tests. Traceability tags maintain the connection for navigation and completeness checking. | +| Epic/Phase/Task hierarchy uses parent-child relationships | `@architect-level` declares the hierarchy tier (epic, phase, task). `@architect-parent` links to the containing pattern. This enables rollup progress tracking. | Large initiatives decompose into phases and tasks. The hierarchy allows progress aggregation (e.g., "Epic 80% complete based on child phases"). | +| All relationships appear in generated documentation | The PATTERNS.md dependency graph renders all relationship types with distinct visual styles. Pattern detail pages list all related artifacts grouped by relationship type. | Visualization makes the relationship model accessible. Different arrow styles distinguish relationship semantics at a glance. | +| Linter detects relationship violations | The pattern linter validates that all relationship targets exist, implements files don't have pattern tags, and bidirectional links are consistent. | Broken relationships cause confusion and incorrect generated docs. Early detection during linting prevents propagation of errors. | ### Pattern Tag Extraction @@ -529,14 +529,14 @@ CATEGORY_TAGS = CATEGORIES.map((c) => c.tag) as readonly CategoryTag[]; | scanPatterns extracts directives from TypeScript files | Every file with a valid opt-in marker and JSDoc directives produces a complete ScannedFile with tags, description, examples, and exports. | Downstream generators depend on complete directive data; partial extraction causes silent documentation gaps across the monorepo. | | scanPatterns collects errors without aborting | A parse failure in one file never prevents other files from being scanned; the result is always Ok with errors collected separately. | In a monorepo with hundreds of files, a single syntax error must not block the entire documentation pipeline. | | Pattern matching and exclusion filtering | Glob patterns control file discovery and exclusion patterns remove matched files before scanning. | Without exclusion filtering, internal directories and generated files would pollute the pattern registry with false positives and slow down scanning. | -| File opt-in requirement gates scanning | Only files containing a standalone @libar-docs marker (not @libar-docs-\*) are eligible for directive extraction. | Without opt-in gating, every TypeScript file in the monorepo would be parsed, wasting processing time on files that have no documentation directives. | +| File opt-in requirement gates scanning | Only files containing a standalone @architect marker (not @architect-\*) are eligible for directive extraction. | Without opt-in gating, every TypeScript file in the monorepo would be parsed, wasting processing time on files that have no documentation directives. | ### Shape Extraction | Rule | Invariant | Rationale | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | extract-shapes tag is defined in registry | The `extract-shapes` tag must exist with CSV format to list multiple type names for extraction. | Without a CSV-format tag, there is no mechanism to specify which type names to extract, and the extractor cannot discover shapes from source files. | -| Interfaces are extracted from TypeScript AST | When `@libar-docs-extract-shapes` lists an interface name, the extractor must find and extract the complete interface definition including JSDoc comments, generics, and extends clauses. | Partial extraction (missing generics, JSDoc, or extends clauses) produces incomplete API documentation that misleads consumers about a type's actual contract. | +| Interfaces are extracted from TypeScript AST | When `@architect-extract-shapes` lists an interface name, the extractor must find and extract the complete interface definition including JSDoc comments, generics, and extends clauses. | Partial extraction (missing generics, JSDoc, or extends clauses) produces incomplete API documentation that misleads consumers about a type's actual contract. | | Type aliases are extracted from TypeScript AST | Type aliases (including union types, intersection types, and mapped types) are extracted when listed in extract-shapes. | Type aliases define domain vocabulary (status enums, branded types, utility types) that consumers need to understand API signatures; omitting them leaves gaps in generated documentation. | | Enums are extracted from TypeScript AST | Both string and numeric enums are extracted with their complete member definitions. | Enum members define the closed set of valid values for a type; extracting only the enum name without its members provides no useful information to documentation consumers. | | Function signatures are extracted (body omitted) | When a function name is listed in extract-shapes, only the signature (parameters, return type, generics) is extracted. The function body is replaced with ellipsis for documentation purposes. | Including implementation bodies in generated documentation exposes internal logic, bloats output size, and creates a maintenance burden when internals change without API changes. | @@ -555,7 +555,7 @@ CATEGORY_TAGS = CATEGORIES.map((c) => c.tag) as readonly CategoryTag[]; | Imported and re-exported shapes are tracked separately | Shapes resolved via import or re-export statements are classified distinctly from locally declared shapes. | Silently extracting imported types as if they were local declarations would produce duplicate or misleading documentation, since the canonical definition lives in another file. | | Invalid TypeScript produces error result | Malformed TypeScript source returns an error Result instead of throwing or producing partial shapes. | Unhandled parse exceptions would crash the pipeline mid-run, preventing all subsequent files from being processed. | | Shape rendering supports grouping options | The `groupInSingleBlock` option controls whether shapes render in one combined code fence or in separate per-shape code fences. | Different documentation layouts require different grouping strategies; a single block provides compact overviews while separate blocks allow per-type commentary. | -| Annotation tags are stripped from extracted JSDoc while preserving standard tags | Extracted shapes never contain @libar-docs-\* annotation lines in their jsDoc field. | Shape JSDoc is rendered in documentation output. Annotation tags are metadata for the extraction pipeline, not user-visible documentation content. | +| Annotation tags are stripped from extracted JSDoc while preserving standard tags | Extracted shapes never contain @architect-\* annotation lines in their jsDoc field. | Shape JSDoc is rendered in documentation output. Annotation tags are metadata for the extraction pipeline, not user-visible documentation content. | | Large source files are rejected to prevent memory exhaustion | Source files exceeding 5MB are rejected before parsing begins. | Feeding unbounded input to the TypeScript parser risks out-of-memory crashes that would halt the entire extraction pipeline. | ### Shape Extraction Types Testing diff --git a/docs-live/product-areas/CONFIGURATION.md b/docs-live/product-areas/CONFIGURATION.md index 8f582385..3dc0ee8d 100644 --- a/docs-live/product-areas/CONFIGURATION.md +++ b/docs-live/product-areas/CONFIGURATION.md @@ -5,12 +5,12 @@ --- -**How do I configure the tool?** Configuration is the entry boundary — it transforms a user-authored `delivery-process.config.ts` file into a fully resolved `DeliveryProcessInstance` that powers the entire pipeline. The flow is: `defineConfig()` provides type-safe authoring (Vite convention, zero validation), `ConfigLoader` discovers and loads the file, `ProjectConfigSchema` validates via Zod, `ConfigResolver` applies defaults and merges stubs into sources, and `DeliveryProcessFactory` builds the final instance with `TagRegistry` and `RegexBuilders`. Three presets define escalating taxonomy complexity — from 3 categories (`generic`, `libar-generic`) to 21 (`ddd-es-cqrs`). `SourceMerger` computes per-generator source overrides, enabling generators like changelog to pull from different feature sets than the base config. +**How do I configure the tool?** Configuration is the entry boundary — it transforms a user-authored `architect.config.ts` file into a fully resolved `ArchitectInstance` that powers the entire pipeline. The flow is: `defineConfig()` provides type-safe authoring (Vite convention, zero validation), `ConfigLoader` discovers and loads the file, `ProjectConfigSchema` validates via Zod, `ConfigResolver` applies defaults and merges stubs into sources, and `ArchitectFactory` builds the final instance with `TagRegistry` and `RegexBuilders`. Three presets define escalating taxonomy complexity — from 3 categories (`generic`, `libar-generic`) to 21 (`ddd-es-cqrs`). `SourceMerger` computes per-generator source overrides, enabling generators like changelog to pull from different feature sets than the base config. ## Key Invariants -- Preset-based taxonomy: `generic` (3 categories, `@docs-`), `libar-generic` (3 categories, `@libar-docs-`), `ddd-es-cqrs` (21 categories, full DDD). Presets replace base categories entirely — they define prefix, categories, and metadata tags as a unit -- Resolution pipeline: defineConfig() → ConfigLoader → ProjectConfigSchema (Zod) → ConfigResolver → DeliveryProcessFactory → DeliveryProcessInstance. Each stage has a single responsibility +- Preset-based taxonomy: `generic` (3 categories, `@docs-`), `libar-generic` (3 categories, `@architect-`), `ddd-es-cqrs` (21 categories, full DDD). Presets replace base categories entirely — they define prefix, categories, and metadata tags as a unit +- Resolution pipeline: defineConfig() → ConfigLoader → ProjectConfigSchema (Zod) → ConfigResolver → ArchitectFactory → ArchitectInstance. Each stage has a single responsibility - Stubs merged at resolution time: Stub directory globs are appended to typescript sources, making stubs transparent to the downstream pipeline - Source override composition: SourceMerger applies per-generator overrides (`replaceFeatures`, `additionalFeatures`, `additionalInput`) to base sources. Exclude is always inherited from base @@ -42,7 +42,7 @@ C4Context System(ProjectConfigSchema, "ProjectConfigSchema") System(ConfigurationPresets, "ConfigurationPresets") System(SourceMerger, "SourceMerger") - System(DeliveryProcessFactory, "DeliveryProcessFactory") + System(ArchitectFactory, "ArchitectFactory") System(DefineConfig, "DefineConfig") System(ConfigurationDefaults, "ConfigurationDefaults") System(ConfigLoader, "ConfigLoader") @@ -52,7 +52,7 @@ C4Context Rel(WorkflowLoader, WorkflowConfigSchema, "uses") Rel(WorkflowLoader, CodecUtils, "uses") Rel(ConfigResolver, ProjectConfigTypes, "uses") - Rel(ConfigResolver, DeliveryProcessFactory, "uses") + Rel(ConfigResolver, ArchitectFactory, "uses") Rel(ConfigResolver, ConfigurationDefaults, "uses") Rel(RegexBuilders, ConfigurationTypes, "uses") Rel(ProjectConfigTypes, ConfigurationTypes, "uses") @@ -60,11 +60,11 @@ C4Context Rel(ProjectConfigSchema, ProjectConfigTypes, "uses") Rel(ConfigurationPresets, ConfigurationTypes, "uses") Rel(SourceMerger, ProjectConfigTypes, "uses") - Rel(DeliveryProcessFactory, ConfigurationTypes, "uses") - Rel(DeliveryProcessFactory, ConfigurationPresets, "uses") - Rel(DeliveryProcessFactory, RegexBuilders, "uses") + Rel(ArchitectFactory, ConfigurationTypes, "uses") + Rel(ArchitectFactory, ConfigurationPresets, "uses") + Rel(ArchitectFactory, RegexBuilders, "uses") Rel(DefineConfig, ProjectConfigTypes, "uses") - Rel(ConfigLoader, DeliveryProcessFactory, "uses") + Rel(ConfigLoader, ArchitectFactory, "uses") Rel(ConfigLoader, ConfigurationTypes, "uses") ``` @@ -85,7 +85,7 @@ graph LR ProjectConfigSchema[/"ProjectConfigSchema"/] ConfigurationPresets["ConfigurationPresets"] SourceMerger("SourceMerger") - DeliveryProcessFactory("DeliveryProcessFactory") + ArchitectFactory("ArchitectFactory") DefineConfig[/"DefineConfig"/] ConfigurationDefaults["ConfigurationDefaults"] ConfigLoader[/"ConfigLoader"/] @@ -97,7 +97,7 @@ graph LR WorkflowLoader -->|uses| WorkflowConfigSchema WorkflowLoader -->|uses| CodecUtils ConfigResolver -->|uses| ProjectConfigTypes - ConfigResolver -->|uses| DeliveryProcessFactory + ConfigResolver -->|uses| ArchitectFactory ConfigResolver -->|uses| ConfigurationDefaults RegexBuilders -->|uses| ConfigurationTypes ProjectConfigTypes -->|uses| ConfigurationTypes @@ -105,11 +105,11 @@ graph LR ProjectConfigSchema -->|uses| ProjectConfigTypes ConfigurationPresets -->|uses| ConfigurationTypes SourceMerger -->|uses| ProjectConfigTypes - DeliveryProcessFactory -->|uses| ConfigurationTypes - DeliveryProcessFactory -->|uses| ConfigurationPresets - DeliveryProcessFactory -->|uses| RegexBuilders + ArchitectFactory -->|uses| ConfigurationTypes + ArchitectFactory -->|uses| ConfigurationPresets + ArchitectFactory -->|uses| RegexBuilders DefineConfig -->|uses| ProjectConfigTypes - ConfigLoader -->|uses| DeliveryProcessFactory + ConfigLoader -->|uses| ArchitectFactory ConfigLoader -->|uses| ConfigurationTypes classDef neighbor stroke-dasharray: 5 5 ``` @@ -118,7 +118,7 @@ graph LR ## API Types -### DeliveryProcessConfig (interface) +### ArchitectConfig (interface) ```typescript /** @@ -128,10 +128,10 @@ graph LR ``` ````typescript -interface DeliveryProcessConfig { - /** Tag prefix for directives (e.g., "@docs-" or "@libar-docs-") */ +interface ArchitectConfig { + /** Tag prefix for directives (e.g., "@docs-" or "@architect-") */ readonly tagPrefix: string; - /** File-level opt-in tag (e.g., "@docs" or "@libar-docs") */ + /** File-level opt-in tag (e.g., "@docs" or "@architect") */ readonly fileOptInTag: string; /** Category definitions for pattern classification */ readonly categories: readonly CategoryDefinition[]; @@ -157,22 +157,22 @@ interface DeliveryProcessConfig { | Property | Description | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| tagPrefix | Tag prefix for directives (e.g., "@docs-" or "@libar-docs-") | -| fileOptInTag | File-level opt-in tag (e.g., "@docs" or "@libar-docs") | +| tagPrefix | Tag prefix for directives (e.g., "@docs-" or "@architect-") | +| fileOptInTag | File-level opt-in tag (e.g., "@docs" or "@architect") | | categories | Category definitions for pattern classification | | metadataTags | Optional metadata tag definitions | | contextInferenceRules | Optional context inference rules for auto-inferring bounded context from file paths. When provided, these rules are merged with the default rules. User-provided rules take precedence over defaults (applied first in the rule list). `typescript contextInferenceRules: [ { pattern: 'packages/orders/**', context: 'orders' }, { pattern: 'packages/inventory/**', context: 'inventory' }, ] ` | -### DeliveryProcessInstance (interface) +### ArchitectInstance (interface) ```typescript /** - * Instance returned by createDeliveryProcess with configured registry + * Instance returned by createArchitect with configured registry */ ``` ```typescript -interface DeliveryProcessInstance { +interface ArchitectInstance { /** The fully configured tag registry */ readonly registry: TagRegistry; /** Regex builders for tag detection */ @@ -216,25 +216,25 @@ interface RegexBuilders { | fileOptInPattern | Pattern to match file-level opt-in (e.g., /\*_ @docs _\/) | | directivePattern | Pattern to match directives (e.g., @docs-pattern, @docs-status) | -### DeliveryProcessProjectConfig (interface) +### ArchitectProjectConfig (interface) ````typescript /** * Unified project configuration for delivery-process. * - * This is the shape users provide in `delivery-process.config.ts`. + * This is the shape users provide in `architect.config.ts`. * `defineConfig()` is an identity function providing type safety. * * @example * ```typescript - * import { defineConfig } from '@libar-dev/delivery-process/config'; + * import { defineConfig } from '@libar-dev/architect/config'; * * export default defineConfig({ * preset: 'ddd-es-cqrs', * sources: { * typescript: ['packages/* /src/** /*.ts'], - * features: ['delivery-process/specs/** /*.feature'], - * stubs: ['delivery-process/stubs/** /*.ts'], + * features: ['architect/specs/** /*.feature'], + * stubs: ['architect/stubs/** /*.ts'], * }, * output: { directory: 'docs-living', overwrite: true }, * }); @@ -243,7 +243,7 @@ interface RegexBuilders { ```` ```typescript -interface DeliveryProcessProjectConfig { +interface ArchitectProjectConfig { // --- Taxonomy --- /** Use a preset taxonomy configuration */ @@ -256,7 +256,7 @@ interface DeliveryProcessProjectConfig { readonly fileOptInTag?: string; /** Custom categories (replaces preset categories entirely) */ - readonly categories?: DeliveryProcessConfig['categories']; + readonly categories?: ArchitectConfig['categories']; // --- Sources --- @@ -345,7 +345,7 @@ interface SourcesConfig { /** * Glob patterns for design stub files. - * Stubs are TypeScript files that live outside `src/` (e.g., `delivery-process/stubs/`). + * Stubs are TypeScript files that live outside `src/` (e.g., `architect/stubs/`). * Merged into TypeScript sources at resolution time. */ readonly stubs?: readonly string[]; @@ -355,12 +355,12 @@ interface SourcesConfig { } ``` -| Property | Description | -| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| typescript | Glob patterns for TypeScript source files (replaces --input) | -| features | Glob patterns for Gherkin feature files (replaces --features). Includes both `.feature` and `.feature.md` files. | -| stubs | Glob patterns for design stub files. Stubs are TypeScript files that live outside `src/` (e.g., `delivery-process/stubs/`). Merged into TypeScript sources at resolution time. | -| exclude | Glob patterns to exclude from all scanning | +| Property | Description | +| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| typescript | Glob patterns for TypeScript source files (replaces --input) | +| features | Glob patterns for Gherkin feature files (replaces --features). Includes both `.feature` and `.feature.md` files. | +| stubs | Glob patterns for design stub files. Stubs are TypeScript files that live outside `src/` (e.g., `architect/stubs/`). Merged into TypeScript sources at resolution time. | +| exclude | Glob patterns to exclude from all scanning | ### OutputConfig (interface) @@ -502,7 +502,7 @@ interface ResolvedSourcesConfig { | features | Gherkin feature file globs | | exclude | Glob patterns to exclude from scanning | -### CreateDeliveryProcessOptions (interface) +### CreateArchitectOptions (interface) ```typescript /** @@ -511,7 +511,7 @@ interface ResolvedSourcesConfig { ``` ```typescript -interface CreateDeliveryProcessOptions { +interface CreateArchitectOptions { /** Use a preset configuration */ preset?: PresetName; /** Custom tag prefix (overrides preset) */ @@ -519,7 +519,7 @@ interface CreateDeliveryProcessOptions { /** Custom file opt-in tag (overrides preset) */ fileOptInTag?: string; /** Custom categories (replaces preset categories entirely) */ - categories?: DeliveryProcessConfig['categories']; + categories?: ArchitectConfig['categories']; } ``` @@ -545,7 +545,7 @@ interface ConfigDiscoveryResult { /** Absolute path to the config file (if found) */ path?: string; /** The loaded configuration instance */ - instance: DeliveryProcessInstance; + instance: ArchitectInstance; /** Whether the default configuration was used */ isDefault: boolean; } @@ -605,7 +605,7 @@ interface ConfigLoadError { type ResolvedConfig = | { /** The taxonomy instance (registry + regexBuilders) */ - readonly instance: DeliveryProcessInstance; + readonly instance: ArchitectInstance; /** The resolved project config with defaults applied */ readonly project: ResolvedProjectConfig; /** Config was generated from defaults (no config file found) */ @@ -615,7 +615,7 @@ type ResolvedConfig = } | { /** The taxonomy instance (registry + regexBuilders) */ - readonly instance: DeliveryProcessInstance; + readonly instance: ArchitectInstance; /** The resolved project config with defaults applied */ readonly project: ResolvedProjectConfig; /** Config was loaded from a file */ @@ -668,8 +668,8 @@ type ConfigLoadResult = * Creates type-safe regex builders for a given tag prefix configuration. * These are used throughout the scanner and validation pipeline. * - * @param tagPrefix - The tag prefix (e.g., "@docs-" or "@libar-docs-") - * @param fileOptInTag - The file opt-in tag (e.g., "@docs" or "@libar-docs") + * @param tagPrefix - The tag prefix (e.g., "@docs-" or "@architect-") + * @param fileOptInTag - The file opt-in tag (e.g., "@docs" or "@architect") * @returns RegexBuilders instance with pattern matching methods * * @example @@ -692,14 +692,14 @@ type ConfigLoadResult = function createRegexBuilders(tagPrefix: string, fileOptInTag: string): RegexBuilders; ``` -| Parameter | Type | Description | -| ------------ | ---- | ---------------------------------------------------- | -| tagPrefix | | The tag prefix (e.g., "@docs-" or "@libar-docs-") | -| fileOptInTag | | The file opt-in tag (e.g., "@docs" or "@libar-docs") | +| Parameter | Type | Description | +| ------------ | ---- | --------------------------------------------------- | +| tagPrefix | | The tag prefix (e.g., "@docs-" or "@architect-") | +| fileOptInTag | | The file opt-in tag (e.g., "@docs" or "@architect") | **Returns:** RegexBuilders instance with pattern matching methods -### createDeliveryProcess (function) +### createArchitect (function) ````typescript /** @@ -721,13 +721,13 @@ function createRegexBuilders(tagPrefix: string, fileOptInTag: string): RegexBuil * @example * ```typescript * // Use generic preset - * const dp = createDeliveryProcess({ preset: "generic" }); + * const dp = createArchitect({ preset: "generic" }); * ``` * * @example * ```typescript * // Custom prefix with DDD taxonomy - * const dp = createDeliveryProcess({ + * const dp = createArchitect({ * preset: "ddd-es-cqrs", * tagPrefix: "@my-project-", * fileOptInTag: "@my-project" @@ -737,13 +737,13 @@ function createRegexBuilders(tagPrefix: string, fileOptInTag: string): RegexBuil * @example * ```typescript * // Default (libar-generic preset with 3 categories) - * const dp = createDeliveryProcess(); + * const dp = createArchitect(); * ``` */ ```` ```typescript -function createDeliveryProcess(options: CreateDeliveryProcessOptions = {}): DeliveryProcessInstance; +function createArchitect(options: CreateArchitectOptions = {}): ArchitectInstance; ``` | Parameter | Type | Description | @@ -848,9 +848,9 @@ function formatConfigError(error: ConfigLoadError): string; * * @example * ```typescript - * import { createDeliveryProcess, GENERIC_PRESET } from '@libar-dev/delivery-process'; + * import { createArchitect, GENERIC_PRESET } from '@libar-dev/architect'; * - * const dp = createDeliveryProcess({ preset: "generic" }); + * const dp = createArchitect({ preset: "generic" }); * // Uses @docs-, @docs-pattern, @docs-status, etc. * ``` */ @@ -883,33 +883,33 @@ GENERIC_PRESET = { aliases: ['infrastructure'], }, ] as const satisfies readonly CategoryDefinition[], -} as const satisfies DeliveryProcessConfig; +} as const satisfies ArchitectConfig; ``` ### LIBAR_GENERIC_PRESET (const) ````typescript /** - * Generic preset with @libar-docs- prefix. + * Generic preset with @architect- prefix. * - * Same minimal categories as GENERIC_PRESET but with @libar-docs- prefix. - * This is the universal default preset for both `createDeliveryProcess()` and + * Same minimal categories as GENERIC_PRESET but with @architect- prefix. + * This is the universal default preset for both `createArchitect()` and * `loadConfig()` fallback. * * Suitable for: * - Most projects (default choice) - * - Projects already using @libar-docs- tags + * - Projects already using @architect- tags * - Package-level configuration (simplified categories, same prefix) * - Gradual adoption without tag migration * * @example * ```typescript - * import { createDeliveryProcess } from '@libar-dev/delivery-process'; + * import { createArchitect } from '@libar-dev/architect'; * * // Default preset (libar-generic): - * const dp = createDeliveryProcess(); - * // Uses @libar-docs-, @libar-docs-pattern, @libar-docs-status, etc. - * // With 3 category tags: @libar-docs-core, @libar-docs-api, @libar-docs-infra + * const dp = createArchitect(); + * // Uses @architect-, @architect-pattern, @architect-status, etc. + * // With 3 category tags: @architect-core, @architect-api, @architect-infra * ``` */ ```` @@ -941,7 +941,7 @@ LIBAR_GENERIC_PRESET = { aliases: ['infrastructure'], }, ] as const satisfies readonly CategoryDefinition[], -} as const satisfies DeliveryProcessConfig; +} as const satisfies ArchitectConfig; ``` ### DDD_ES_CQRS_PRESET (const) @@ -950,7 +950,7 @@ LIBAR_GENERIC_PRESET = { /** * Full DDD/ES/CQRS preset (current @libar-dev taxonomy). * - * Complete 21-category taxonomy with @libar-docs- prefix. Suitable for: + * Complete 21-category taxonomy with @architect- prefix. Suitable for: * - DDD architectures * - Event sourcing projects * - CQRS implementations @@ -958,9 +958,9 @@ LIBAR_GENERIC_PRESET = { * * @example * ```typescript - * import { createDeliveryProcess, DDD_ES_CQRS_PRESET } from '@libar-dev/delivery-process'; + * import { createArchitect, DDD_ES_CQRS_PRESET } from '@libar-dev/architect'; * - * const dp = createDeliveryProcess({ preset: "ddd-es-cqrs" }); + * const dp = createArchitect({ preset: "ddd-es-cqrs" }); * ``` */ ```` @@ -971,7 +971,7 @@ DDD_ES_CQRS_PRESET = { fileOptInTag: DEFAULT_FILE_OPT_IN_TAG, categories: CATEGORIES, metadataTags: buildRegistry().metadataTags, -} as const satisfies DeliveryProcessConfig; +} as const satisfies ArchitectConfig; ``` ### PRESETS (const) @@ -982,7 +982,7 @@ DDD_ES_CQRS_PRESET = { * * @example * ```typescript - * import { PRESETS, type PresetName } from '@libar-dev/delivery-process'; + * import { PRESETS, type PresetName } from '@libar-dev/architect'; * * function getPreset(name: PresetName) { * return PRESETS[name]; @@ -992,7 +992,7 @@ DDD_ES_CQRS_PRESET = { ```` ```typescript -const PRESETS: Record; +const PRESETS: Record; ``` --- @@ -1064,7 +1064,7 @@ const PRESETS: Record; | Rule | Invariant | Rationale | | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Generic preset provides minimal taxonomy | The generic preset must provide exactly 3 categories (core, api, infra) with @docs- prefix. | Simple projects need minimal configuration without DDD-specific categories cluttering the taxonomy. | -| Libar generic preset provides minimal taxonomy with libar prefix | The libar-generic preset must provide exactly 3 categories with @libar-docs- prefix. | This package uses @libar-docs- prefix to avoid collisions with consumer projects' annotations. | +| Libar generic preset provides minimal taxonomy with libar prefix | The libar-generic preset must provide exactly 3 categories with @architect- prefix. | This package uses @architect- prefix to avoid collisions with consumer projects' annotations. | | DDD-ES-CQRS preset provides full taxonomy | The DDD preset must provide all 21 categories spanning DDD, ES, CQRS, and infrastructure domains. | DDD architectures require fine-grained categorization to distinguish bounded contexts, aggregates, and projections. | | Presets can be accessed by name | All preset instances must be accessible via the PRESETS map using their canonical string key. | Programmatic access enables config files to reference presets by name instead of importing instances. | @@ -1074,16 +1074,16 @@ const PRESETS: Record; | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Missing config returns defaults | When no config file exists, loadProjectConfig must return a default resolved config with isDefault=true. | Graceful fallback enables zero-config usage — new projects work without requiring config file creation. | | New-style config is loaded and resolved | A file exporting defineConfig must be loaded, validated, and resolved with correct preset categories. | defineConfig is the primary config format — correct loading is the critical path for all documentation generation. | -| Legacy config is loaded with backward compatibility | A file exporting createDeliveryProcess must be loaded and produce a valid resolved config. | Backward compatibility prevents breaking existing consumers during migration to the new config format. | +| Legacy config is loaded with backward compatibility | A file exporting createArchitect must be loaded and produce a valid resolved config. | Backward compatibility prevents breaking existing consumers during migration to the new config format. | | Invalid configs produce clear errors | Config files without a default export or with invalid data must produce descriptive error messages. | Actionable error messages reduce debugging time — users need to know what to fix, not just that something failed. | ### Setup Command | Rule | Invariant | Rationale | | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Init detects existing project context before making changes | The init command reads the target directory for package.json, tsconfig.json, delivery-process.config.ts (or .js), and monorepo markers before prompting or generating any files. Detection results determine which steps are skipped. | Blindly generating files overwrites user configuration and breaks working setups. Context detection enables safe adoption into existing projects by skipping steps that are already complete. | +| Init detects existing project context before making changes | The init command reads the target directory for package.json, tsconfig.json, architect.config.ts (or .js), and monorepo markers before prompting or generating any files. Detection results determine which steps are skipped. | Blindly generating files overwrites user configuration and breaks working setups. Context detection enables safe adoption into existing projects by skipping steps that are already complete. | | Interactive prompts configure preset and source paths with smart defaults | The init command prompts for preset selection from the three available presets (generic, libar-generic, ddd-es-cqrs) with descriptions, and for source glob paths with defaults inferred from project structure. The --yes flag skips non-destructive selection prompts and uses defaults. Destructive overwrites require an explicit --force flag; otherwise init exits without modifying existing files. | New users do not know which preset to choose or what glob patterns to use. Smart defaults reduce decisions to confirmations. The --yes flag enables scripted adoption in CI. | -| Generated config file uses defineConfig with correct imports | The generated delivery-process.config.ts (or .js) imports defineConfig from the correct path, uses the selected preset, and includes configured source globs. An existing config file is never overwritten without confirmation. | The config file is the most important artifact. An incorrect import path or malformed glob causes every subsequent command to fail. The overwrite guard prevents destroying custom configuration. | +| Generated config file uses defineConfig with correct imports | The generated architect.config.ts (or .js) imports defineConfig from the correct path, uses the selected preset, and includes configured source globs. An existing config file is never overwritten without confirmation. | The config file is the most important artifact. An incorrect import path or malformed glob causes every subsequent command to fail. The overwrite guard prevents destroying custom configuration. | | Npm scripts are injected using bin command names | Injected scripts reference bin names (process-api, generate-docs) resolved via node_modules/.bin, not dist paths. Existing scripts are preserved. The package.json "type" field is preserved. ESM migration is an explicit opt-in via --esm flag. | The tutorial uses long fragile dist paths. Bin commands are the stable public API. Setting type:module ensures ESM imports work for the config. | | Directory structure and example annotation enable immediate first run | The init command creates directories for configured source globs and generates one example annotated TypeScript file with the minimum annotation set (opt-in marker, pattern tag, status, category, description). | Empty source globs produce a confusing "0 patterns" result. An example file proves the pipeline works and teaches annotation syntax by example. | | Init validates the complete setup by running the pipeline | After all files are generated, init runs process-api overview and reports whether the pipeline detected the example pattern. Success prints a summary and next steps. Failure prints diagnostic information. | Generating files without verification produces false confidence. Running the pipeline as the final step proves config, globs, directories, and the example annotation all work together. | diff --git a/docs-live/product-areas/DATA-API.md b/docs-live/product-areas/DATA-API.md index 2838dd79..28df392c 100644 --- a/docs-live/product-areas/DATA-API.md +++ b/docs-live/product-areas/DATA-API.md @@ -45,7 +45,7 @@ and `transformToMasterDataset` with validation summary. ## Consumer Architecture and PipelineOptions Differentiation -Three consumers share this factory: `process-api`, `validate-patterns`, and the +Three consumers share this factory: `architect`, `architect-validate`, and the generation orchestrator. `PipelineOptions` differentiates behavior by `mergeConflictStrategy` (`fatal` vs `concatenate`), `includeValidation` toggles, and `failOnScanErrors` policy without forking pipeline logic. @@ -416,16 +416,16 @@ SourceViewsSchema = z.object({ ```typescript RelationshipEntrySchema = z.object({ - /** Patterns this pattern uses (from @libar-docs-uses) */ + /** Patterns this pattern uses (from @architect-uses) */ uses: z.array(z.string()), - /** Patterns that use this pattern (from @libar-docs-used-by) */ + /** Patterns that use this pattern (from @architect-used-by) */ usedBy: z.array(z.string()), - /** Patterns this pattern depends on (from @libar-docs-depends-on) */ + /** Patterns this pattern depends on (from @architect-depends-on) */ dependsOn: z.array(z.string()), - /** Patterns this pattern enables (from @libar-docs-enables) */ + /** Patterns this pattern enables (from @architect-enables) */ enables: z.array(z.string()), // UML-inspired relationship fields (PatternRelationshipModel) @@ -441,10 +441,10 @@ RelationshipEntrySchema = z.object({ /** Patterns that extend this pattern (computed inverse) */ extendedBy: z.array(z.string()), - /** Related patterns for cross-reference without dependency (from @libar-docs-see-also tag) */ + /** Related patterns for cross-reference without dependency (from @architect-see-also tag) */ seeAlso: z.array(z.string()), - /** File paths to implementation APIs (from @libar-docs-api-ref tag) */ + /** File paths to implementation APIs (from @architect-api-ref tag) */ apiRef: z.array(z.string()), }); ``` @@ -573,11 +573,11 @@ ArchIndexSchema = z.object({ ### Data API Stub Integration -| Rule | Invariant | Rationale | -| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| All stubs are visible to the scanner pipeline | Every stub file in `delivery-process/stubs/` has `@libar-docs` opt-in and `@libar-docs-implements` linking it to its parent pattern. | The scanner requires `@libar-docs` opt-in marker to include a file. Without it, stubs are invisible regardless of other annotations. The `@libar-docs-implements` tag creates the bidirectional link: spec defines the pattern (via `@libar-docs-pattern`), stub implements it. Per PDR-009, stubs must NOT use `@libar-docs-pattern` -- that belongs to the feature file. | -| Stubs subcommand lists design stubs with implementation status | `stubs` returns stub files with their target paths, design session origins, and whether the target file already exists. | Before implementation, agents need to know: which stubs exist for a pattern, where they should be moved to, and which have already been implemented. The stub-to-implementation resolver compares `@libar-docs-target` paths against actual files to determine status. | -| Decisions and PDR commands surface design rationale | Design decisions (AD-N items) and PDR references from stub annotations are queryable by pattern name or PDR number. | Design sessions produce numbered decisions (AD-1, AD-2, etc.) and reference PDR decision records (see PDR-012). When reviewing designs or starting implementation, agents need to find these decisions without reading every stub file manually. | +| Rule | Invariant | Rationale | +| -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| All stubs are visible to the scanner pipeline | Every stub file in `architect/stubs/` has `@architect` opt-in and `@architect-implements` linking it to its parent pattern. | The scanner requires `@architect` opt-in marker to include a file. Without it, stubs are invisible regardless of other annotations. The `@architect-implements` tag creates the bidirectional link: spec defines the pattern (via `@architect-pattern`), stub implements it. Per PDR-009, stubs must NOT use `@architect-pattern` -- that belongs to the feature file. | +| Stubs subcommand lists design stubs with implementation status | `stubs` returns stub files with their target paths, design session origins, and whether the target file already exists. | Before implementation, agents need to know: which stubs exist for a pattern, where they should be moved to, and which have already been implemented. The stub-to-implementation resolver compares `@architect-target` paths against actual files to determine status. | +| Decisions and PDR commands surface design rationale | Design decisions (AD-N items) and PDR references from stub annotations are queryable by pattern name or PDR number. | Design sessions produce numbered decisions (AD-1, AD-2, etc.) and reference PDR decision records (see PDR-012). When reviewing designs or starting implementation, agents need to find these decisions without reading every stub file manually. | ### Fuzzy Match Tests @@ -643,9 +643,9 @@ ArchIndexSchema = z.object({ | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | MCP server starts via stdio transport and manages its own lifecycle | The MCP server communicates over stdio using JSON-RPC. It builds the pipeline once during initialization, then enters a request-response loop. No non-MCP output is written to stdout (no console.log, no pnpm banners). | MCP defines stdio as the standard transport for local tool servers. Claude Code spawns the process and communicates over stdin/stdout pipes. Any extraneous stdout output corrupts the JSON-RPC stream. Loading the pipeline during initialization ensures the first tool call is fast. | | ProcessStateAPI methods and CLI subcommands are registered as MCP tools | Every CLI subcommand is registered as an MCP tool with a JSON Schema describing its input parameters. Tool names use snake*case with a "dp*" prefix to avoid collisions with other MCP servers. | MCP tools are the unit of interaction. Each tool needs a name, description (for LLM tool selection), and JSON Schema for input validation. The "dp\_" prefix prevents collisions in multi-server setups. | -| MasterDataset is loaded once and reused across all tool invocations | The pipeline runs exactly once during server initialization. All subsequent tool calls read from in-memory MasterDataset. A manual rebuild can be triggered via a "dp_rebuild" tool. | The pipeline costs 2-5 seconds. Running it per tool call negates MCP benefits. Pre-computed views provide O(1) access ideal for a query server. | -| Source file changes trigger automatic dataset rebuild with debouncing | When --watch is enabled, changes to source files trigger an automatic pipeline rebuild. Multiple rapid changes are debounced into a single rebuild (default 500ms window). | During implementation sessions, source files change frequently. Without auto-rebuild, agents must manually call dp_rebuild. Debouncing prevents redundant rebuilds during rapid-fire saves. | -| MCP server is configurable via standard client configuration | The server works with .mcp.json (Claude Code), claude_desktop_config.json (Claude Desktop), and any MCP client. It accepts --input, --features, --base-dir args and auto-detects delivery-process.config.ts. | MCP clients discover servers through configuration files. The server must work with sensible defaults (config auto-detection) while supporting explicit overrides for monorepo setups. | +| MasterDataset is loaded once and reused across all tool invocations | The pipeline runs exactly once during server initialization. All subsequent tool calls read from in-memory MasterDataset. A manual rebuild can be triggered via a "architect_rebuild" tool. | The pipeline costs 2-5 seconds. Running it per tool call negates MCP benefits. Pre-computed views provide O(1) access ideal for a query server. | +| Source file changes trigger automatic dataset rebuild with debouncing | When --watch is enabled, changes to source files trigger an automatic pipeline rebuild. Multiple rapid changes are debounced into a single rebuild (default 500ms window). | During implementation sessions, source files change frequently. Without auto-rebuild, agents must manually call architect_rebuild. Debouncing prevents redundant rebuilds during rapid-fire saves. | +| MCP server is configurable via standard client configuration | The server works with .mcp.json (Claude Code), claude_desktop_config.json (Claude Desktop), and any MCP client. It accepts --input, --features, --base-dir args and auto-detects architect.config.ts. | MCP clients discover servers through configuration files. The server must work with sensible defaults (config auto-detection) while supporting explicit overrides for monorepo setups. | ### Output Pipeline Tests @@ -745,7 +745,7 @@ ArchIndexSchema = z.object({ | CLI context assembly subcommands return text output | Context assembly subcommands (context, overview, dep-tree) must produce non-empty human-readable text containing the requested pattern or summary, and require a pattern argument where applicable. | These subcommands replace manual file reads in AI sessions; empty or off-target output forces expensive explore-agent fallbacks that consume 5-10x more context. | | CLI tags and sources subcommands return JSON | The tags and sources subcommands must return valid JSON with the expected top-level structure (data key for tags, array for sources). | Annotation exploration depends on machine-parseable output; invalid JSON prevents automated enrichment workflows from detecting unannotated files and tag gaps. | | CLI extended arch subcommands query architecture relationships | Extended arch subcommands (neighborhood, compare, coverage) must return valid JSON reflecting the actual architecture relationships present in the scanned sources. | Architecture queries drive design-session decisions; stale or structurally invalid output leads to incorrect dependency analysis and missed coupling between bounded contexts. | -| CLI unannotated subcommand finds files without annotations | The unannotated subcommand must return valid JSON listing every TypeScript file that lacks the `@libar-docs` opt-in marker. | Files missing the opt-in marker are invisible to the scanner; without this subcommand, unannotated files silently drop out of generated documentation and validation. | +| CLI unannotated subcommand finds files without annotations | The unannotated subcommand must return valid JSON listing every TypeScript file that lacks the `@architect` opt-in marker. | Files missing the opt-in marker are invisible to the scanner; without this subcommand, unannotated files silently drop out of generated documentation and validation. | ### Process API Layered Extraction diff --git a/docs-live/product-areas/GENERATION.md b/docs-live/product-areas/GENERATION.md index 0911e859..e5574b52 100644 --- a/docs-live/product-areas/GENERATION.md +++ b/docs-live/product-areas/GENERATION.md @@ -11,7 +11,7 @@ | Stage | Module | Responsibility | | ----------- | -------------------------- | --------------------------------------------------------------- | -| Scanner | `src/scanner/` | File discovery, AST parsing, opt-in via `@libar-docs` | +| Scanner | `src/scanner/` | File discovery, AST parsing, opt-in via `@architect` | | Extractor | `src/extractor/` | Pattern extraction from TypeScript JSDoc and Gherkin tags | | Transformer | `src/generators/pipeline/` | MasterDataset with pre-computed views for O(1) access (ADR-006) | | Codec | `src/renderable/` | Pure functions: MasterDataset → RenderableDocument → Markdown | @@ -38,7 +38,7 @@ - Config-driven generation: A single `ReferenceDocConfig` produces a complete document. Content sources compose in fixed order: conventions, diagrams, shapes, behaviors - RenderableDocument IR: Codecs express intent ("this is a table"), the renderer handles syntax ("pipe-delimited markdown"). Switching output format requires only a new renderer - Composition order: Reference docs compose four content layers in fixed order. Product area docs compose five layers: intro, conventions, diagrams, shapes, business rules -- Shape extraction: TypeScript shapes (`interface`, `type`, `enum`, `function`, `const`) are extracted by declaration-level `@libar-docs-shape` tags. Shapes include source text, JSDoc, type parameters, and property documentation +- Shape extraction: TypeScript shapes (`interface`, `type`, `enum`, `function`, `const`) are extracted by declaration-level `@architect-shape` tags. Shapes include source text, JSDoc, type parameters, and property documentation - Generator registration: Generators self-register via `registerGenerator()`. The orchestrator runs them in registration order. Each generator owns its output files and codec configuration --- @@ -354,7 +354,7 @@ function transformToMasterDataset(raw: RawDataset): RuntimeMasterDataset; | Rule | Invariant | Rationale | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Convention-tagged JSDoc produces machine-extractable codec documentation | Every codec source file annotated with `@libar-docs-convention
codec-registry` must have structured JSDoc following the machine-extractable format. The convention extractor splits multi-codec files by `## Heading` into separate convention rules, each rendered as its own section in the generated reference document. | DD-1: Convention tag approach over dedicated codec. Rather than creating a new "codec inventory" codec that enumerates codecs from source, the existing convention-tag mechanism is reused. Each codec file's JSDoc is treated as convention rules tagged with `codec-registry`. This avoids new codec infrastructure and leverages the proven convention extractor path. The reference codec already handles 4-layer composition, so convention tags slot into the existing Layer 1 (conventions) position. | +| Convention-tagged JSDoc produces machine-extractable codec documentation | Every codec source file annotated with `@architect-convention
codec-registry` must have structured JSDoc following the machine-extractable format. The convention extractor splits multi-codec files by `## Heading` into separate convention rules, each rendered as its own section in the generated reference document. | DD-1: Convention tag approach over dedicated codec. Rather than creating a new "codec inventory" codec that enumerates codecs from source, the existing convention-tag mechanism is reused. Each codec file's JSDoc is treated as convention rules tagged with `codec-registry`. This avoids new codec infrastructure and leverages the proven convention extractor path. The reference codec already handles 4-layer composition, so convention tags slot into the existing Layer 1 (conventions) position. | | Machine-extractable JSDoc format follows structured heading convention | DD-2: Multi-codec JSDoc splitting uses one `## Heading` per codec per file. Each heading block contains structured fields in a fixed order: `**Purpose:**` one-liner, `**Output Files:**` file paths, options table with Type/Default/Description columns, `**When to Use:**` bullet list, and `**Factory Pattern:**` code example. Fields are optional -- codecs without options omit the table, codecs without factory patterns omit the code block. | The convention extractor uses `## ` heading regex to split descriptions into rules. Without this structure, a file like `session.ts` (3 codecs) would produce a single undifferentiated blob. The heading text becomes the convention rule title in the generated reference. The fixed field order ensures consistent rendering across all 20+ codec entries. | | Heading match in convention extractor handles whitespace correctly | The convention extractor's heading parser uses `matchEnd` (the character position after the full regex match) rather than `indexOf('\n',
heading.index)` to calculate where content starts after a heading. This prevents the `\s*` prefix in the heading regex from consuming leading newlines, which would cause `heading.index` to point to those newlines instead of the heading text. | Discovered during Phase 2 implementation. The heading regex `/^\s*##\s+(.+)$/gm` matches headings with optional leading whitespace. When a heading has leading newlines, `heading.index` points to the first newline (part of the `\s*` match), not the `##` character. Using `indexOf('\n', heading.index)` then finds the newline BEFORE the heading, producing content that includes the heading text itself. The fix uses the regex match's end position directly. | | Section disposition follows content-type routing | DD-3: Each ARCHITECTURE.md section is routed based on content type. Three routing strategies apply: (1) product area absorption -- sections describing a specific pipeline stage move to the corresponding product area document where they get live diagrams and relationship graphs; (2) generated shapes -- sections documenting TypeScript interfaces move to generated shape reference docs; (3) generated diagrams -- ASCII/text data flow diagrams are replaced by live Mermaid diagrams generated from architecture annotations. | The routing heuristic is: if a generated equivalent already exists, replace with pointer; if content is convention-taggable in source files, tag and generate; if editorial content that cannot be expressed as annotations, retain. This ensures each section lands in the location with the best maintenance model for its content type. | @@ -368,7 +368,7 @@ function transformToMasterDataset(raw: RawDataset): RuntimeMasterDataset; | Rule | Invariant | Rationale | | --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Product area sections coexist with generated documents | Each architecture section in docs/ARCHITECTURE.md has a corresponding generated document in docs-live/product-areas/ covering equivalent content from annotated sources. | Manual and generated docs must coexist during the transition period. Generated docs prove that annotated sources produce equivalent coverage before manual sections are deprecated. | -| Four-Stage Pipeline section retains annotation format examples | The Four-Stage Pipeline section contains annotation format examples (e.g., @libar-docs-shape, extract-shapes) and appears before the Source Systems section in document order. | Annotation format examples in the pipeline section demonstrate the source-first architecture. Their ordering establishes the conceptual flow: pipeline stages first, then the source systems that feed them. | +| Four-Stage Pipeline section retains annotation format examples | The Four-Stage Pipeline section contains annotation format examples (e.g., @architect-shape, extract-shapes) and appears before the Source Systems section in document order. | Annotation format examples in the pipeline section demonstrate the source-first architecture. Their ordering establishes the conceptual flow: pipeline stages first, then the source systems that feed them. | | Convention extraction produces ARCHITECTURE-CODECS reference document | The ARCHITECTURE-CODECS.md reference document is generated from convention-tagged JSDoc in codec source files and contains structured sections for each codec with output file references. | Codec documentation must stay synchronized with source code. Convention extraction from JSDoc ensures the reference document reflects actual codec implementations rather than manually maintained descriptions that drift. | | Full sections coexist with generated equivalents in docs-live | Major sections of ARCHITECTURE.md (Unified Transformation, Data Flow Diagrams, Quick Reference) are retained alongside their generated equivalents in docs-live/reference/. | Generated reference documents (ARCHITECTURE-TYPES.md, ARCHITECTURE-CODECS.md) provide exhaustive type and codec listings, but the manual sections offer architectural narrative and design rationale that generated docs cannot yet replicate. | | MasterDataset shapes appear in ARCHITECTURE-TYPES reference | The ARCHITECTURE-TYPES.md reference document contains core MasterDataset types (MasterDataset, RuntimeMasterDataset, RawDataset) and pipeline types (PipelineOptions, PipelineResult) extracted from shape annotations. | 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. | @@ -409,7 +409,7 @@ function transformToMasterDataset(raw: RawDataset): RuntimeMasterDataset; | Rule | Invariant | Rationale | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Extracts Rule blocks with Invariant and Rationale | Every `Rule:` block with `**Invariant:**` annotation must be extracted. Rules without annotations are included with rule name only. | Business rules are the core domain constraints. Extracting them separately from acceptance criteria creates a focused reference document for domain understanding. | -| Organizes rules by domain category and phase | Rules are grouped first by domain category (from `@libar-docs-*` flags), then by phase number for temporal ordering. | Domain-organized documentation helps stakeholders find rules relevant to their area of concern without scanning all rules. | +| Organizes rules by domain category and phase | Rules are grouped first by domain category (from `@architect-*` flags), then by phase number for temporal ordering. | Domain-organized documentation helps stakeholders find rules relevant to their area of concern without scanning all rules. | | Preserves code examples and comparison tables | DocStrings (`"""typescript`) and tables in Rule descriptions are rendered in the business rules document. | Code examples and tables provide concrete understanding of abstract rules. Removing them loses critical context. | | Generates scenario traceability links | Each rule's `**Verified by:**` section generates links to the scenarios that verify the rule. | Traceability enables audit compliance and helps developers find relevant tests when modifying rules. | @@ -431,7 +431,7 @@ function transformToMasterDataset(raw: RawDataset): RuntimeMasterDataset; | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CLI recipes are a separate generator from reference tables | The `CliRecipeGenerator` is a standalone sibling to `ProcessApiReferenceGenerator`, not an extension of it. Both implement `DocumentGenerator`, both consume `CLI_SCHEMA` directly, and both produce independent `OutputFile[]` via the standard orchestrator write path. The recipe generator produces `docs-live/reference/PROCESS-API-RECIPES.md` while the reference generator produces `docs-live/reference/PROCESS-API-REFERENCE.md`. | Reference tables and recipe guides serve different audiences and change at different cadences. Reference tables change when CLI flags are added or removed. Recipes change when workflow recommendations evolve. Coupling them in one generator would force both to change together and make the generator responsible for two distinct content types. ProcessApiReferenceGenerator is already completed and tested (Phase 43) -- extending it risks regressions. Two small standalone generators are easier to test and maintain than one large one. | | Recipe content uses a structured schema extension | `CLI_SCHEMA` is extended with a `recipes` field containing `RecipeGroup[]`. Each `RecipeGroup` has a title, optional description, and an array of `RecipeExample` objects. Each `RecipeExample` has a title, a purpose description, an array of RecipeStep entries (each with a command string and optional comment), and an optional expected output block. The schema extension is additive -- existing `CLIOptionGroup` types are unchanged. | Recipes are multi-command sequences ("run these 3 commands in order") with explanatory context. They do not fit into `CLIOptionGroup` which models individual flags. A separate `RecipeGroup[]` keeps the schema type-safe and makes recipes independently testable. Static expected output strings in the schema are deterministic -- no build-time CLI execution needed. | -| Narrative prose uses preamble mechanism | Editorial content that cannot be derived from the CLI schema -- specifically "Why Use This" motivational prose, the Quick Start example with output, and the session type decision tree -- uses a preamble mechanism in the generator configuration. Preamble content is manually authored in `delivery-process.config.ts` as structured section data and appears before all generated recipe content in the output file. | The "Why Use This" section explains the value proposition of the Data API CLI with a comparison table (CLI vs reading markdown). This is editorial judgment, not derivable from command metadata. The Quick Start shows a specific 3-command workflow with example terminal output. The session decision tree maps cognitive states ("Starting to code?") to session types. None of these have a source annotation -- they are instructional content authored for human understanding. The preamble mechanism exists precisely for this (proven by DocsConsolidationStrategy Phase 2 preamble implementation). | +| Narrative prose uses preamble mechanism | Editorial content that cannot be derived from the CLI schema -- specifically "Why Use This" motivational prose, the Quick Start example with output, and the session type decision tree -- uses a preamble mechanism in the generator configuration. Preamble content is manually authored in `architect.config.ts` as structured section data and appears before all generated recipe content in the output file. | The "Why Use This" section explains the value proposition of the Data API CLI with a comparison table (CLI vs reading markdown). This is editorial judgment, not derivable from command metadata. The Quick Start shows a specific 3-command workflow with example terminal output. The session decision tree maps cognitive states ("Starting to code?") to session types. None of these have a source annotation -- they are instructional content authored for human understanding. The preamble mechanism exists precisely for this (proven by DocsConsolidationStrategy Phase 2 preamble implementation). | | Generated recipe file complements manual PROCESS-API.md | After this pattern completes, `docs/PROCESS-API.md` is trimmed to a slim editorial introduction (~30 lines) containing the document title, a one-paragraph purpose statement, and links to both generated files: `docs-live/reference/PROCESS-API-REFERENCE.md` (option tables from Phase 43) and `docs-live/reference/PROCESS-API-RECIPES.md` (recipes and narratives from this pattern). The manual file retains the JSON Envelope, Exit Codes, and JSON Piping sections (~40 lines) which are operational reference unlikely to drift. All other prose sections are replaced by the generated recipe file. | Phase 43 established the hybrid pattern: keep editorial prose in the manual file, extract derivable content to generated files. This pattern extends the hybrid by recognizing that recipe content IS derivable from a structured schema. The ~460 lines of command descriptions, example output, and recipe blocks can be maintained as schema data rather than freeform markdown. What remains in the manual file (~70 lines total) is true operational reference (JSON envelope format, exit codes, piping tips) that changes rarely and has no schema source. | | Command narrative descriptions are sourced from schema metadata | Each command group in the generated recipe file includes a narrative description sourced from the CLI schema, not hardcoded in the generator. The existing `CLIOptionGroup.description` and `CLIOptionGroup.postNote` fields carry per-group narrative text. For command groups not currently in CLI_SCHEMA (Session Workflow Commands, Pattern Discovery, Architecture Queries, Metadata and Inventory), new `CommandGroup` entries are added to the schema with title, description, and per-command narrative metadata. | The manual PROCESS-API.md contains narrative descriptions for each command ("Highest-impact command. Pre-flight readiness check that prevents wasted sessions.") that are valuable developer context. Hardcoding these in the generator would create a second maintenance location. Placing them in CLI_SCHEMA co-locates command metadata (what the command does) with command definition (what flags it accepts), following the same single-source-of-truth principle that drove Phase 43. | @@ -603,14 +603,14 @@ function transformToMasterDataset(raw: RawDataset): RuntimeMasterDataset; | Proof of Concept - Self-documentation validates the pattern | The documentation generation pattern must be validated by generating documentation about itself from its own annotated sources. | A self-referential proof of concept exposes extraction gaps and source mapping issues that synthetic test data would miss. | | Expected Output - Compact claude module structure | Compact output must contain only essential tables and type names, with no JSDoc comments or implementation details. | AI context windows are finite; including non-essential content displaces actionable information and degrades session effectiveness. | | Consequences - Durable sources with clear ownership boundaries | Decision documents remain the authoritative source for intro, rationale, and convention content until explicitly superseded. | Without durable ownership, documentation sections lose their authoritative source and degrade into unattributed prose that no one updates. | -| Consequences - Design stubs live in stubs, not src | Pre-implementation design stubs must reside in `delivery-process/stubs/`, never in `src/`. | Stubs in `src/` require ESLint exceptions, create confusion between production and design code, and risk accidental imports of unimplemented functions. | +| Consequences - Design stubs live in stubs, not src | Pre-implementation design stubs must reside in `architect/stubs/`, never in `src/`. | Stubs in `src/` require ESLint exceptions, create confusion between production and design code, and risk accidental imports of unimplemented functions. | | Decision - Source mapping table parsing and extraction method dispatch | The source mapping table in a decision document defines how documentation sections are assembled from multiple source files. | Without a declarative mapping, generators must hard-code source-to-section relationships, making the system brittle to new document types. | ### Docs Consolidation Strategy | Rule | Invariant | Rationale | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Convention tags are the primary consolidation mechanism | Each consolidation phase follows the same pattern: register a convention tag value in `src/taxonomy/conventions.ts`, annotate source files with `@libar-docs-convention` tags using structured JSDoc, add a `ReferenceDocConfig` entry in `delivery-process.config.ts`, and replace the manual doc section with a pointer to the generated reference document. | Convention-tagged annotations are the only sustainable way to keep docs in sync with implementation. The reference codec (`createReferenceCodec`) already handles the 4-layer composition so each phase only needs annotation work and config — no new codec infrastructure required. | +| Convention tags are the primary consolidation mechanism | Each consolidation phase follows the same pattern: register a convention tag value in `src/taxonomy/conventions.ts`, annotate source files with `@architect-convention` tags using structured JSDoc, add a `ReferenceDocConfig` entry in `architect.config.ts`, and replace the manual doc section with a pointer to the generated reference document. | Convention-tagged annotations are the only sustainable way to keep docs in sync with implementation. The reference codec (`createReferenceCodec`) already handles the 4-layer composition so each phase only needs annotation work and config — no new codec infrastructure required. | | Preamble preserves editorial context in generated docs | `ReferenceDocConfig.preamble` accepts `readonly SectionBlock[]` that are prepended before all generated content. Preamble sections appear in both detailed and summary (claude-md) outputs, followed by a separator. A config without preamble produces no extra separator or empty sections. | Not all documentation content can be extracted from code annotations. Introductory prose, cross-cutting context, and reading guides require human authorship. The preamble provides a designated place for this content within the generated document structure, avoiding a separate hand-maintained file. | | Each consolidation phase is independently deliverable | Each phase can be implemented and validated independently. A phase is complete when: the manual doc section has been replaced with a pointer to the generated equivalent, `pnpm docs:all` produces the generated output without errors, and the generated content covers the replaced manual content. No phase requires another uncompleted phase to function. | Independent phases allow incremental consolidation without blocking on the full initiative. Each merged PR reduces manual maintenance immediately. Phase ordering in the plan is a suggested sequence (simplest first), not a dependency chain. | | Manual docs retain editorial and tutorial content | Documents containing philosophy (METHODOLOGY.md) remain fully manual with no generated equivalent (~238 lines). Documents that were originally manual but now have generated equivalents or have been restructured (SESSION-GUIDES.md, GHERKIN-PATTERNS.md, PROCESS-API.md) retain their editorial content as preamble within generated outputs. PUBLISHING.md was relocated to MAINTAINERS.md at the repository root. | The consolidation targets sections most likely to drift when code changes: reference tables, codec listings, validation rules, API types. Editorial content changes at a different cadence and requires human judgment to update. Forcing this into annotations would produce worse documentation. Documents that transitioned to hybrid generation preserve their editorial voice via preamble while keeping reference content in sync with source annotations. | @@ -640,12 +640,12 @@ function transformToMasterDataset(raw: RawDataset): RuntimeMasterDataset; ### Error Guide Codec -| Rule | Invariant | Rationale | -| ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Error guide extends the existing ValidationRulesCodec | Error diagnosis guide content is produced by enhancing the existing `ValidationRulesCodec` and its `RULE_DEFINITIONS` constant, not by creating a parallel codec. The enhanced codec adds fix rationale, alternative approaches, and integration context to the existing error catalog, FSM transitions, and protection level detail files. A separate `ErrorGuideCodec` class is not created. | `ValidationRulesCodec` already owns `RULE_DEFINITIONS` with error codes, causes, and fixes. It generates `error-catalog.md`, `fsm-transitions.md`, and `protection-levels.md`. Creating a parallel codec would duplicate RULE_DEFINITIONS access and fragment validation documentation across two codecs. Extending the existing codec keeps all validation reference content in one place. | -| Each error code has fix rationale explaining why the rule exists | Every error code in the generated output includes not just a fix command but a "why this rule exists" rationale. The rationale is sourced from `@libar-docs-convention:process-guard-errors` JSDoc annotations on the error-handling code in `src/lint/process-guard/`. The `RuleDefinition` interface is extended with a `rationale` field, or rationale is composed from convention-extracted content. | The existing `error-catalog.md` tells developers what to do (fix command) but not why the rule exists. Without rationale, developers reach for escape hatches instead of understanding the workflow constraint. PROCESS-GUARD.md includes rationale like "Prevents scope creep during implementation. Plan fully before starting; implement what was planned." -- this must survive in the generated output. | -| Preamble carries integration content that cannot come from annotations | Pre-commit setup instructions (Husky configuration, package.json scripts), CI pipeline patterns, programmatic API examples, and the Decider pattern architecture diagram use the `ReferenceDocConfig.preamble` mechanism. These are `SectionBlock[]` defined in the config entry, prepended before all generated content. Preamble content is manually authored and changes at editorial cadence, not code cadence. | Integration recipes (Husky hook setup, CI YAML patterns, API usage examples) are not extractable from source annotations because they describe how external systems consume Process Guard, not how Process Guard is implemented. The preamble mechanism exists precisely for this: editorial prose that lives in the config, not in a separate manual file, and appears in the generated output. | -| Convention tags source error context from annotated lint code | Error-handling code in `src/lint/process-guard/` is annotated with `@libar-docs-convention:process-guard-errors` using structured JSDoc that includes rationale, alternative approaches, and common mistake patterns. The convention tag value `process-guard-errors` is registered in `src/taxonomy/conventions.ts` in the `CONVENTION_VALUES` array. The `createReferenceCodec` factory extracts this content via the existing convention extractor pipeline. | Convention-tagged annotations on the error-handling code co-locate rationale with implementation. When a developer changes an error rule in the decider, the convention JSDoc is right there -- they update both in the same commit. This is the same pattern used by `codec-registry`, `pipeline-architecture`, and `taxonomy-rules` convention tags, all proven by CodecDrivenReferenceGeneration. | +| Rule | Invariant | Rationale | +| ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Error guide extends the existing ValidationRulesCodec | Error diagnosis guide content is produced by enhancing the existing `ValidationRulesCodec` and its `RULE_DEFINITIONS` constant, not by creating a parallel codec. The enhanced codec adds fix rationale, alternative approaches, and integration context to the existing error catalog, FSM transitions, and protection level detail files. A separate `ErrorGuideCodec` class is not created. | `ValidationRulesCodec` already owns `RULE_DEFINITIONS` with error codes, causes, and fixes. It generates `error-catalog.md`, `fsm-transitions.md`, and `protection-levels.md`. Creating a parallel codec would duplicate RULE_DEFINITIONS access and fragment validation documentation across two codecs. Extending the existing codec keeps all validation reference content in one place. | +| Each error code has fix rationale explaining why the rule exists | Every error code in the generated output includes not just a fix command but a "why this rule exists" rationale. The rationale is sourced from `@architect-convention:process-guard-errors` JSDoc annotations on the error-handling code in `src/lint/process-guard/`. The `RuleDefinition` interface is extended with a `rationale` field, or rationale is composed from convention-extracted content. | The existing `error-catalog.md` tells developers what to do (fix command) but not why the rule exists. Without rationale, developers reach for escape hatches instead of understanding the workflow constraint. PROCESS-GUARD.md includes rationale like "Prevents scope creep during implementation. Plan fully before starting; implement what was planned." -- this must survive in the generated output. | +| Preamble carries integration content that cannot come from annotations | Pre-commit setup instructions (Husky configuration, package.json scripts), CI pipeline patterns, programmatic API examples, and the Decider pattern architecture diagram use the `ReferenceDocConfig.preamble` mechanism. These are `SectionBlock[]` defined in the config entry, prepended before all generated content. Preamble content is manually authored and changes at editorial cadence, not code cadence. | Integration recipes (Husky hook setup, CI YAML patterns, API usage examples) are not extractable from source annotations because they describe how external systems consume Process Guard, not how Process Guard is implemented. The preamble mechanism exists precisely for this: editorial prose that lives in the config, not in a separate manual file, and appears in the generated output. | +| Convention tags source error context from annotated lint code | Error-handling code in `src/lint/process-guard/` is annotated with `@architect-convention:process-guard-errors` using structured JSDoc that includes rationale, alternative approaches, and common mistake patterns. The convention tag value `process-guard-errors` is registered in `src/taxonomy/conventions.ts` in the `CONVENTION_VALUES` array. The `createReferenceCodec` factory extracts this content via the existing convention extractor pipeline. | Convention-tagged annotations on the error-handling code co-locate rationale with implementation. When a developer changes an error rule in the decider, the convention JSDoc is right there -- they update both in the same commit. This is the same pattern used by `codec-registry`, `pipeline-architecture`, and `taxonomy-rules` convention tags, all proven by CodecDrivenReferenceGeneration. | ### Extract Summary @@ -836,20 +836,20 @@ function transformToMasterDataset(raw: RawDataset): RuntimeMasterDataset; ### Prd Implementation Section -| Rule | Invariant | Rationale | -| --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| PRD generator discovers implementations from relationship index | When generating PRD for pattern X, the generator queries the relationship index for all files where `implements === X`. No explicit listing in the spec file is required. | The `@libar-docs-implements` tag creates a backward link from code to spec. The relationship index aggregates these. PRD generation simply queries the index rather than scanning directories. | -| Implementation metadata appears in dedicated PRD section | The PRD output includes a "## Implementations" section listing all files that implement the pattern. Each file shows its `uses`, `usedBy`, and `usecase` metadata in a consistent format. | Developers reading PRDs benefit from seeing the implementation landscape alongside requirements, without cross-referencing code files. | -| Patterns without implementations render cleanly | If no files have `@libar-docs-implements:X` for pattern X, the "## Implementations" section is omitted (not rendered as empty). | Planned patterns may not have implementations yet. Empty sections add noise without value. | +| Rule | Invariant | Rationale | +| --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| PRD generator discovers implementations from relationship index | When generating PRD for pattern X, the generator queries the relationship index for all files where `implements === X`. No explicit listing in the spec file is required. | The `@architect-implements` tag creates a backward link from code to spec. The relationship index aggregates these. PRD generation simply queries the index rather than scanning directories. | +| Implementation metadata appears in dedicated PRD section | The PRD output includes a "## Implementations" section listing all files that implement the pattern. Each file shows its `uses`, `usedBy`, and `usecase` metadata in a consistent format. | Developers reading PRDs benefit from seeing the implementation landscape alongside requirements, without cross-referencing code files. | +| Patterns without implementations render cleanly | If no files have `@architect-implements:X` for pattern X, the "## Implementations" section is omitted (not rendered as empty). | Planned patterns may not have implementations yet. Empty sections add noise without value. | ### Prd Implementation Section Testing -| Rule | Invariant | Rationale | -| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Implementation files appear in pattern docs via @libar-docs-implements | Any TypeScript file with a matching @libar-docs-implements tag must appear in the pattern document's Implementations section with a working file link. | Implementation discovery relies on tag-based linking — missing entries break traceability between specs and code. | -| Multiple implementations are listed alphabetically | When multiple files implement the same pattern, they must be listed in ascending file path order. | Deterministic ordering ensures stable document output across regeneration runs. | -| Patterns without implementations omit the section | The Implementations heading must not appear in pattern documents when no implementing files exist. | Rendering an empty Implementations section misleads readers into thinking implementations were expected but are missing, rather than simply not applicable. | -| Implementation references use relative file links | Implementation file links must be relative paths starting from the patterns output directory. | Absolute paths break when documentation is viewed from different locations; relative paths ensure portability. | +| Rule | Invariant | Rationale | +| --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Implementation files appear in pattern docs via @architect-implements | Any TypeScript file with a matching @architect-implements tag must appear in the pattern document's Implementations section with a working file link. | Implementation discovery relies on tag-based linking — missing entries break traceability between specs and code. | +| Multiple implementations are listed alphabetically | When multiple files implement the same pattern, they must be listed in ascending file path order. | Deterministic ordering ensures stable document output across regeneration runs. | +| Patterns without implementations omit the section | The Implementations heading must not appear in pattern documents when no implementing files exist. | Rendering an empty Implementations section misleads readers into thinking implementations were expected but are missing, rather than simply not applicable. | +| Implementation references use relative file links | Implementation file links must be relative paths starting from the patterns output directory. | Absolute paths break when documentation is viewed from different locations; relative paths ensure portability. | ### Procedural Guide Codec @@ -880,11 +880,11 @@ function transformToMasterDataset(raw: RawDataset): RuntimeMasterDataset; ### Readme Rationalization -| Rule | Invariant | Rationale | -| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| README must be an npm package landing page | README.md content is scoped to what an npm package consumer needs: title and badges, one-paragraph value proposition, install instructions, quick start (annotate, generate, enforce), one annotated code example, content block summary table, CLI command table, and documentation index. | npm package pages are scanned by developers evaluating installation decisions. Content above 150-200 lines increases time-to-value. Enterprise pitch content (benchmark tables, methodology comparisons, session workflows, relationship models, comparison matrices) is not actionable at install time and belongs on the project website where it receives proper formatting, navigation, and updates without coupling to the package release cycle. The libar.dev website already contains 9 landing page components covering all enterprise pitch content: Metrics.astro (Proven at Scale), Pillars.astro (FSM, dual-source, relationships, codecs), DataAPI.astro (Data API CLI), Workflows.astro (session types), CodeExamples.astro (annotation examples), and Pipeline.astro (four-stage pipeline). | -| Configuration reference must not be duplicated in README | docs/CONFIGURATION.md is the single source of truth for preset and tag configuration. | README.md lines 441-474 reproduce the exact same preset table and config code examples that appear in docs/CONFIGURATION.md. Duplicate reference content diverges over time -- when a new preset is added, both files require updates. Removing the README copy and pointing to CONFIGURATION.md eliminates the divergence risk and removes approximately 34 lines from the README with no loss of information. | -| Trimmed README must serve as an effective getting-started page | The website publishes README.md as /delivery-process/getting-started/ via content-manifest.mjs (line 57). After trimming, the remaining content must serve a first-time visitor arriving at that URL: install instructions, a quick annotated code example, CLI commands to run, and navigation links to deeper documentation. | The current 504-line README is a poor getting-started page because the install command is buried after 50+ lines of marketing content. The trimmed 150-line version places install instructions within the first 20 lines and follows with practical steps -- this is a better getting-started experience than the current version. No manifest changes are needed; the trim improves alignment with the URL. | +| Rule | Invariant | Rationale | +| -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| README must be an npm package landing page | README.md content is scoped to what an npm package consumer needs: title and badges, one-paragraph value proposition, install instructions, quick start (annotate, generate, enforce), one annotated code example, content block summary table, CLI command table, and documentation index. | npm package pages are scanned by developers evaluating installation decisions. Content above 150-200 lines increases time-to-value. Enterprise pitch content (benchmark tables, methodology comparisons, session workflows, relationship models, comparison matrices) is not actionable at install time and belongs on the project website where it receives proper formatting, navigation, and updates without coupling to the package release cycle. The libar.dev website already contains 9 landing page components covering all enterprise pitch content: Metrics.astro (Proven at Scale), Pillars.astro (FSM, dual-source, relationships, codecs), DataAPI.astro (Data API CLI), Workflows.astro (session types), CodeExamples.astro (annotation examples), and Pipeline.astro (four-stage pipeline). | +| Configuration reference must not be duplicated in README | docs/CONFIGURATION.md is the single source of truth for preset and tag configuration. | README.md lines 441-474 reproduce the exact same preset table and config code examples that appear in docs/CONFIGURATION.md. Duplicate reference content diverges over time -- when a new preset is added, both files require updates. Removing the README copy and pointing to CONFIGURATION.md eliminates the divergence risk and removes approximately 34 lines from the README with no loss of information. | +| Trimmed README must serve as an effective getting-started page | The website publishes README.md as /architect/getting-started/ via content-manifest.mjs (line 57). After trimming, the remaining content must serve a first-time visitor arriving at that URL: install instructions, a quick annotated code example, CLI commands to run, and navigation links to deeper documentation. | The current 504-line README is a poor getting-started page because the install command is buried after 50+ lines of marketing content. The trimmed 150-line version places install instructions within the first 20 lines and follows with practical steps -- this is a better getting-started experience than the current version. No manifest changes are needed; the trim improves alignment with the URL. | ### Reference Codec Core Testing @@ -1049,17 +1049,17 @@ function transformToMasterDataset(raw: RawDataset): RuntimeMasterDataset; ### Session Guides Module Source -| Rule | Invariant | Rationale | -| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| SESSION-GUIDES.md is the authoritative public human reference | `docs/SESSION-GUIDES.md` exists and is not deleted, shortened, or replaced with a redirect. Its comprehensive checklists, CLI command examples, and session decision trees serve developers on libar.dev. | Session workflow guidance requires two formats for two audiences. Public developers need comprehensive checklists with full examples. AI sessions need compact invariants they can apply without reading 389 lines. | -| CLAUDE.md session workflow content is derived, not hand-authored | After Phase 39 generation deliverables complete, the "Session Workflows" section in CLAUDE.md contains no manually-authored content. It is composed from generated `_claude-md/workflow/` modules. | A hand-maintained CLAUDE.md session section creates two copies of session workflow guidance with no synchronization mechanism. Regeneration from annotated source eliminates drift. | -| Session type determines artifacts and FSM changes | Four session types exist, each with defined input, output, and FSM impact. Mixing outputs across session types (e.g., writing code in a planning session) violates session discipline. | Session type confusion causes wasted work — a design mistake discovered mid-implementation wastes the entire session. Clear contracts prevent scope bleeding between session types. | -| Planning sessions produce roadmap specs only | A planning session creates a roadmap spec with metadata, deliverables table, Rule: blocks with invariants, and scenarios. It must not produce implementation code, transition to active, or prompt for implementation readiness. | Planning is the cheapest session type — it produces .feature file edits, no compilation needed. Mixing implementation into planning defeats the cost advantage and introduces untested code without a locked scope. | -| Design sessions produce decisions and stubs only | A design session makes architectural decisions and creates code stubs with interfaces. It must not produce implementation code. Context gathering via the Process Data API must precede any explore agent usage. | Design sessions resolve ambiguity before implementation begins. Code stubs in delivery-process/stubs/ live outside src/ to avoid TypeScript compilation and ESLint issues, making them zero-risk artifacts. | -| Implementation sessions follow FSM-enforced execution order | Implementation sessions must follow a strict 5-step execution order. Transition to active must happen before any code changes. Transition to completed must happen only when ALL deliverables are done. Skipping steps causes Process Guard rejection at commit time. | The execution order ensures FSM state accurately reflects work state at every point. Writing code before transitioning to active means Process Guard sees changes to a roadmap spec (no scope protection). Marking completed with incomplete work creates a hard-locked state that requires unlock-reason to fix. | -| FSM errors have documented fixes | Every Process Guard error code has a defined cause and fix. The error codes, causes, and fixes form a closed set — no undocumented error states exist. | Undocumented FSM errors cause session-blocking confusion. A lookup table from error code to fix eliminates guesswork and prevents workarounds that bypass process integrity. | -| Handoff captures session-end state for continuity | Multi-session work requires handoff documentation generated from the Process Data API. Handoff output always reflects actual annotation state, not manual notes. | Manual session notes drift from actual deliverable state. The handoff command derives state from annotations, ensuring the next session starts from ground truth rather than stale notes. | -| ClaudeModuleGeneration is the generation mechanism | Phase 39 depends on ClaudeModuleGeneration (Phase 25). Adding `@libar-docs-claude-module` and `@libar-docs-claude-section:workflow` tags to this spec will cause ClaudeModuleGeneration to produce `_claude-md/workflow/` output files. The hand-written `_claude-md/workflow/` files are deleted after successful verified generation. | The annotation work (Rule blocks in this spec) is immediately useful — queryable via `pnpm process:query -- rules`. Generation deliverables cannot complete until Phase 25 ships the ClaudeModuleCodec. This sequencing is intentional: the annotation investment has standalone value regardless of whether the codec exists yet. | +| Rule | Invariant | Rationale | +| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| SESSION-GUIDES.md is the authoritative public human reference | `docs/SESSION-GUIDES.md` exists and is not deleted, shortened, or replaced with a redirect. Its comprehensive checklists, CLI command examples, and session decision trees serve developers on libar.dev. | Session workflow guidance requires two formats for two audiences. Public developers need comprehensive checklists with full examples. AI sessions need compact invariants they can apply without reading 389 lines. | +| CLAUDE.md session workflow content is derived, not hand-authored | After Phase 39 generation deliverables complete, the "Session Workflows" section in CLAUDE.md contains no manually-authored content. It is composed from generated `_claude-md/workflow/` modules. | A hand-maintained CLAUDE.md session section creates two copies of session workflow guidance with no synchronization mechanism. Regeneration from annotated source eliminates drift. | +| Session type determines artifacts and FSM changes | Four session types exist, each with defined input, output, and FSM impact. Mixing outputs across session types (e.g., writing code in a planning session) violates session discipline. | Session type confusion causes wasted work — a design mistake discovered mid-implementation wastes the entire session. Clear contracts prevent scope bleeding between session types. | +| Planning sessions produce roadmap specs only | A planning session creates a roadmap spec with metadata, deliverables table, Rule: blocks with invariants, and scenarios. It must not produce implementation code, transition to active, or prompt for implementation readiness. | Planning is the cheapest session type — it produces .feature file edits, no compilation needed. Mixing implementation into planning defeats the cost advantage and introduces untested code without a locked scope. | +| Design sessions produce decisions and stubs only | A design session makes architectural decisions and creates code stubs with interfaces. It must not produce implementation code. Context gathering via the Process Data API must precede any explore agent usage. | Design sessions resolve ambiguity before implementation begins. Code stubs in architect/stubs/ live outside src/ to avoid TypeScript compilation and ESLint issues, making them zero-risk artifacts. | +| Implementation sessions follow FSM-enforced execution order | Implementation sessions must follow a strict 5-step execution order. Transition to active must happen before any code changes. Transition to completed must happen only when ALL deliverables are done. Skipping steps causes Process Guard rejection at commit time. | The execution order ensures FSM state accurately reflects work state at every point. Writing code before transitioning to active means Process Guard sees changes to a roadmap spec (no scope protection). Marking completed with incomplete work creates a hard-locked state that requires unlock-reason to fix. | +| FSM errors have documented fixes | Every Process Guard error code has a defined cause and fix. The error codes, causes, and fixes form a closed set — no undocumented error states exist. | Undocumented FSM errors cause session-blocking confusion. A lookup table from error code to fix eliminates guesswork and prevents workarounds that bypass process integrity. | +| Handoff captures session-end state for continuity | Multi-session work requires handoff documentation generated from the Process Data API. Handoff output always reflects actual annotation state, not manual notes. | Manual session notes drift from actual deliverable state. The handoff command derives state from annotations, ensuring the next session starts from ground truth rather than stale notes. | +| ClaudeModuleGeneration is the generation mechanism | Phase 39 depends on ClaudeModuleGeneration (Phase 25). Adding `@architect-claude-module` and `@architect-claude-section:workflow` tags to this spec will cause ClaudeModuleGeneration to produce `_claude-md/workflow/` output files. The hand-written `_claude-md/workflow/` files are deleted after successful verified generation. | The annotation work (Rule blocks in this spec) is immediately useful — queryable via `pnpm architect:query -- rules`. Generation deliverables cannot complete until Phase 25 ships the ClaudeModuleCodec. This sequencing is intentional: the annotation investment has standalone value regardless of whether the codec exists yet. | ### Shape Matcher Testing @@ -1138,7 +1138,7 @@ function transformToMasterDataset(raw: RawDataset): RuntimeMasterDataset; | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Cross-references Verified by annotations against actual scenarios | Every `verifiedBy` string extracted from a Rule description is matched against scenario names in the MasterDataset. The traceability matrix shows each Rule with its verification status: verified (all references resolve), partially verified (some resolve), or unverified (none resolve or no annotation). | `parseBusinessRuleAnnotations()` already extracts `verifiedBy` arrays from Rule descriptions. Without cross-referencing against actual scenario names, the traceability report cannot distinguish between claimed and actual test coverage. A dangling reference (scenario name that does not exist) is worse than no annotation because it creates false confidence. | | Detects orphan scenarios and unverified rules | Orphan scenarios (acceptance-criteria scenarios not referenced by any Rule's Verified by annotation) and unverified rules (Rules without a Verified by annotation or with zero matched scenarios) are listed in dedicated sections of the traceability output. | Coverage gaps indicate either missing traceability annotations or actual missing test coverage. Orphan scenarios may be valuable tests that lack traceability links, or dead tests that should be removed. Unverified rules are business constraints with no demonstrated test coverage. | -| Traceability output is wired into the docs pipeline | The TraceabilityCodec output is generated as part of `pnpm docs:all` via a `docs:traceability` npm script backed by a ReferenceDocConfig entry in `delivery-process.config.ts`. The output file lands in `docs-live/TRACEABILITY.md`. | The TraceabilityCodec is registered in the CodecRegistry but not wired into `delivery-process.config.ts` or `package.json`. Without config wiring, the codec is only usable programmatically or via tests. Adding it to the docs pipeline makes traceability output a first-class generated artifact alongside CHANGELOG.md, OVERVIEW.md, and other reporting codecs. | +| Traceability output is wired into the docs pipeline | The TraceabilityCodec output is generated as part of `pnpm docs:all` via a `docs:traceability` npm script backed by a ReferenceDocConfig entry in `architect.config.ts`. The output file lands in `docs-live/TRACEABILITY.md`. | The TraceabilityCodec is registered in the CodecRegistry but not wired into `architect.config.ts` or `package.json`. Without config wiring, the codec is only usable programmatically or via tests. Adding it to the docs pipeline makes traceability output a first-class generated artifact alongside CHANGELOG.md, OVERVIEW.md, and other reporting codecs. | ### Transform Dataset Testing diff --git a/docs-live/product-areas/PROCESS.md b/docs-live/product-areas/PROCESS.md index 3b54cb68..b7f0a9f2 100644 --- a/docs-live/product-areas/PROCESS.md +++ b/docs-live/product-areas/PROCESS.md @@ -9,7 +9,7 @@ ## Key Invariants -- TypeScript source owns pattern identity: `@libar-docs-pattern` in TypeScript defines the pattern. Tier 1 specs are ephemeral working documents +- TypeScript source owns pattern identity: `@architect-pattern` in TypeScript defines the pattern. Tier 1 specs are ephemeral working documents - 7 canonical product-area values: Annotation, Configuration, Generation, Validation, DataAPI, CoreTypes, Process — reader-facing sections, not source modules - Two distinct status domains: Pattern FSM status (4 values) vs. deliverable status (6 values). Never cross domains - Session types define capabilities: planning creates specs, design creates stubs, implementation writes code. Each session type has a fixed input/output contract enforced by convention @@ -105,7 +105,7 @@ **Verified by:** Canonical values are enforced Completed is a terminal state. Modifications require - `@libar-docs-unlock-reason` escape hatch. + `@architect-unlock-reason` escape hatch. --- @@ -115,14 +115,14 @@ **Rationale:** Without explicit format types, parsers must guess value structure, leading to silent data corruption when CSV values are treated as single strings or numbers are treated as text. -| Format | Parsing | Example | -| ------------ | ------------------------------ | ------------------------------ | -| flag | Boolean presence, no value | @libar-docs-core | -| value | Simple string | @libar-docs-pattern MyPattern | -| enum | Constrained to predefined list | @libar-docs-status completed | -| csv | Comma-separated values | @libar-docs-uses A, B, C | -| number | Numeric value | @libar-docs-phase 15 | -| quoted-value | Preserves spaces | @libar-docs-brief:'Multi word' | +| Format | Parsing | Example | +| ------------ | ------------------------------ | ----------------------------- | +| flag | Boolean presence, no value | @architect-core | +| value | Simple string | @architect-pattern MyPattern | +| enum | Constrained to predefined list | @architect-status completed | +| csv | Comma-separated values | @architect-uses A, B, C | +| number | Numeric value | @architect-phase 15 | +| quoted-value | Preserves spaces | @architect-brief:'Multi word' | **Verified by:** Canonical values are enforced @@ -289,14 +289,14 @@ graph LR ### ADR 003 Source First Pattern Architecture -| Rule | Invariant | Rationale | -| -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| TypeScript source owns pattern identity | A pattern is defined by `@libar-docs-pattern` in a TypeScript file — either a stub (pre-implementation) or source code (post-implementation). | If pattern identity lives in tier 1 specs, it becomes stale after implementation and diverges from the code that actually realizes the pattern. | -| 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) | `@libar-docs-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 | `@libar-docs-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. | -| Reverse links preferred over forward links | `@libar-docs-implements` (reverse: "I verify this pattern") is the primary traceability mechanism. `@libar-docs-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. | +| Rule | Invariant | Rationale | +| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| TypeScript source owns pattern identity | A pattern is defined by `@architect-pattern` in a TypeScript file — either a stub (pre-implementation) or source code (post-implementation). | If pattern identity lives in tier 1 specs, it becomes stale after implementation and diverges from the code that actually realizes the pattern. | +| 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. | +| 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 diff --git a/docs-live/product-areas/VALIDATION.md b/docs-live/product-areas/VALIDATION.md index 21e18c61..8e4b6224 100644 --- a/docs-live/product-areas/VALIDATION.md +++ b/docs-live/product-areas/VALIDATION.md @@ -5,11 +5,11 @@ --- -**How is the workflow enforced?** Validation is the enforcement boundary — it ensures that every change to annotated source files respects the delivery lifecycle rules defined by the FSM, protection levels, and scope constraints. The system operates in three layers: the FSM validator checks status transitions against a 4-state directed graph, the Process Guard orchestrates commit-time validation using a Decider pattern (state derived from annotations, not stored separately), and the lint engine provides pluggable rule execution with pretty and JSON output. Anti-pattern detection enforces dual-source ownership boundaries — `@libar-docs-uses` belongs on TypeScript, `@libar-docs-depends-on` belongs on Gherkin — preventing cross-domain tag confusion that causes documentation drift. Definition of Done validation ensures completed patterns have all deliverables marked done and at least one acceptance-criteria scenario. +**How is the workflow enforced?** Validation is the enforcement boundary — it ensures that every change to annotated source files respects the delivery lifecycle rules defined by the FSM, protection levels, and scope constraints. The system operates in three layers: the FSM validator checks status transitions against a 4-state directed graph, the Process Guard orchestrates commit-time validation using a Decider pattern (state derived from annotations, not stored separately), and the lint engine provides pluggable rule execution with pretty and JSON output. Anti-pattern detection enforces dual-source ownership boundaries — `@architect-uses` belongs on TypeScript, `@architect-depends-on` belongs on Gherkin — preventing cross-domain tag confusion that causes documentation drift. Definition of Done validation ensures completed patterns have all deliverables marked done and at least one acceptance-criteria scenario. ## Key Invariants -- Protection levels: `roadmap`/`deferred` = none (fully editable), `active` = scope-locked (no new deliverables), `completed` = hard-locked (requires `@libar-docs-unlock-reason`) +- Protection levels: `roadmap`/`deferred` = none (fully editable), `active` = scope-locked (no new deliverables), `completed` = hard-locked (requires `@architect-unlock-reason`) - Valid FSM transitions: Only roadmap→active, roadmap→deferred, active→completed, active→roadmap, deferred→roadmap. Completed is terminal - Decider pattern: All validation is (state, changes, options) → result. State is derived from annotations, not maintained separately - Dual-source ownership: Anti-pattern detection enforces tag boundaries — `uses` on TypeScript (runtime deps), `depends-on`/`quarter`/`team` on Gherkin (planning metadata). Violations are flagged before they cause documentation drift @@ -407,7 +407,7 @@ function formatDoDSummary(summary: DoDValidationSummary): string; * * @example * ```typescript - * // With default prefix (@libar-docs-) + * // With default prefix (@architect-) * const violations = detectAntiPatterns(tsFiles, featureFiles); * * // With custom prefix @@ -448,7 +448,7 @@ function detectAntiPatterns( * in TypeScript files. Process metadata belongs in feature files. * * @param scannedFiles - Array of scanned TypeScript files - * @param registry - Optional tag registry for prefix-aware detection (defaults to @libar-docs-) + * @param registry - Optional tag registry for prefix-aware detection (defaults to @architect-) * @returns Array of anti-pattern violations */ ``` @@ -460,10 +460,10 @@ function detectProcessInCode( ): AntiPatternViolation[]; ``` -| Parameter | Type | Description | -| ------------ | ---- | --------------------------------------------------------------------------- | -| scannedFiles | | Array of scanned TypeScript files | -| registry | | Optional tag registry for prefix-aware detection (defaults to @libar-docs-) | +| Parameter | Type | Description | +| ------------ | ---- | -------------------------------------------------------------------------- | +| scannedFiles | | Array of scanned TypeScript files | +| registry | | Optional tag registry for prefix-aware detection (defaults to @architect-) | **Returns:** Array of anti-pattern violations @@ -916,14 +916,14 @@ const missingStatus: LintRule; ### Anti Pattern Detector Testing -| Rule | Invariant | Rationale | -| ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Process metadata should not appear in TypeScript code | Process metadata tags (@libar-docs-status, @libar-docs-phase, etc.) must only appear in Gherkin feature files, never in TypeScript source code. | TypeScript owns runtime behavior while Gherkin owns delivery process metadata — mixing them creates dual-source conflicts and validation ambiguity. | -| Generator hints should not appear in feature files | Feature files must not contain generator magic comments beyond a configurable threshold. | Generator hints are implementation details that belong in TypeScript — excessive magic comments in specs indicate leaking implementation concerns into business requirements. | -| Feature files should not have excessive scenarios | A single feature file must not exceed the configured maximum scenario count. | Oversized feature files indicate missing decomposition — they become hard to maintain and slow to execute. | -| Feature files should not exceed size thresholds | A single feature file must not exceed the configured maximum line count. | Excessively large files indicate a feature that should be split into focused, independently testable specifications. | -| All anti-patterns can be detected in one pass | The anti-pattern detector must evaluate all registered rules in a single scan pass over the source files. | Single-pass detection ensures consistent results and avoids O(n\*m) performance degradation with multiple file traversals. | -| Violations can be formatted for console output | Anti-pattern violations must be renderable as grouped, human-readable console output. | Developers need actionable feedback at commit time — ungrouped or unformatted violations are hard to triage and fix. | +| Rule | Invariant | Rationale | +| ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Process metadata should not appear in TypeScript code | Process metadata tags (@architect-status, @architect-phase, etc.) must only appear in Gherkin feature files, never in TypeScript source code. | TypeScript owns runtime behavior while Gherkin owns delivery process metadata — mixing them creates dual-source conflicts and validation ambiguity. | +| Generator hints should not appear in feature files | Feature files must not contain generator magic comments beyond a configurable threshold. | Generator hints are implementation details that belong in TypeScript — excessive magic comments in specs indicate leaking implementation concerns into business requirements. | +| Feature files should not have excessive scenarios | A single feature file must not exceed the configured maximum scenario count. | Oversized feature files indicate missing decomposition — they become hard to maintain and slow to execute. | +| Feature files should not exceed size thresholds | A single feature file must not exceed the configured maximum line count. | Excessively large files indicate a feature that should be split into focused, independently testable specifications. | +| All anti-patterns can be detected in one pass | The anti-pattern detector must evaluate all registered rules in a single scan pass over the source files. | Single-pass detection ensures consistent results and avoids O(n\*m) performance degradation with multiple file traversals. | +| Violations can be formatted for console output | Anti-pattern violations must be renderable as grouped, human-readable console output. | Developers need actionable feedback at commit time — ungrouped or unformatted violations are hard to triage and fix. | ### Codec Utils Validation @@ -1029,19 +1029,19 @@ const missingStatus: LintRule; | Rule | Invariant | Rationale | | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | -| Protection levels determine modification restrictions | Every file's modification restrictions are determined solely by its `@libar-docs-status` tag, with `completed` requiring an explicit unlock reason for any change. | Without status-derived protection, completed and approved work can be silently overwritten by bulk edits or accidental modifications. | +| Protection levels determine modification restrictions | Every file's modification restrictions are determined solely by its `@architect-status` tag, with `completed` requiring an explicit unlock reason for any change. | Without status-derived protection, completed and approved work can be silently overwritten by bulk edits or accidental modifications. | | Session definition files scope what can be modified | When an active session exists, only specs explicitly listed in the session definition may be modified without warning, and excluded specs cannot be modified at all. | Without session scoping, bulk operations and context switches cause unintended modifications to specs outside the current work focus. | | Status transitions follow PDR-005 FSM | Every status change must follow a valid edge in the PDR-005 finite state machine; no transition may skip intermediate states. | Skipping states (e.g., `roadmap` directly to `completed`) bypasses scope-locking and review gates, allowing incomplete work to be marked as done. | | Active specs cannot add new deliverables | The deliverables table of an `active` spec is immutable with respect to new rows; only existing deliverable statuses may change. | Adding deliverables after work has begun constitutes scope creep, undermining effort estimates and blocking completion. | | CLI provides flexible validation modes | The CLI must support both pre-commit (staged-only) and CI (all-files) validation modes with deterministic exit codes reflecting violation severity. | Without flexible modes, teams cannot integrate process guard into both local developer workflows and CI pipelines with appropriate strictness levels. | -| Integrates with existing lint infrastructure | Process guard output format and exit code semantics must be consistent with the existing `lint-patterns` tool. | Inconsistent output formats force consumers to maintain separate parsers, and inconsistent exit codes break combined lint pipelines. | +| Integrates with existing lint infrastructure | Process guard output format and exit code semantics must be consistent with the existing `architect-lint-patterns` tool. | Inconsistent output formats force consumers to maintain separate parsers, and inconsistent exit codes break combined lint pipelines. | | New tags support process guard functionality | Session and protection tags must be registered in the TypeScript taxonomy with defined formats before use in feature files. | Unregistered tags bypass schema validation and are silently ignored by the scanner, causing process guard rules to fail without diagnostics. | ### Process Guard Testing | Rule | Invariant | Rationale | | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | -| Completed files require unlock-reason to modify | A completed spec file cannot be modified unless it carries an @libar-docs-unlock-reason tag. | Completed work represents validated, shipped functionality — accidental modification risks regression. | +| Completed files require unlock-reason to modify | A completed spec file cannot be modified unless it carries an @architect-unlock-reason tag. | Completed work represents validated, shipped functionality — accidental modification risks regression. | | Status transitions must follow PDR-005 FSM | Status changes must follow the directed graph: roadmap->active->completed, roadmap<->deferred, active->roadmap. | The FSM prevents skipping required stages (e.g., roadmap->completed bypasses implementation). | | Active specs cannot add new deliverables | A spec in active status cannot have deliverables added that were not present when it entered active. | Scope-locking active work prevents mid-sprint scope creep that derails delivery commitments. | | Files outside active session scope trigger warnings | Files modified outside the active session's declared scope produce a session-scope warning. | Session scoping keeps focus on planned work and makes accidental cross-cutting changes visible. | @@ -1050,28 +1050,28 @@ const missingStatus: LintRule; ### Release Association Rules -| Rule | Invariant | Rationale | -| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | -| Spec files must not contain release columns | Spec file DataTables must never include a Release column; release metadata belongs exclusively in phase files. | Mixing release metadata into specs couples planning artifacts to release timing, violating the separation defined by PDR-003. | -| TypeScript phase files must have required annotations | Every TypeScript phase file must include @libar-docs-pattern, @libar-docs-phase, and @libar-docs-status annotations. | Missing required annotations cause phase files to be invisible to the scanner, producing incomplete roadmap projections and broken cross-references. | -| Release version follows semantic versioning | All release version identifiers must conform to the `vX.Y.Z` semantic versioning format. | Non-semver version strings break downstream tooling that relies on version ordering and comparison for release planning. | +| Rule | Invariant | Rationale | +| ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | +| Spec files must not contain release columns | Spec file DataTables must never include a Release column; release metadata belongs exclusively in phase files. | Mixing release metadata into specs couples planning artifacts to release timing, violating the separation defined by PDR-003. | +| TypeScript phase files must have required annotations | Every TypeScript phase file must include @architect-pattern, @architect-phase, and @architect-status annotations. | Missing required annotations cause phase files to be invisible to the scanner, producing incomplete roadmap projections and broken cross-references. | +| Release version follows semantic versioning | All release version identifiers must conform to the `vX.Y.Z` semantic versioning format. | Non-semver version strings break downstream tooling that relies on version ordering and comparison for release planning. | ### Status Aware Eslint Suppression -| Rule | Invariant | Rationale | -| ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| File status determines unused-vars enforcement | Files with `@libar-docs-status roadmap` or `deferred` have relaxed unused-vars rules. Files with `active`, `completed`, or no status have strict enforcement. | Design artifacts (roadmap stubs) define API shapes that are intentionally unused until implementation. Relaxing rules for these files prevents false positives while ensuring implemented code (active/completed) remains strictly checked. | -| Reuses deriveProcessState for status extraction | Status extraction logic must be shared with Process Guard Linter. No duplicate parsing or status-to-protection mapping. | DRY principle - the Process Guard already has battle-tested status extraction from JSDoc comments. Duplicating this logic creates maintenance burden and potential inconsistencies between tools. | -| ESLint Processor filters messages based on status | The processor uses ESLint's postprocess hook to filter or downgrade messages. Source code is never modified. No eslint-disable comments are injected. | ESLint processors can inspect and filter linting messages after rules run. This approach: - Requires no source code modification - Works with any ESLint rule (not just no-unused-vars) - Can be extended to other status-based behaviors | -| CLI can generate static ESLint ignore list | Running `pnpm lint:process --eslint-ignores` outputs a list of files that should have relaxed linting, suitable for inclusion in eslint.config.js. | For CI environments or users preferring static configuration, a generated list provides an alternative to runtime processing. The list can be regenerated whenever status annotations change. | -| Replaces directory-based ESLint exclusions | After implementation, the directory-based exclusions in eslint.config.js (lines 30-57) are removed. All suppression is driven by @libar-docs-status annotations. | Directory-based exclusions are tech debt: - They don't account for file lifecycle (roadmap -> completed) - They require manual updates when new roadmap directories are added - They persist even after files are implemented | -| Rule relaxation is configurable | The set of rules relaxed for roadmap/deferred files is configurable, defaulting to `@typescript-eslint/no-unused-vars`. | Different projects may want to relax different rules for design artifacts. The default covers the common case (unused exports in API stubs). | +| Rule | Invariant | Rationale | +| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| File status determines unused-vars enforcement | Files with `@architect-status roadmap` or `deferred` have relaxed unused-vars rules. Files with `active`, `completed`, or no status have strict enforcement. | Design artifacts (roadmap stubs) define API shapes that are intentionally unused until implementation. Relaxing rules for these files prevents false positives while ensuring implemented code (active/completed) remains strictly checked. | +| Reuses deriveProcessState for status extraction | Status extraction logic must be shared with Process Guard Linter. No duplicate parsing or status-to-protection mapping. | DRY principle - the Process Guard already has battle-tested status extraction from JSDoc comments. Duplicating this logic creates maintenance burden and potential inconsistencies between tools. | +| ESLint Processor filters messages based on status | The processor uses ESLint's postprocess hook to filter or downgrade messages. Source code is never modified. No eslint-disable comments are injected. | ESLint processors can inspect and filter linting messages after rules run. This approach: - Requires no source code modification - Works with any ESLint rule (not just no-unused-vars) - Can be extended to other status-based behaviors | +| CLI can generate static ESLint ignore list | Running `pnpm architect:guard --eslint-ignores` outputs a list of files that should have relaxed linting, suitable for inclusion in eslint.config.js. | For CI environments or users preferring static configuration, a generated list provides an alternative to runtime processing. The list can be regenerated whenever status annotations change. | +| Replaces directory-based ESLint exclusions | After implementation, the directory-based exclusions in eslint.config.js (lines 30-57) are removed. All suppression is driven by @architect-status annotations. | Directory-based exclusions are tech debt: - They don't account for file lifecycle (roadmap -> completed) - They require manual updates when new roadmap directories are added - They persist even after files are implemented | +| Rule relaxation is configurable | The set of rules relaxed for roadmap/deferred files is configurable, defaulting to `@typescript-eslint/no-unused-vars`. | Different projects may want to relax different rules for design artifacts. The default covers the common case (unused exports in API stubs). | ### Status Transition Detection Testing | Rule | Invariant | Rationale | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Status transitions are detected from file-level tags | Status transitions must be detected by comparing @libar-docs-status tags at the file level between the old and new versions of a file. | File-level tags are the canonical source of pattern status — detecting transitions from tags ensures consistency with the FSM validator. | +| Status transitions are detected from file-level tags | Status transitions must be detected by comparing @architect-status tags at the file level between the old and new versions of a file. | File-level tags are the canonical source of pattern status — detecting transitions from tags ensures consistency with the FSM validator. | | Status tags inside docstrings are ignored | Status tags appearing inside Gherkin docstring blocks (between triple-quote delimiters) must not be treated as real status declarations. | Docstrings often contain example code or documentation showing status tags — parsing these as real would cause phantom status transitions. | | First valid status tag outside docstrings is used | When multiple status tags appear outside docstrings, only the first one determines the file's status. | A single canonical status per file prevents ambiguity — using the first tag matches Gherkin convention where file-level tags appear at the top. | | Line numbers are tracked from hunk headers | Detected status transitions must include the line number where the status tag appears, derived from git diff hunk headers. | Line numbers enable precise error reporting — developers need to know exactly where in the file the transition was detected. | @@ -1121,7 +1121,7 @@ const missingStatus: LintRule; | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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 `@libar-docs-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. | +| 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 diff --git a/docs-live/reference/ANNOTATION-REFERENCE.md b/docs-live/reference/ANNOTATION-REFERENCE.md index 8d63029e..3800ad00 100644 --- a/docs-live/reference/ANNOTATION-REFERENCE.md +++ b/docs-live/reference/ANNOTATION-REFERENCE.md @@ -7,7 +7,7 @@ ## Getting Started -Every file that participates in the annotation system must have a `@libar-docs` opt-in marker. Files without this marker are invisible to the scanner. +Every file that participates in the annotation system must have a `@architect` opt-in marker. Files without this marker are invisible to the scanner. ### File-Level Opt-In @@ -15,10 +15,10 @@ Every file that participates in the annotation system must have a `@libar-docs` ```typescript /** - * @libar-docs - * @libar-docs-pattern MyPattern - * @libar-docs-status roadmap - * @libar-docs-uses EventStore, CommandBus + * @architect + * @architect-pattern MyPattern + * @architect-status roadmap + * @architect-uses EventStore, CommandBus * * ## My Pattern - Description */ @@ -27,10 +27,10 @@ Every file that participates in the annotation system must have a `@libar-docs` **Gherkin** -- file-level tags before `Feature:`: ```gherkin -@libar-docs -@libar-docs-pattern:MyPattern -@libar-docs-status:roadmap -@libar-docs-phase:14 +@architect +@architect-pattern:MyPattern +@architect-status:roadmap +@architect-phase:14 Feature: My Pattern **Problem:** @@ -39,11 +39,11 @@ Feature: My Pattern ### Tag Prefix by Preset -| Preset | Prefix | Categories | Use Case | -| ------------------------- | -------------- | ---------- | ----------------------------- | -| `libar-generic` (default) | `@libar-docs-` | 3 | Simple projects | -| `ddd-es-cqrs` | `@libar-docs-` | 21 | DDD/Event Sourcing monorepos | -| `generic` | `@docs-` | 3 | Simple projects, short prefix | +| Preset | Prefix | Categories | Use Case | +| ------------------------- | ------------- | ---------- | ----------------------------- | +| `libar-generic` (default) | `@architect-` | 3 | Simple projects | +| `ddd-es-cqrs` | `@architect-` | 21 | DDD/Event Sourcing monorepos | +| `generic` | `@docs-` | 3 | Simple projects, short prefix | ### Dual-Source Ownership @@ -64,8 +64,8 @@ List specific declaration names in the file-level JSDoc: ```typescript /** - * @libar-docs - * @libar-docs-extract-shapes MasterDatasetSchema, StatusGroupsSchema + * @architect + * @architect-extract-shapes MasterDatasetSchema, StatusGroupsSchema */ ``` @@ -75,8 +75,8 @@ Names appear in the generated output in the order listed. ```typescript /** - * @libar-docs - * @libar-docs-extract-shapes * + * @architect + * @architect-extract-shapes * */ ``` @@ -84,17 +84,17 @@ Wildcard must be the sole value -- `*, Foo` is invalid. ### Mode 3: Declaration-Level Tagging -Tag individual declarations with `@libar-docs-shape`, optionally with a group name: +Tag individual declarations with `@architect-shape`, optionally with a group name: ```typescript -/** @libar-docs-shape api-types */ +/** @architect-shape api-types */ export interface CommandInput { readonly aggregateId: string; readonly payload: unknown; } ``` -The optional group name (`api-types`) enables filtering in diagram scopes and product area documents via `@libar-docs-include`. +The optional group name (`api-types`) enables filtering in diagram scopes and product area documents via `@architect-include`. --- @@ -115,10 +115,10 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern MasterDataset - * @libar-docs-status completed - * @libar-docs-extract-shapes MasterDatasetSchema, StatusGroupsSchema, PhaseGroupSchema + * @architect + * @architect-pattern MasterDataset + * @architect-status completed + * @architect-extract-shapes MasterDatasetSchema, StatusGroupsSchema, PhaseGroupSchema */ ``` @@ -126,10 +126,10 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern DocumentGenerator - * @libar-docs-status completed - * @libar-docs-extract-shapes DocumentGenerator, GeneratorContext, GeneratorOutput + * @architect + * @architect-pattern DocumentGenerator + * @architect-status completed + * @architect-extract-shapes DocumentGenerator, GeneratorContext, GeneratorOutput */ ``` @@ -137,23 +137,23 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern TransformDataset - * @libar-docs-status completed - * @libar-docs-arch-context generator - * @libar-docs-arch-layer application - * @libar-docs-extract-shapes transformToMasterDataset, RuntimeMasterDataset + * @architect + * @architect-pattern TransformDataset + * @architect-status completed + * @architect-arch-context generator + * @architect-arch-layer application + * @architect-extract-shapes transformToMasterDataset, RuntimeMasterDataset */ ``` ### Gherkin Feature Files ```gherkin -@libar-docs -@libar-docs-pattern:ProcessGuardLinter -@libar-docs-status:roadmap -@libar-docs-phase:99 -@libar-docs-depends-on:StateMachine,ValidationRules +@architect +@architect-pattern:ProcessGuardLinter +@architect-status:roadmap +@architect-phase:99 +@architect-depends-on:StateMachine,ValidationRules Feature: Process Guard Linter Background: Deliverables @@ -202,16 +202,16 @@ Tags are organized into 12 functional groups. For the complete reference with al ```bash # Tag usage inventory (counts per tag and value) -pnpm process:query -- tags +pnpm architect:query -- tags -# Find files missing @libar-docs opt-in marker -pnpm process:query -- unannotated --path src/types +# Find files missing @architect opt-in marker +pnpm architect:query -- unannotated --path src/types # File inventory by type (TS, Gherkin, Stubs) -pnpm process:query -- sources +pnpm architect:query -- sources # Full pattern JSON including extractedShapes -pnpm process:query -- query getPattern MyPattern +pnpm architect:query -- query getPattern MyPattern # Generate complete tag reference npx generate-tag-taxonomy -o TAG_TAXONOMY.md -f @@ -221,13 +221,13 @@ npx generate-tag-taxonomy -o TAG_TAXONOMY.md -f ## Common Issues -| Symptom | Cause | Fix | -| ------------------------------- | ----------------------------------- | ------------------------------------------------ | -| Pattern not in scanner output | Missing `@libar-docs` opt-in marker | Add file-level `@libar-docs` JSDoc/tag | -| Shape shows `z.infer<>` wrapper | Extracted type alias, not schema | Use schema constant name (e.g., `FooSchema`) | -| Shape not in product area doc | Missing `@libar-docs-product-area` | Add product-area tag to file-level annotation | -| Declaration-level shape missing | No `@libar-docs-shape` on decl | Add `@libar-docs-shape` JSDoc to the declaration | -| Tag value rejected | Wrong format or invalid enum value | Check format type in taxonomy reference | -| Anti-pattern validation error | Tag on wrong source type | Move tag to correct source (TS vs Gherkin) | +| Symptom | Cause | Fix | +| ------------------------------- | ---------------------------------- | ----------------------------------------------- | +| Pattern not in scanner output | Missing `@architect` opt-in marker | Add file-level `@architect` JSDoc/tag | +| Shape shows `z.infer<>` wrapper | Extracted type alias, not schema | Use schema constant name (e.g., `FooSchema`) | +| Shape not in product area doc | Missing `@architect-product-area` | Add product-area tag to file-level annotation | +| Declaration-level shape missing | No `@architect-shape` on decl | Add `@architect-shape` JSDoc to the declaration | +| Tag value rejected | Wrong format or invalid enum value | Check format type in taxonomy reference | +| Anti-pattern validation error | Tag on wrong source type | Move tag to correct source (TS vs Gherkin) | --- diff --git a/docs-live/reference/ARCHITECTURE-CODECS.md b/docs-live/reference/ARCHITECTURE-CODECS.md index 64427915..e9218bcb 100644 --- a/docs-live/reference/ARCHITECTURE-CODECS.md +++ b/docs-live/reference/ARCHITECTURE-CODECS.md @@ -240,7 +240,7 @@ const doc = codec.decode(dataset); A single codec factory that creates reference document codecs from configuration objects. Convention content is sourced from -decision records tagged with @libar-docs-convention. +decision records tagged with @architect-convention. **Purpose:** Scoped reference documentation assembling four content layers (conventions, diagrams, shapes, behaviors) into a single document. @@ -248,7 +248,7 @@ decision records tagged with @libar-docs-convention. ### 4-Layer Composition (in order) -1. **Convention content** -- Extracted from `@libar-docs-convention`-tagged patterns (rules, invariants, tables) +1. **Convention content** -- Extracted from `@architect-convention`-tagged patterns (rules, invariants, tables) 2. **Scoped diagrams** -- Mermaid diagrams filtered by `archContext`, `archLayer`, `patterns`, or `include` tags 3. **TypeScript shapes** -- API surfaces from `shapeSources` globs or `shapeSelectors` (declaration-level filtering) 4. **Behavior content** -- Gherkin-sourced patterns from `behaviorCategories` @@ -463,7 +463,7 @@ and design question templates. **Purpose:** Auto-generate design review documents from sequence annotations on Gherkin specs. Diagrams stay synchronized with spec changes. -**Output Files:** `delivery-process/design-reviews/{pattern-name}.md` +**Output Files:** `architect/design-reviews/{pattern-name}.md` ### Factory Pattern @@ -640,9 +640,9 @@ const doc = ArchitectureDocumentCodec.decode(dataset); ## AdrDocumentCodec Transforms MasterDataset into RenderableDocument for Architecture Decision Records. -Extracts ADRs from patterns with `@libar-docs-adr` tags. +Extracts ADRs from patterns with `@architect-adr` tags. -**Purpose:** Architecture Decision Records extracted from patterns with @libar-docs-adr tags. +**Purpose:** Architecture Decision Records extracted from patterns with @architect-adr tags. **Output Files:** `DECISIONS.md` (ADR index), `decisions/.md` (category details) diff --git a/docs-live/reference/ARCHITECTURE-TYPES.md b/docs-live/reference/ARCHITECTURE-TYPES.md index 9dcb3217..d0332b05 100644 --- a/docs-live/reference/ARCHITECTURE-TYPES.md +++ b/docs-live/reference/ARCHITECTURE-TYPES.md @@ -211,16 +211,16 @@ SourceViewsSchema = z.object({ ```typescript RelationshipEntrySchema = z.object({ - /** Patterns this pattern uses (from @libar-docs-uses) */ + /** Patterns this pattern uses (from @architect-uses) */ uses: z.array(z.string()), - /** Patterns that use this pattern (from @libar-docs-used-by) */ + /** Patterns that use this pattern (from @architect-used-by) */ usedBy: z.array(z.string()), - /** Patterns this pattern depends on (from @libar-docs-depends-on) */ + /** Patterns this pattern depends on (from @architect-depends-on) */ dependsOn: z.array(z.string()), - /** Patterns this pattern enables (from @libar-docs-enables) */ + /** Patterns this pattern enables (from @architect-enables) */ enables: z.array(z.string()), // UML-inspired relationship fields (PatternRelationshipModel) @@ -236,10 +236,10 @@ RelationshipEntrySchema = z.object({ /** Patterns that extend this pattern (computed inverse) */ extendedBy: z.array(z.string()), - /** Related patterns for cross-reference without dependency (from @libar-docs-see-also tag) */ + /** Related patterns for cross-reference without dependency (from @architect-see-also tag) */ seeAlso: z.array(z.string()), - /** File paths to implementation APIs (from @libar-docs-api-ref tag) */ + /** File paths to implementation APIs (from @architect-api-ref tag) */ apiRef: z.array(z.string()), }); ``` @@ -403,7 +403,7 @@ and `transformToMasterDataset` with validation summary. ## Consumer Architecture and PipelineOptions Differentiation -Three consumers share this factory: `process-api`, `validate-patterns`, and the +Three consumers share this factory: `architect`, `architect-validate`, and the generation orchestrator. `PipelineOptions` differentiates behavior by `mergeConflictStrategy` (`fatal` vs `concatenate`), `includeValidation` toggles, and `failOnScanErrors` policy without forking pipeline logic. diff --git a/docs-live/reference/CONFIGURATION-GUIDE.md b/docs-live/reference/CONFIGURATION-GUIDE.md index c533fae5..80510908 100644 --- a/docs-live/reference/CONFIGURATION-GUIDE.md +++ b/docs-live/reference/CONFIGURATION-GUIDE.md @@ -7,15 +7,15 @@ ## Quick Reference -| Preset | Tag Prefix | Categories | Use Case | -| ----------------------------- | -------------- | ---------- | ------------------------------------ | -| **`libar-generic`** (default) | `@libar-docs-` | 3 | Simple projects (this package) | -| `generic` | `@docs-` | 3 | Simple projects with `@docs-` prefix | -| `ddd-es-cqrs` | `@libar-docs-` | 21 | DDD/Event Sourcing architectures | +| Preset | Tag Prefix | Categories | Use Case | +| ----------------------------- | ------------- | ---------- | ------------------------------------ | +| **`libar-generic`** (default) | `@architect-` | 3 | Simple projects (this package) | +| `generic` | `@docs-` | 3 | Simple projects with `@docs-` prefix | +| `ddd-es-cqrs` | `@architect-` | 21 | DDD/Event Sourcing architectures | ```typescript -// delivery-process.config.ts -import { defineConfig } from '@libar-dev/delivery-process/config'; +// architect.config.ts +import { defineConfig } from '@libar-dev/architect/config'; // Default: libar-generic preset (simple 3-category taxonomy) export default defineConfig({ @@ -36,7 +36,7 @@ export default defineConfig({ | Preset | Use When | Categories | | --------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------- | -| `libar-generic` | Simple projects, standard `@libar-docs-` prefix | 3 (core, api, infra) | +| `libar-generic` | Simple projects, standard `@architect-` prefix | 3 (core, api, infra) | | `generic` | Prefer shorter `@docs-` prefix | 3 (core, api, infra) | | `ddd-es-cqrs` | DDD architecture with bounded contexts, event sourcing, CQRS | 21 (domain, ddd, bounded-context, event-sourcing, decider, cqrs, saga, projection, etc.) | @@ -56,26 +56,26 @@ All entry points default to `libar-generic`: ## Unified Config File -The `defineConfig()` function centralizes taxonomy, sources, output, and generator overrides in a single `delivery-process.config.ts` file. CLI tools discover this file automatically. +The `defineConfig()` function centralizes taxonomy, sources, output, and generator overrides in a single `architect.config.ts` file. CLI tools discover this file automatically. ### Discovery Order -1. Current directory: check `delivery-process.config.ts`, then `.js` +1. Current directory: check `architect.config.ts`, then `.js` 2. Walk up to repo root (`.git` folder), checking each directory -3. Fall back to libar-generic preset (3 categories, `@libar-docs-` prefix) +3. Fall back to libar-generic preset (3 categories, `@architect-` prefix) ### Config File Format ```typescript -// delivery-process.config.ts -import { defineConfig } from '@libar-dev/delivery-process/config'; +// architect.config.ts +import { defineConfig } from '@libar-dev/architect/config'; export default defineConfig({ preset: 'libar-generic', sources: { typescript: ['src/**/*.ts'], - stubs: ['delivery-process/stubs/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + stubs: ['architect/stubs/**/*.ts'], + features: ['architect/specs/*.feature'], }, output: { directory: 'docs-generated', @@ -111,15 +111,15 @@ export default defineConfig({ preset: 'libar-generic', sources: { typescript: ['src/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + features: ['architect/specs/*.feature'], }, output: { directory: 'docs-generated', overwrite: true }, generatorOverrides: { changelog: { - additionalFeatures: ['delivery-process/decisions/*.feature'], + additionalFeatures: ['architect/decisions/*.feature'], }, 'doc-from-decision': { - replaceFeatures: ['delivery-process/decisions/*.feature'], + replaceFeatures: ['architect/decisions/*.feature'], }, }, }); @@ -138,7 +138,7 @@ export default defineConfig({ ## Monorepo Setup -```my-monorepo/ delivery-process.config.ts # Repo-level: ddd-es-cqrs packages/ my-package/ delivery-process.config.ts # Package-level: generic +```my-monorepo/ architect.config.ts # Repo-level: ddd-es-cqrs packages/ my-package/ architect.config.ts # Package-level: generic ``` @@ -202,7 +202,7 @@ export default defineConfig({ For tools that need to load configuration files: ```typescript -import { loadProjectConfig } from '@libar-dev/delivery-process/config'; +import { loadProjectConfig } from '@libar-dev/architect/config'; const result = await loadProjectConfig(process.cwd()); @@ -212,7 +212,7 @@ if (!result.ok) { } const resolved = result.value; -// resolved.instance - DeliveryProcessInstance (registry + regexBuilders) +// resolved.instance - ArchitectInstance (registry + regexBuilders) // resolved.project - ResolvedProjectConfig (sources, output, generators) // resolved.isDefault - true if no config file found // resolved.configPath - config file path (if found) @@ -221,7 +221,7 @@ const resolved = result.value; For per-generator source resolution: ```typescript -import { mergeSourcesForGenerator } from '@libar-dev/delivery-process/config'; +import { mergeSourcesForGenerator } from '@libar-dev/architect/config'; const effectiveSources = mergeSourcesForGenerator( resolved.project.sources, @@ -236,12 +236,12 @@ const effectiveSources = mergeSourcesForGenerator( ## Backward Compatibility -The legacy `createDeliveryProcess()` API is still exported and supported. Config files using the old format are detected automatically by `loadProjectConfig()` and wrapped in a `ResolvedConfig` with default project settings. +The legacy `createArchitect()` API is still exported and supported. Config files using the old format are detected automatically by `loadProjectConfig()` and wrapped in a `ResolvedConfig` with default project settings. ```typescript // Legacy format (still works) -import { createDeliveryProcess } from '@libar-dev/delivery-process'; -export default createDeliveryProcess({ preset: 'ddd-es-cqrs' }); +import { createArchitect } from '@libar-dev/architect'; +export default createArchitect({ preset: 'ddd-es-cqrs' }); ``` New projects should use `defineConfig()` for the unified configuration experience. diff --git a/docs-live/reference/GHERKIN-AUTHORING-GUIDE.md b/docs-live/reference/GHERKIN-AUTHORING-GUIDE.md index 75777ec1..58fedd8e 100644 --- a/docs-live/reference/GHERKIN-AUTHORING-GUIDE.md +++ b/docs-live/reference/GHERKIN-AUTHORING-GUIDE.md @@ -12,10 +12,10 @@ Roadmap specs define planned work with Problem/Solution descriptions and a Background deliverables table. ```gherkin -@libar-docs -@libar-docs-pattern:ProcessGuardLinter -@libar-docs-status:roadmap -@libar-docs-phase:99 +@architect +@architect-pattern:ProcessGuardLinter +@architect-status:roadmap +@architect-phase:99 Feature: Process Guard Linter **Problem:** @@ -39,9 +39,9 @@ Feature: Process Guard Linter **Key elements:** -- `@libar-docs` -- bare opt-in marker (required) -- `@libar-docs-pattern:Name` -- unique identifier (required) -- `@libar-docs-status:roadmap` -- FSM state +- `@architect` -- bare opt-in marker (required) +- `@architect-pattern:Name` -- unique identifier (required) +- `@architect-status:roadmap` -- FSM state - `**Problem:**` / `**Solution:**` -- extracted by generators - Background deliverables table -- tracks implementation progress @@ -109,7 +109,7 @@ Test features focus on behavior verification with section dividers for organizat ```gherkin @behavior @scanner-core -@libar-docs-pattern:ScannerCore +@architect-pattern:ScannerCore Feature: Scanner Core Integration Background: @@ -162,11 +162,11 @@ Use `"""typescript` for code blocks. Essential when content contains pipes or sp Scenario: Extract directive from TypeScript Given a file with content: """typescript - /** @libar-docs */ + /** @architect */ export function authenticate() {} """ When scanning the file - Then directive should have tag "@libar-docs-core" + Then directive should have tag "@architect-core" ``` --- @@ -214,7 +214,7 @@ Feature files serve dual purposes: **executable specs** and **documentation sour | DocStrings (`"""typescript`) | Brief examples (5-10 lines), current/target state comparison | | Code stub reference | Complex APIs, interfaces, full implementations | -Code stubs are annotated TypeScript files with `throw new Error("not yet implemented")`, located in `delivery-process/stubs/{pattern-name}/`. +Code stubs are annotated TypeScript files with `throw new Error("not yet implemented")`, located in `architect/stubs/{pattern-name}/`. ### Valid Rich Content @@ -244,15 +244,15 @@ Code stubs are annotated TypeScript files with `throw new Error("not yet impleme **Tag values cannot contain spaces.** Use hyphens: -| Invalid | Valid | -| -------------------------------- | ------------------------------- | -| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | -| `@libar-docs-pattern:My Pattern` | `@libar-docs-pattern:MyPattern` | +| Invalid | Valid | +| ------------------------------- | ------------------------------ | +| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | +| `@architect-pattern:My Pattern` | `@architect-pattern:MyPattern` | For values with spaces, use the `quoted-value` format where supported: ```gherkin -@libar-docs-usecase "When handling command failures" +@architect-usecase "When handling command failures" ``` --- diff --git a/docs-live/reference/PROCESS-API-RECIPES.md b/docs-live/reference/PROCESS-API-RECIPES.md index f180b2bc..f1e49869 100644 --- a/docs-live/reference/PROCESS-API-RECIPES.md +++ b/docs-live/reference/PROCESS-API-RECIPES.md @@ -16,16 +16,16 @@ The CLI has two output modes: - **Text commands** (6) -- formatted for terminal reading or AI context. Use `===` section markers for structure. - **JSON commands** (12+) -- wrapped in a `QueryResult` envelope. Pipeable to `jq`. -Run `process-api --help` for the full command reference with all flags and 26 available API methods. +Run `architect --help` for the full command reference with all flags and 26 available API methods. ## Quick Start The recommended session startup is three commands: ```bash -pnpm process:query -- overview -pnpm process:query -- scope-validate MyPattern implement -pnpm process:query -- context MyPattern --session implement +pnpm architect:query -- overview +pnpm architect:query -- scope-validate MyPattern implement +pnpm architect:query -- context MyPattern --session implement ``` Example `overview` output: @@ -42,7 +42,7 @@ Phase 25: DataAPIStubIntegration (1 active) StepLintExtendedRules blocked by: StepLintVitestCucumber === DATA API === -pnpm process:query -- +pnpm architect:query -- overview, context, scope-validate, dep-tree, list, stubs, files, rules, arch blocking ``` @@ -69,7 +69,7 @@ These 6 commands output structured text (not JSON). They are designed for termin Executive summary: progress percentage, active phases, blocking patterns, and a CLI cheat sheet. ```bash -pnpm process:query -- overview +pnpm architect:query -- overview ``` Example output: @@ -86,7 +86,7 @@ Phase 25: DataAPIStubIntegration (1 active) StepLintExtendedRules blocked by: StepLintVitestCucumber === DATA API — Use Instead of Explore Agents === -pnpm process:query -- +pnpm architect:query -- overview, context, scope-validate, dep-tree, list, stubs, files, rules, arch blocking ``` @@ -95,7 +95,7 @@ pnpm process:query -- **Highest-impact command.** Pre-flight readiness check that prevents wasted sessions. Returns a PASS/BLOCKED/WARN verdict covering: dependency completion, deliverable definitions, FSM transition validity, and design decisions. ```bash -pnpm process:query -- scope-validate MyPattern implement +pnpm architect:query -- scope-validate MyPattern implement ``` Checks: dependency completion, deliverable definitions, FSM transition validity, design decisions, executable spec location. Valid session types for scope-validate: `implement`, `design`. @@ -120,7 +120,7 @@ BLOCKED: 1 blocker(s) prevent implement session Curated context bundle tailored to session type. ```bash -pnpm process:query -- context MyPattern --session design +pnpm architect:query -- context MyPattern --session design ``` Example output: @@ -152,17 +152,17 @@ ProcessStateAPI (active, service) Dependency chain with status indicators. Shows what a pattern depends on, recursively. ```bash -pnpm process:query -- dep-tree MyPattern +pnpm architect:query -- dep-tree MyPattern ``` -Use `--depth` to limit recursion depth: `pnpm process:query -- dep-tree MyPattern --depth 2`. +Use `--depth` to limit recursion depth: `pnpm architect:query -- dep-tree MyPattern --depth 2`. ### `files` File reading list with implementation paths. Use `--related` to include architecture neighbors. ```bash -pnpm process:query -- files MyPattern --related +pnpm architect:query -- files MyPattern --related ``` Example output: @@ -182,7 +182,7 @@ src/cli/error-handler.ts Captures session-end state: deliverable statuses, blockers, and modification date. ```bash -pnpm process:query -- handoff --pattern MyPattern +pnpm architect:query -- handoff --pattern MyPattern ``` Use `--git` to include recent commits. Use `--session` to tag the handoff with a session id. @@ -212,7 +212,7 @@ These commands output JSON wrapped in a `QueryResult` envelope. Status counts and completion percentage. ```bash -pnpm process:query -- status +pnpm architect:query -- status ``` **Output:** `{ counts: { completed, active, planned, total }, completionPercentage, distribution }` @@ -222,7 +222,7 @@ pnpm process:query -- status Filtered pattern listing. Composable with output modifiers and list filters. ```bash -pnpm process:query -- list --status roadmap --names-only +pnpm architect:query -- list --status roadmap --names-only ``` See Output Modifiers and List Filters for all options. Examples: `list --status active --count`, `list --phase 25 --fields patternName,status,file`. @@ -232,7 +232,7 @@ See Output Modifiers and List Filters for all options. Examples: `list --status Fuzzy name search with match scores. Suggests close matches when a pattern is not found. ```bash -pnpm process:query -- search EventStore +pnpm architect:query -- search EventStore ``` ### `pattern` @@ -240,7 +240,7 @@ pnpm process:query -- search EventStore Full detail for one pattern including deliverables, dependencies, and all relationship fields. ```bash -pnpm process:query -- pattern TransformDataset +pnpm architect:query -- pattern TransformDataset ``` **Warning:** Completed patterns can produce ~66KB of output. Prefer `context --session` for interactive sessions. @@ -250,17 +250,17 @@ pnpm process:query -- pattern TransformDataset Design stubs with target paths and resolution status. ```bash -pnpm process:query -- stubs MyPattern +pnpm architect:query -- stubs MyPattern ``` -Use `--unresolved` to show only stubs missing target files: `pnpm process:query -- stubs --unresolved`. +Use `--unresolved` to show only stubs missing target files: `pnpm architect:query -- stubs --unresolved`. ### `decisions` AD-N design decisions extracted from stub descriptions. ```bash -pnpm process:query -- decisions MyPattern +pnpm architect:query -- decisions MyPattern ``` **Note:** Returns exit code 1 when no decisions are found (unlike `list`/`search` which return empty arrays). @@ -270,7 +270,7 @@ pnpm process:query -- decisions MyPattern Cross-reference patterns mentioning a PDR number. ```bash -pnpm process:query -- pdr 1 +pnpm architect:query -- pdr 1 ``` **Note:** Returns exit code 1 when no PDR references are found, same as `decisions`. @@ -280,7 +280,7 @@ pnpm process:query -- pdr 1 Business rules and invariants extracted from Gherkin `Rule:` blocks, grouped by product area, phase, and feature. ```bash -pnpm process:query -- rules --pattern ProcessGuardDecider +pnpm architect:query -- rules --pattern ProcessGuardDecider ``` **Warning:** Unfiltered `rules` output can exceed 600KB. Always use `--pattern` or `--product-area` filters. **Output shape:** `{ productAreas: [{ productArea, ruleCount, invariantCount, phases: [{ phase, features: [{ pattern, source, rules }] }] }], totalRules, totalInvariants }` @@ -289,14 +289,14 @@ pnpm process:query -- rules --pattern ProcessGuardDecider ## Architecture Queries -All architecture queries output JSON. They use `@libar-docs-arch-*` annotations. +All architecture queries output JSON. They use `@architect-arch-*` annotations. ### `arch roles` All arch-roles with pattern counts ```bash -pnpm process:query -- arch roles +pnpm architect:query -- arch roles ``` ### `arch context` @@ -304,7 +304,7 @@ pnpm process:query -- arch roles All bounded contexts ```bash -pnpm process:query -- arch context +pnpm architect:query -- arch context ``` ### `arch context ` @@ -312,7 +312,7 @@ pnpm process:query -- arch context Patterns in one bounded context ```bash -pnpm process:query -- arch context scanner +pnpm architect:query -- arch context scanner ``` ### `arch layer` @@ -320,7 +320,7 @@ pnpm process:query -- arch context scanner All architecture layers ```bash -pnpm process:query -- arch layer +pnpm architect:query -- arch layer ``` ### `arch layer ` @@ -328,7 +328,7 @@ pnpm process:query -- arch layer Patterns in one layer ```bash -pnpm process:query -- arch layer domain +pnpm architect:query -- arch layer domain ``` ### `arch neighborhood ` @@ -336,7 +336,7 @@ pnpm process:query -- arch layer domain Uses, usedBy, dependsOn, same-context ```bash -pnpm process:query -- arch neighborhood EventStore +pnpm architect:query -- arch neighborhood EventStore ``` ### `arch compare ` @@ -344,7 +344,7 @@ pnpm process:query -- arch neighborhood EventStore Cross-context shared deps + integration ```bash -pnpm process:query -- arch compare scanner codec +pnpm architect:query -- arch compare scanner codec ``` ### `arch coverage` @@ -352,7 +352,7 @@ pnpm process:query -- arch compare scanner codec Annotation completeness across input files ```bash -pnpm process:query -- arch coverage +pnpm architect:query -- arch coverage ``` ### `arch dangling` @@ -360,7 +360,7 @@ pnpm process:query -- arch coverage Broken references (names that don't exist) ```bash -pnpm process:query -- arch dangling +pnpm architect:query -- arch dangling ``` ### `arch orphans` @@ -368,7 +368,7 @@ pnpm process:query -- arch dangling Patterns with no relationships (isolated) ```bash -pnpm process:query -- arch orphans +pnpm architect:query -- arch orphans ``` ### `arch blocking` @@ -376,7 +376,7 @@ pnpm process:query -- arch orphans Patterns blocked by incomplete deps ```bash -pnpm process:query -- arch blocking +pnpm architect:query -- arch blocking ``` --- @@ -388,7 +388,7 @@ pnpm process:query -- arch blocking Tag usage report — counts per tag and value across all annotated sources. ```bash -pnpm process:query -- tags +pnpm architect:query -- tags ``` ### `sources` @@ -396,15 +396,15 @@ pnpm process:query -- tags File inventory by type (TypeScript, Gherkin, Stubs, Decisions). ```bash -pnpm process:query -- sources +pnpm architect:query -- sources ``` ### `unannotated` -TypeScript files missing the `@libar-docs` opt-in marker. Use `--path` to scope to a directory. +TypeScript files missing the `@architect` opt-in marker. Use `--path` to scope to a directory. ```bash -pnpm process:query -- unannotated --path src/types +pnpm architect:query -- unannotated --path src/types ``` ### `query` @@ -412,10 +412,10 @@ pnpm process:query -- unannotated --path src/types Execute any of the 26 query API methods directly by name. This is the escape hatch for methods not exposed as dedicated subcommands. ```bash -pnpm process:query -- query getStatusCounts +pnpm architect:query -- query getStatusCounts ``` -Integer-like arguments are automatically coerced to numbers. Run `process-api --help` for the full list of available API methods. Examples: `query isValidTransition roadmap active`, `query getPatternsByPhase 18`, `query getRecentlyCompleted 5`. +Integer-like arguments are automatically coerced to numbers. Run `architect --help` for the full list of available API methods. Examples: `query isValidTransition roadmap active`, `query getPatternsByPhase 18`, `query getRecentlyCompleted 5`. --- @@ -428,9 +428,9 @@ Frequently-used command sequences for daily workflow. The recommended session startup is three commands. ```bash -pnpm process:query -- overview # project health -pnpm process:query -- scope-validate MyPattern implement # pre-flight -pnpm process:query -- context MyPattern --session implement # curated context +pnpm architect:query -- overview # project health +pnpm architect:query -- scope-validate MyPattern implement # pre-flight +pnpm architect:query -- context MyPattern --session implement # curated context ``` ### Finding What to Work On @@ -438,9 +438,9 @@ pnpm process:query -- context MyPattern --session implement # curated context Discover available patterns, blockers, and missing implementations. ```bash -pnpm process:query -- list --status roadmap --names-only # available patterns -pnpm process:query -- arch blocking # stuck patterns -pnpm process:query -- stubs --unresolved # missing implementations +pnpm architect:query -- list --status roadmap --names-only # available patterns +pnpm architect:query -- arch blocking # stuck patterns +pnpm architect:query -- stubs --unresolved # missing implementations ``` ### Investigating a Pattern @@ -448,10 +448,10 @@ pnpm process:query -- stubs --unresolved # missing implementations Deep-dive into a specific pattern: search, dependencies, neighbors, and files. ```bash -pnpm process:query -- search EventStore # fuzzy name search -pnpm process:query -- dep-tree MyPattern --depth 2 # dependency chain -pnpm process:query -- arch neighborhood MyPattern # what it touches -pnpm process:query -- files MyPattern --related # file paths +pnpm architect:query -- search EventStore # fuzzy name search +pnpm architect:query -- dep-tree MyPattern --depth 2 # dependency chain +pnpm architect:query -- arch neighborhood MyPattern # what it touches +pnpm architect:query -- files MyPattern --related # file paths ``` ### Design Session Prep @@ -459,9 +459,9 @@ pnpm process:query -- files MyPattern --related # file paths Gather full context, design decisions, and stubs before a design session. ```bash -pnpm process:query -- context MyPattern --session design # full context -pnpm process:query -- decisions MyPattern # design decisions -pnpm process:query -- stubs MyPattern # existing stubs +pnpm architect:query -- context MyPattern --session design # full context +pnpm architect:query -- decisions MyPattern # design decisions +pnpm architect:query -- stubs MyPattern # existing stubs ``` ### Ending a Session @@ -469,8 +469,8 @@ pnpm process:query -- stubs MyPattern # existing stubs Capture session-end state for continuity. ```bash -pnpm process:query -- handoff --pattern MyPattern # capture state -pnpm process:query -- handoff --pattern MyPattern --git # include commits +pnpm architect:query -- handoff --pattern MyPattern # capture state +pnpm architect:query -- handoff --pattern MyPattern --git # include commits ``` --- diff --git a/docs-live/reference/PROCESS-API-REFERENCE.md b/docs-live/reference/PROCESS-API-REFERENCE.md index 7e60573a..b604fcc4 100644 --- a/docs-live/reference/PROCESS-API-REFERENCE.md +++ b/docs-live/reference/PROCESS-API-REFERENCE.md @@ -13,7 +13,7 @@ | `--help` | `-h` | Show help | --- | | `--version` | `-v` | Show version | --- | -**Config auto-detection:** If `--input` and `--features` are not provided, the CLI loads defaults from `delivery-process.config.ts` in the current directory. If no config file exists, it falls back to filesystem-based detection. If neither works, `--input` is required. +**Config auto-detection:** If `--input` and `--features` are not provided, the CLI loads defaults from `architect.config.ts` in the current directory. If no config file exists, it falls back to filesystem-based detection. If neither works, `--input` is required. --- diff --git a/docs-live/reference/PROCESS-GUARD-REFERENCE.md b/docs-live/reference/PROCESS-GUARD-REFERENCE.md index a46a4925..1a893868 100644 --- a/docs-live/reference/PROCESS-GUARD-REFERENCE.md +++ b/docs-live/reference/PROCESS-GUARD-REFERENCE.md @@ -29,9 +29,9 @@ | Situation | Solution | Example | | ----------------------------- | ---------------------------------- | --------------------------------------------- | -| Fix bug in completed spec | Add `@*-unlock-reason:'reason'` | `@libar-docs-unlock-reason:'Fix typo'` | -| Modify outside session scope | `--ignore-session` flag | `lint-process --staged --ignore-session` | -| CI treats warnings as errors | `--strict` flag | `lint-process --all --strict` | +| Fix bug in completed spec | Add `@*-unlock-reason:'reason'` | `@architect-unlock-reason:'Fix typo'` | +| Modify outside session scope | `--ignore-session` flag | `architect-guard --staged --ignore-session` | +| CI treats warnings as errors | `--strict` flag | `architect-guard --all --strict` | | Skip workflow (legacy import) | Multiple transitions in one commit | Set `roadmap` then `completed` in same commit | --- @@ -71,11 +71,11 @@ lint-process [options] ### Examples ```bash -lint-process --staged # Pre-commit hook (recommended) -lint-process --all --strict # CI pipeline with strict mode -lint-process --file specs/my-feature.feature # Validate specific file -lint-process --staged --show-state # Debug: see derived state -lint-process --staged --ignore-session # Override session scope +architect-guard --staged # Pre-commit hook (recommended) +architect-guard --all --strict # CI pipeline with strict mode +architect-guard --file specs/my-feature.feature # Validate specific file +architect-guard --staged --show-state # Debug: see derived state +architect-guard --staged --ignore-session # Override session scope ``` --- @@ -88,7 +88,7 @@ Configure Process Guard as a pre-commit hook using Husky. #!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh" -npx lint-process --staged +npx architect-guard --staged ``` ### package.json Scripts @@ -96,8 +96,8 @@ npx lint-process --staged ```json { "scripts": { - "lint:process": "lint-process --staged", - "lint:process:ci": "lint-process --all --strict" + "lint:process": "architect-guard --staged", + "lint:process:ci": "architect-guard --all --strict" } } ``` @@ -115,7 +115,7 @@ import { validateChanges, hasErrors, summarizeResult, -} from '@libar-dev/delivery-process/lint'; +} from '@libar-dev/architect/lint'; // 1. Derive state from annotations const state = (await deriveProcessState({ baseDir: '.' })).value; @@ -198,11 +198,11 @@ Follows the Decider pattern from platform-core: no I/O, no side effects. **Rationale:** The `completed` status represents verified, accepted work. Allowing silent modification undermines the terminal-state guarantee. Requiring an unlock reason creates an audit trail and forces the developer to justify why completed work needs revisiting. -| Situation | Solution | Example | -| -------------------------- | ---------------------------------- | --------------------------------------------------- | -| Fix typo in completed spec | Add unlock reason tag | `@libar-docs-unlock-reason:Fix-typo-in-FSM-diagram` | -| Spec needs rework | Create new spec instead | New feature file with `roadmap` status | -| Legacy import | Multiple transitions in one commit | Set `roadmap` then `completed` | +| Situation | Solution | Example | +| -------------------------- | ---------------------------------- | -------------------------------------------------- | +| Fix typo in completed spec | Add unlock reason tag | `@architect-unlock-reason:Fix-typo-in-FSM-diagram` | +| Spec needs rework | Create new spec instead | New feature file with `roadmap` status | +| Legacy import | Multiple transitions in one commit | Set `roadmap` then `completed` | --- diff --git a/docs-live/reference/REFERENCE-SAMPLE.md b/docs-live/reference/REFERENCE-SAMPLE.md index 29f24c16..78cb77ad 100644 --- a/docs-live/reference/REFERENCE-SAMPLE.md +++ b/docs-live/reference/REFERENCE-SAMPLE.md @@ -76,7 +76,7 @@ **Verified by:** Canonical values are enforced Completed is a terminal state. Modifications require - `@libar-docs-unlock-reason` escape hatch. + `@architect-unlock-reason` escape hatch. --- @@ -86,14 +86,14 @@ **Rationale:** Without explicit format types, parsers must guess value structure, leading to silent data corruption when CSV values are treated as single strings or numbers are treated as text. -| Format | Parsing | Example | -| ------------ | ------------------------------ | ------------------------------ | -| flag | Boolean presence, no value | @libar-docs-core | -| value | Simple string | @libar-docs-pattern MyPattern | -| enum | Constrained to predefined list | @libar-docs-status completed | -| csv | Comma-separated values | @libar-docs-uses A, B, C | -| number | Numeric value | @libar-docs-phase 15 | -| quoted-value | Preserves spaces | @libar-docs-brief:'Multi word' | +| Format | Parsing | Example | +| ------------ | ------------------------------ | ----------------------------- | +| flag | Boolean presence, no value | @architect-core | +| value | Simple string | @architect-pattern MyPattern | +| enum | Constrained to predefined list | @architect-status completed | +| csv | Comma-separated values | @architect-uses A, B, C | +| number | Numeric value | @architect-phase 15 | +| quoted-value | Preserves spaces | @architect-brief:'Multi word' | **Verified by:** Canonical values are enforced @@ -171,7 +171,7 @@ Scoped architecture diagram showing component relationships: ```mermaid graph TB subgraph config["Config"] - DeliveryProcessFactory("DeliveryProcessFactory") + ArchitectFactory("ArchitectFactory") DefineConfig[/"DefineConfig"/] end ConfigBasedWorkflowDefinition["ConfigBasedWorkflowDefinition"] @@ -186,9 +186,9 @@ graph TB PhaseStateMachineValidation["PhaseStateMachineValidation"]:::neighbor MvpWorkflowImplementation["MvpWorkflowImplementation"]:::neighbor end - DeliveryProcessFactory -->|uses| ConfigurationTypes - DeliveryProcessFactory -->|uses| ConfigurationPresets - DeliveryProcessFactory -->|uses| RegexBuilders + ArchitectFactory -->|uses| ConfigurationTypes + ArchitectFactory -->|uses| ConfigurationPresets + ArchitectFactory -->|uses| RegexBuilders DefineConfig -->|uses| ProjectConfigTypes ConfigBasedWorkflowDefinition -.->|depends on| MvpWorkflowImplementation ProcessGuardTesting -.->|depends on| PhaseStateMachineValidation @@ -553,9 +553,9 @@ interface CategoryDefinition { ## Behavior Specifications -### DeliveryProcessFactory +### ArchitectFactory -[View DeliveryProcessFactory source](src/config/factory.ts) +[View ArchitectFactory source](src/config/factory.ts) ## Delivery Process Factory @@ -582,11 +582,11 @@ Validation happens later at load time via Zod schema in `loadProjectConfig()`. ### When to Use -- In `delivery-process.config.ts` at project root to get type-safe configuration with autocompletion. +- In `architect.config.ts` at project root to get type-safe configuration with autocompletion. ### ADR005CodecBasedMarkdownRendering -[View ADR005CodecBasedMarkdownRendering source](delivery-process/decisions/adr-005-codec-based-markdown-rendering.feature) +[View ADR005CodecBasedMarkdownRendering source](architect/decisions/adr-005-codec-based-markdown-rendering.feature) **Context:** The documentation generator needs to transform structured pattern data @@ -728,7 +728,7 @@ const referenceDoc = CompositeCodec.create({ ### ADR001TaxonomyCanonicalValues -[View ADR001TaxonomyCanonicalValues source](delivery-process/decisions/adr-001-taxonomy-canonical-values.feature) +[View ADR001TaxonomyCanonicalValues source](architect/decisions/adr-001-taxonomy-canonical-values.feature) **Context:** The annotation system requires well-defined canonical values for taxonomy @@ -807,7 +807,7 @@ These are the durable constants of the delivery process. - Canonical values are enforced Completed is a terminal state. Modifications require - `@libar-docs-unlock-reason` escape hatch. + `@architect-unlock-reason` escape hatch. @@ -888,10 +888,10 @@ These are the durable constants of the delivery process. ### ConfigBasedWorkflowDefinition -[View ConfigBasedWorkflowDefinition source](delivery-process/specs/config-based-workflow-definition.feature) +[View ConfigBasedWorkflowDefinition source](architect/specs/config-based-workflow-definition.feature) **Problem:** -Every `pnpm process:query` and `pnpm docs:*` invocation prints: +Every `pnpm architect:query` and `pnpm docs:*` invocation prints: `Failed to load default workflow (6-phase-standard): Workflow file not found` The `loadDefaultWorkflow()` function resolves to `catalogue/workflows/` @@ -985,8 +985,8 @@ Design Decisions (DS-1, 2026-02-15): - N/A - deferred until preset integration - Adding `workflow` as a field on `DeliveryProcessConfig` (presets) and - `DeliveryProcessProjectConfig` (project config) is a natural next step + Adding `workflow` as a field on `ArchitectConfig` (presets) and + `ArchitectProjectConfig` (project config) is a natural next step but NOT required for the MVP fix. The inline constant in `workflow-loader.ts` resolves the warning. Moving @@ -994,11 +994,11 @@ Design Decisions (DS-1, 2026-02-15): - Different presets with different default phases (e.g. - 3-phase generic) - - Per-project phase customization in delivery-process.config.ts + - Per-project phase customization in architect.config.ts - Phase definitions appearing in generated documentation See ideation artifact for design options: - delivery-process/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature + architect/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature @@ -1029,7 +1029,7 @@ All validation follows the Decider pattern: (state, changes, options) => result. #### Completed files require unlock-reason to modify -**Invariant:** A completed spec file cannot be modified unless it carries an @libar-docs-unlock-reason tag. +**Invariant:** A completed spec file cannot be modified unless it carries an @architect-unlock-reason tag. **Rationale:** Completed work represents validated, shipped functionality — accidental modification risks regression. diff --git a/docs-live/reference/SESSION-WORKFLOW-GUIDE.md b/docs-live/reference/SESSION-WORKFLOW-GUIDE.md index bd9e3ac8..fe6de595 100644 --- a/docs-live/reference/SESSION-WORKFLOW-GUIDE.md +++ b/docs-live/reference/SESSION-WORKFLOW-GUIDE.md @@ -42,7 +42,7 @@ graph TD Implementation sessions MUST follow this strict 5-step sequence. Skipping steps causes Process Guard rejection at commit time. 1. **Transition to `active` FIRST** (before any code changes) -2. **Create executable spec stubs** (if `@libar-docs-executable-specs` present) +2. **Create executable spec stubs** (if `@architect-executable-specs` present) 3. **For each deliverable:** implement, test, update status to `complete` 4. **Transition to `completed`** (only when ALL deliverables done) 5. **Regenerate docs:** `pnpm docs:all` @@ -65,8 +65,8 @@ Implementation sessions MUST follow this strict 5-step sequence. Skipping steps ### Context Gathering ```bash -pnpm process:query -- overview # Project health -pnpm process:query -- list --status roadmap --names-only # Available patterns +pnpm architect:query -- overview # Project health +pnpm architect:query -- list --status roadmap --names-only # Available patterns ``` ### Planning Checklist @@ -76,7 +76,7 @@ pnpm process:query -- list --status roadmap --names-only # Available patter - [ ] **Structure the feature** with Problem/Solution, tags, deliverables table - [ ] **Convert constraints to Rule: blocks** with Invariant/Rationale - [ ] **Add scenarios** per Rule: 1 happy-path + 1 validation minimum -- [ ] **Set executable specs location** via `@libar-docs-executable-specs` tag +- [ ] **Set executable specs location** via `@architect-executable-specs` tag ### Planning Do NOT @@ -93,9 +93,9 @@ pnpm process:query -- list --status roadmap --names-only # Available patter ### Context Gathering ```bash -pnpm process:query -- context --session design # Full context bundle -pnpm process:query -- dep-tree # Dependency chain -pnpm process:query -- stubs # Existing design stubs +pnpm architect:query -- context --session design # Full context bundle +pnpm architect:query -- dep-tree # Dependency chain +pnpm architect:query -- stubs # Existing design stubs ``` ### When to Use Design Sessions @@ -108,12 +108,12 @@ pnpm process:query -- stubs # Existing design ### Design Checklist -- [ ] **Record decisions** as PDR `.feature` files in `delivery-process/decisions/` +- [ ] **Record decisions** as PDR `.feature` files in `architect/decisions/` - [ ] **Document options** with at least 2-3 approaches and pros/cons - [ ] **Get approval** from user on recommended approach -- [ ] **Create code stubs** in `delivery-process/stubs/{pattern-name}/` +- [ ] **Create code stubs** in `architect/stubs/{pattern-name}/` - [ ] **Verify stub identifier spelling** before committing -- [ ] **List canonical helpers** in `@libar-docs-uses` tags +- [ ] **List canonical helpers** in `@architect-uses` tags ### Design Do NOT @@ -143,8 +143,8 @@ pnpm process:query -- stubs # Existing design For multi-session work, capture state at session boundaries using the Process Data API. ```bash -pnpm process:query -- handoff --pattern -pnpm process:query -- handoff --pattern --git # include recent commits +pnpm architect:query -- handoff --pattern +pnpm architect:query -- handoff --pattern --git # include recent commits ``` --- @@ -164,7 +164,7 @@ pnpm process:query -- handoff --pattern --git # include recent c ### SessionGuidesModuleSource -[View SessionGuidesModuleSource source](delivery-process/specs/session-guides-module-source.feature) +[View SessionGuidesModuleSource source](architect/specs/session-guides-module-source.feature) **Problem:** CLAUDE.md contains a "Session Workflows" section (~160 lines) that is hand-maintained @@ -172,7 +172,7 @@ with no link to any annotated source. Three hand-written files in `_claude-md/wo (session-workflows.md, session-details.md, fsm-handoff.md) are equally opaque: no machine-readable origin, no regeneration from source annotations. -The prior plan proposed tagging ADR-001, ADR-003, and PDR-001 with `@libar-docs-claude-module` +The prior plan proposed tagging ADR-001, ADR-003, and PDR-001 with `@architect-claude-module` to make them the source for generated workflow modules. Design analysis revealed this is fundamentally flawed: `claude-module` is a file-level tag that pulls ALL Rules from a file, but most Rules in those decision specs are irrelevant to session workflows (ADR-001 has 9 @@ -184,8 +184,8 @@ This spec file itself becomes the annotated source for session workflow content. Session workflow invariants are captured as Rule: blocks here, covering session type contracts, FSM protection, execution order, error recovery, and handoff patterns. -Once ClaudeModuleGeneration (Phase 25) ships, adding `@libar-docs-claude-module` and -`@libar-docs-claude-section:workflow` tags to this spec will cause the codec to produce +Once ClaudeModuleGeneration (Phase 25) ships, adding `@architect-claude-module` and +`@architect-claude-section:workflow` tags to this spec will cause the codec to produce `_claude-md/workflow/` modules automatically. The hand-written files are then deleted and the CLAUDE.md section becomes a generated include. @@ -205,7 +205,7 @@ Three-layer architecture after Phase 39: | No CLAUDE.md drift | Session workflow section generated, not hand-authored | | Single annotated source | This spec owns all session workflow invariants | | Correct audience alignment | Public guide stays in docs/, AI context in \_claude-md/ | -| Process API coverage | Session workflow content queryable via `pnpm process:query -- rules` | +| Process API coverage | Session workflow content queryable via `pnpm architect:query -- rules` | | Immediately useful | Rule: blocks are queryable today, generation follows when Phase 25 ships | **Design Session Findings (2026-03-05):** @@ -285,7 +285,7 @@ Three-layer architecture after Phase 39: **Invariant:** A design session makes architectural decisions and creates code stubs with interfaces. It must not produce implementation code. Context gathering via the Process Data API must precede any explore agent usage. -**Rationale:** Design sessions resolve ambiguity before implementation begins. Code stubs in delivery-process/stubs/ live outside src/ to avoid TypeScript compilation and ESLint issues, making them zero-risk artifacts. +**Rationale:** Design sessions resolve ambiguity before implementation begins. Code stubs in architect/stubs/ live outside src/ to avoid TypeScript compilation and ESLint issues, making them zero-risk artifacts. **Verified by:** @@ -349,7 +349,7 @@ Three-layer architecture after Phase 39: - Handoff output reflects annotation state - Handoff output reflects annotation state - Generate handoff via: pnpm process:query -- handoff --pattern PatternName + Generate handoff via: pnpm architect:query -- handoff --pattern PatternName Options: --git (include recent commits) - --session (session identifier) @@ -368,9 +368,9 @@ Three-layer architecture after Phase 39: #### ClaudeModuleGeneration is the generation mechanism -**Invariant:** Phase 39 depends on ClaudeModuleGeneration (Phase 25). Adding `@libar-docs-claude-module` and `@libar-docs-claude-section:workflow` tags to this spec will cause ClaudeModuleGeneration to produce `_claude-md/workflow/` output files. The hand-written `_claude-md/workflow/` files are deleted after successful verified generation. +**Invariant:** Phase 39 depends on ClaudeModuleGeneration (Phase 25). Adding `@architect-claude-module` and `@architect-claude-section:workflow` tags to this spec will cause ClaudeModuleGeneration to produce `_claude-md/workflow/` output files. The hand-written `_claude-md/workflow/` files are deleted after successful verified generation. -**Rationale:** The annotation work (Rule blocks in this spec) is immediately useful — queryable via `pnpm process:query -- rules`. Generation deliverables cannot complete until Phase 25 ships the ClaudeModuleCodec. This sequencing is intentional: the annotation investment has standalone value regardless of whether the codec exists yet. +**Rationale:** The annotation work (Rule blocks in this spec) is immediately useful — queryable via `pnpm architect:query -- rules`. Generation deliverables cannot complete until Phase 25 ships the ClaudeModuleCodec. This sequencing is intentional: the annotation investment has standalone value regardless of whether the codec exists yet. **Prerequisite:** Phase 25 must add `workflow` to the `claude-section` enum values (currently: core, delivery-process, testing, infrastructure). diff --git a/docs-live/reference/VALIDATION-TOOLS-GUIDE.md b/docs-live/reference/VALIDATION-TOOLS-GUIDE.md index 3156b7cf..98b4482e 100644 --- a/docs-live/reference/VALIDATION-TOOLS-GUIDE.md +++ b/docs-live/reference/VALIDATION-TOOLS-GUIDE.md @@ -21,17 +21,17 @@ Need cross-source or DoD validation? Yes -> validate-patterns Running pre-commit hook? - lint-process --staged (default) + architect-guard --staged (default) ``` ## Command Summary -| Command | Purpose | When to Use | -| ------------------- | --------------------------------- | --------------------------------------------- | -| `lint-patterns` | Annotation quality | Ensure patterns have required tags | -| `lint-steps` | vitest-cucumber compatibility | After writing/modifying feature or step files | -| `lint-process` | FSM workflow enforcement | Pre-commit hooks, CI pipelines | -| `validate-patterns` | Cross-source + DoD + anti-pattern | Release validation, comprehensive | +| Command | Purpose | When to Use | +| ------------------------- | --------------------------------- | --------------------------------------------- | +| `architect-lint-patterns` | Annotation quality | Ensure patterns have required tags | +| `architect-lint-steps` | vitest-cucumber compatibility | After writing/modifying feature or step files | +| `architect-guard` | FSM workflow enforcement | Pre-commit hooks, CI pipelines | +| `architect-validate` | Cross-source + DoD + anti-pattern | Release validation, comprehensive | --- @@ -124,8 +124,8 @@ pnpm lint:steps --strict # CI FSM validation for delivery workflow. Enforces status transitions and protection levels. ```bash -npx lint-process --staged # Pre-commit (default) -npx lint-process --all --strict # CI pipeline +npx architect-guard --staged # Pre-commit (default) +npx architect-guard --all --strict # CI pipeline ``` **What it validates:** @@ -204,8 +204,8 @@ For patterns with `completed` status, checks: "lint:patterns": "lint-patterns -i 'src/**/*.ts'", "lint:steps": "lint-steps", "lint:steps:ci": "lint-steps --strict", - "lint:process": "lint-process --staged", - "lint:process:ci": "lint-process --all --strict", + "lint:process": "architect-guard --staged", + "lint:process:ci": "architect-guard --all --strict", "validate:all": "validate-patterns -i 'src/**/*.ts' -F 'specs/**/*.feature' --dod --anti-patterns" } } @@ -214,7 +214,7 @@ For patterns with `completed` status, checks: ### Pre-commit Hook ```bash -npx lint-process --staged +npx architect-guard --staged ``` ### GitHub Actions @@ -248,16 +248,16 @@ All validation tools expose programmatic APIs: ```typescript // Pattern linting -import { lintFiles, hasFailures } from '@libar-dev/delivery-process/lint'; +import { lintFiles, hasFailures } from '@libar-dev/architect/lint'; // Step linting -import { runStepLint, STEP_LINT_RULES } from '@libar-dev/delivery-process/lint'; +import { runStepLint, STEP_LINT_RULES } from '@libar-dev/architect/lint'; // Process guard -import { deriveProcessState, validateChanges } from '@libar-dev/delivery-process/lint'; +import { deriveProcessState, validateChanges } from '@libar-dev/architect/lint'; // Anti-patterns and DoD -import { detectAntiPatterns, validateDoD } from '@libar-dev/delivery-process/validation'; +import { detectAntiPatterns, validateDoD } from '@libar-dev/architect/validation'; ``` --- diff --git a/docs-live/taxonomy/format-types.md b/docs-live/taxonomy/format-types.md index 9a0bd1c8..6b6e2284 100644 --- a/docs-live/taxonomy/format-types.md +++ b/docs-live/taxonomy/format-types.md @@ -14,7 +14,7 @@ Detailed parsing behavior for each format type. | ---------------- | --------------------------------------------------- | | Description | Simple string value | | Parsing Behavior | Captures everything after the tag name as the value | -| Example | `@libar-docs-pattern CommandOrchestrator` | +| Example | `@architect-pattern CommandOrchestrator` | | Notes | Most common format for single-value tags | ### `enum` @@ -23,7 +23,7 @@ Detailed parsing behavior for each format type. | ---------------- | ------------------------------------------------------------ | | Description | Constrained to predefined values | | Parsing Behavior | Validates value against allowed list; rejects invalid values | -| Example | `@libar-docs-status roadmap` | +| Example | `@architect-status roadmap` | | Notes | Used for FSM states, priority levels, risk levels | ### `quoted-value` @@ -32,7 +32,7 @@ Detailed parsing behavior for each format type. | ---------------- | -------------------------------------------------------------- | | Description | String in quotes (preserves spaces) | | Parsing Behavior | Extracts content between quotes; preserves internal whitespace | -| Example | `@libar-docs-usecase "When a user submits a form"` | +| Example | `@architect-usecase "When a user submits a form"` | | Notes | Use for human-readable text with spaces | ### `csv` @@ -41,7 +41,7 @@ Detailed parsing behavior for each format type. | ---------------- | ----------------------------------------------------- | | Description | Comma-separated values | | Parsing Behavior | Splits on commas; trims whitespace from each value | -| Example | `@libar-docs-uses CommandBus, EventStore, Projection` | +| Example | `@architect-uses CommandBus, EventStore, Projection` | | Notes | Used for relationship tags and multi-value references | ### `number` @@ -50,7 +50,7 @@ Detailed parsing behavior for each format type. | ---------------- | ----------------------------------- | | Description | Numeric value | | Parsing Behavior | Parses as integer; NaN if invalid | -| Example | `@libar-docs-phase 14` | +| Example | `@architect-phase 14` | | Notes | Used for phase numbers and ordering | ### `flag` @@ -59,7 +59,7 @@ Detailed parsing behavior for each format type. | ---------------- | ------------------------------------------------------- | | Description | Boolean presence (no value needed) | | Parsing Behavior | Presence of tag indicates true; absence indicates false | -| Example | `@libar-docs-core` | +| Example | `@architect-core` | | Notes | Used for boolean markers like core, overview, decision | --- diff --git a/docs-live/taxonomy/metadata-tags.md b/docs-live/taxonomy/metadata-tags.md index 0a6c58fd..976fbe49 100644 --- a/docs-live/taxonomy/metadata-tags.md +++ b/docs-live/taxonomy/metadata-tags.md @@ -75,13 +75,13 @@ ### `pattern` -| Property | Value | -| ---------- | ----------------------------------------- | -| Format | value | -| Purpose | Explicit pattern name | -| Required | Yes | -| Repeatable | No | -| Example | `@libar-docs-pattern CommandOrchestrator` | +| Property | Value | +| ---------- | ---------------------------------------- | +| Format | value | +| Purpose | Explicit pattern name | +| Required | Yes | +| Repeatable | No | +| Example | `@architect-pattern CommandOrchestrator` | ### `status` @@ -93,7 +93,7 @@ | Repeatable | No | | Valid Values | roadmap, active, completed, deferred | | Default | roadmap | -| Example | `@libar-docs-status roadmap` | +| Example | `@architect-status roadmap` | ### `core` @@ -103,37 +103,37 @@ | Purpose | Marks as essential/must-know pattern | | Required | No | | Repeatable | No | -| Example | `@libar-docs-core` | +| Example | `@architect-core` | ### `usecase` -| Property | Value | -| ---------- | ------------------------------------------------------ | -| Format | quoted-value | -| Purpose | Use case association | -| Required | No | -| Repeatable | Yes | -| Example | `@libar-docs-usecase "When handling command failures"` | +| Property | Value | +| ---------- | ----------------------------------------------------- | +| Format | quoted-value | +| Purpose | Use case association | +| Required | No | +| Repeatable | Yes | +| Example | `@architect-usecase "When handling command failures"` | ### `uses` -| Property | Value | -| ---------- | ----------------------------------------- | -| Format | csv | -| Purpose | Patterns this depends on | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-uses CommandBus, EventStore` | +| Property | Value | +| ---------- | ---------------------------------------- | +| Format | csv | +| Purpose | Patterns this depends on | +| Required | No | +| Repeatable | No | +| Example | `@architect-uses CommandBus, EventStore` | ### `used-by` -| Property | Value | -| ---------- | -------------------------------------- | -| Format | csv | -| Purpose | Patterns that depend on this | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-used-by SagaOrchestrator` | +| Property | Value | +| ---------- | ------------------------------------- | +| Format | csv | +| Purpose | Patterns that depend on this | +| Required | No | +| Repeatable | No | +| Example | `@architect-used-by SagaOrchestrator` | ### `phase` @@ -143,7 +143,7 @@ | Purpose | Roadmap phase number (unified across monorepo) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-phase 14` | +| Example | `@architect-phase 14` | ### `release` @@ -153,47 +153,47 @@ | Purpose | Target release version (semver or vNEXT for unreleased work) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-release v0.1.0` | +| Example | `@architect-release v0.1.0` | ### `brief` -| Property | Value | -| ---------- | -------------------------------------------------- | -| Format | value | -| Purpose | Path to pattern brief markdown | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-brief docs/briefs/decider-pattern.md` | +| Property | Value | +| ---------- | ------------------------------------------------- | +| Format | value | +| Purpose | Path to pattern brief markdown | +| Required | No | +| Repeatable | No | +| Example | `@architect-brief docs/briefs/decider-pattern.md` | ### `depends-on` -| Property | Value | -| ---------- | ----------------------------------------------- | -| Format | csv | -| Purpose | Roadmap dependencies (pattern or phase names) | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-depends-on EventStore, CommandBus` | +| Property | Value | +| ---------- | ---------------------------------------------- | +| Format | csv | +| Purpose | Roadmap dependencies (pattern or phase names) | +| Required | No | +| Repeatable | No | +| Example | `@architect-depends-on EventStore, CommandBus` | ### `enables` -| Property | Value | -| ---------- | --------------------------------------------------------- | -| Format | csv | -| Purpose | Patterns this enables | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-enables SagaOrchestrator, ProjectionBuilder` | +| Property | Value | +| ---------- | -------------------------------------------------------- | +| Format | csv | +| Purpose | Patterns this enables | +| Required | No | +| Repeatable | No | +| Example | `@architect-enables SagaOrchestrator, ProjectionBuilder` | ### `implements` -| Property | Value | -| ---------- | --------------------------------------------------------------- | -| Format | csv | -| Purpose | Patterns this code file realizes (realization relationship) | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-implements EventStoreDurability, IdempotentAppend` | +| Property | Value | +| ---------- | -------------------------------------------------------------- | +| Format | csv | +| Purpose | Patterns this code file realizes (realization relationship) | +| Required | No | +| Repeatable | No | +| Example | `@architect-implements EventStoreDurability, IdempotentAppend` | ### `extends` @@ -203,7 +203,7 @@ | Purpose | Base pattern this pattern extends (generalization relationship) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-extends ProjectionCategories` | +| Example | `@architect-extends ProjectionCategories` | ### `quarter` @@ -213,7 +213,7 @@ | Purpose | Delivery quarter for timeline tracking | | Required | No | | Repeatable | No | -| Example | `@libar-docs-quarter Q1-2026` | +| Example | `@architect-quarter Q1-2026` | ### `completed` @@ -223,7 +223,7 @@ | Purpose | Completion date (YYYY-MM-DD format) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-completed 2026-01-08` | +| Example | `@architect-completed 2026-01-08` | ### `effort` @@ -233,7 +233,7 @@ | Purpose | Estimated effort (4h, 2d, 1w format) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-effort 2d` | +| Example | `@architect-effort 2d` | ### `effort-actual` @@ -243,7 +243,7 @@ | Purpose | Actual effort spent (4h, 2d, 1w format) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-effort-actual 3d` | +| Example | `@architect-effort-actual 3d` | ### `team` @@ -253,7 +253,7 @@ | Purpose | Responsible team assignment | | Required | No | | Repeatable | No | -| Example | `@libar-docs-team platform` | +| Example | `@architect-team platform` | ### `workflow` @@ -264,18 +264,18 @@ | Required | No | | Repeatable | No | | Valid Values | implementation, planning, validation, documentation | -| Example | `@libar-docs-workflow implementation` | +| Example | `@architect-workflow implementation` | ### `risk` -| Property | Value | -| ------------ | ------------------------- | -| Format | enum | -| Purpose | Risk level for planning | -| Required | No | -| Repeatable | No | -| Valid Values | low, medium, high | -| Example | `@libar-docs-risk medium` | +| Property | Value | +| ------------ | ------------------------ | +| Format | enum | +| Purpose | Risk level for planning | +| Required | No | +| Repeatable | No | +| Valid Values | low, medium, high | +| Example | `@architect-risk medium` | ### `priority` @@ -286,17 +286,17 @@ | Required | No | | Repeatable | No | | Valid Values | critical, high, medium, low | -| Example | `@libar-docs-priority high` | +| Example | `@architect-priority high` | ### `product-area` -| Property | Value | -| ---------- | --------------------------------------- | -| Format | value | -| Purpose | Product area for PRD grouping | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-product-area PlatformCore` | +| Property | Value | +| ---------- | -------------------------------------- | +| Format | value | +| Purpose | Product area for PRD grouping | +| Required | No | +| Repeatable | No | +| Example | `@architect-product-area PlatformCore` | ### `user-role` @@ -306,17 +306,17 @@ | Purpose | Target user persona for this feature | | Required | No | | Repeatable | No | -| Example | `@libar-docs-user-role Developer` | +| Example | `@architect-user-role Developer` | ### `business-value` -| Property | Value | -| ---------- | --------------------------------------------------------------- | -| Format | value | -| Purpose | Business value statement (hyphenated for tag format) | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-business-value eliminates-event-replay-complexity` | +| Property | Value | +| ---------- | -------------------------------------------------------------- | +| Format | value | +| Purpose | Business value statement (hyphenated for tag format) | +| Required | No | +| Repeatable | No | +| Example | `@architect-business-value eliminates-event-replay-complexity` | ### `constraint` @@ -326,7 +326,7 @@ | Purpose | Technical constraint affecting feature implementation | | Required | No | | Repeatable | Yes | -| Example | `@libar-docs-constraint requires-convex-backend` | +| Example | `@architect-constraint requires-convex-backend` | ### `adr` @@ -336,7 +336,7 @@ | Purpose | ADR/PDR number for decision tracking | | Required | No | | Repeatable | No | -| Example | `@libar-docs-adr 015` | +| Example | `@architect-adr 015` | ### `adr-status` @@ -348,7 +348,7 @@ | Repeatable | No | | Valid Values | proposed, accepted, deprecated, superseded | | Default | proposed | -| Example | `@libar-docs-adr-status accepted` | +| Example | `@architect-adr-status accepted` | ### `adr-category` @@ -358,7 +358,7 @@ | Purpose | ADR/PDR category (architecture, process, tooling) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-adr-category architecture` | +| Example | `@architect-adr-category architecture` | ### `adr-supersedes` @@ -368,7 +368,7 @@ | Purpose | ADR/PDR number this decision supersedes | | Required | No | | Repeatable | No | -| Example | `@libar-docs-adr-supersedes 012` | +| Example | `@architect-adr-supersedes 012` | ### `adr-superseded-by` @@ -378,7 +378,7 @@ | Purpose | ADR/PDR number that supersedes this decision | | Required | No | | Repeatable | No | -| Example | `@libar-docs-adr-superseded-by 020` | +| Example | `@architect-adr-superseded-by 020` | ### `adr-theme` @@ -389,7 +389,7 @@ | Required | No | | Repeatable | No | | Valid Values | persistence, isolation, commands, projections, coordination, taxonomy, testing | -| Example | `@libar-docs-adr-theme persistence` | +| Example | `@architect-adr-theme persistence` | ### `adr-layer` @@ -400,7 +400,7 @@ | Required | No | | Repeatable | No | | Valid Values | foundation, infrastructure, refinement | -| Example | `@libar-docs-adr-layer foundation` | +| Example | `@architect-adr-layer foundation` | ### `level` @@ -412,7 +412,7 @@ | Repeatable | No | | Valid Values | epic, phase, task | | Default | phase | -| Example | `@libar-docs-level epic` | +| Example | `@architect-level epic` | ### `parent` @@ -422,7 +422,7 @@ | Purpose | Parent pattern name in hierarchy (links tasks to phases, phases to epics) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-parent AggregateArchitecture` | +| Example | `@architect-parent AggregateArchitecture` | ### `title` @@ -432,17 +432,17 @@ | Purpose | Human-readable display title (supports quoted values with spaces) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-title:"Process Guard Linter"` | +| Example | `@architect-title:"Process Guard Linter"` | ### `executable-specs` -| Property | Value | -| ---------- | ----------------------------------------------------------------------- | -| Format | csv | -| Purpose | Links roadmap spec to package executable spec locations (PDR-007) | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-executable-specs platform-decider/tests/features/behavior` | +| Property | Value | +| ---------- | ---------------------------------------------------------------------- | +| Format | csv | +| Purpose | Links roadmap spec to package executable spec locations (PDR-007) | +| Required | No | +| Repeatable | No | +| Example | `@architect-executable-specs platform-decider/tests/features/behavior` | ### `roadmap-spec` @@ -452,67 +452,67 @@ | Purpose | Links package spec back to roadmap pattern for traceability (PDR-007) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-roadmap-spec DeciderPattern` | +| Example | `@architect-roadmap-spec DeciderPattern` | ### `behavior-file` -| Property | Value | -| ---------- | ------------------------------------------------------- | -| Format | value | -| Purpose | Path to behavior test feature file for traceability | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-behavior-file behavior/my-pattern.feature` | +| Property | Value | +| ---------- | ------------------------------------------------------ | +| Format | value | +| Purpose | Path to behavior test feature file for traceability | +| Required | No | +| Repeatable | No | +| Example | `@architect-behavior-file behavior/my-pattern.feature` | ### `discovered-gap` +| Property | Value | +| ---------- | -------------------------------------------------- | +| Format | value | +| Purpose | Gap identified during session retrospective | +| Required | No | +| Repeatable | Yes | +| Example | `@architect-discovered-gap missing-error-handling` | + +### `discovered-improvement` + +| Property | Value | +| ---------- | ------------------------------------------------------ | +| Format | value | +| Purpose | Improvement identified during session retrospective | +| Required | No | +| Repeatable | Yes | +| Example | `@architect-discovered-improvement cache-invalidation` | + +### `discovered-risk` + | Property | Value | | ---------- | --------------------------------------------------- | | Format | value | -| Purpose | Gap identified during session retrospective | +| Purpose | Risk identified during session retrospective | | Required | No | | Repeatable | Yes | -| Example | `@libar-docs-discovered-gap missing-error-handling` | +| Example | `@architect-discovered-risk data-loss-on-migration` | -### `discovered-improvement` +### `discovered-learning` | Property | Value | | ---------- | ------------------------------------------------------- | | Format | value | -| Purpose | Improvement identified during session retrospective | +| Purpose | Learning captured during session retrospective | | Required | No | | Repeatable | Yes | -| Example | `@libar-docs-discovered-improvement cache-invalidation` | - -### `discovered-risk` - -| Property | Value | -| ---------- | ---------------------------------------------------- | -| Format | value | -| Purpose | Risk identified during session retrospective | -| Required | No | -| Repeatable | Yes | -| Example | `@libar-docs-discovered-risk data-loss-on-migration` | - -### `discovered-learning` - -| Property | Value | -| ---------- | -------------------------------------------------------- | -| Format | value | -| Purpose | Learning captured during session retrospective | -| Required | No | -| Repeatable | Yes | -| Example | `@libar-docs-discovered-learning convex-mutation-limits` | +| Example | `@architect-discovered-learning convex-mutation-limits` | ### `see-also` -| Property | Value | -| ---------- | --------------------------------------------------------------------- | -| Format | csv | -| Purpose | Related patterns for cross-reference without dependency implication | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-see-also AgentAsBoundedContext, CrossContextIntegration` | +| Property | Value | +| ---------- | -------------------------------------------------------------------- | +| Format | csv | +| Purpose | Related patterns for cross-reference without dependency implication | +| Required | No | +| Repeatable | No | +| Example | `@architect-see-also AgentAsBoundedContext, CrossContextIntegration` | ### `api-ref` @@ -522,17 +522,17 @@ | Purpose | File paths to implementation APIs (replaces 'See:' Markdown text in Rules) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-api-ref @libar-dev/platform-core/src/durability/outbox.ts` | +| Example | `@architect-api-ref @libar-dev/platform-core/src/durability/outbox.ts` | ### `extract-shapes` -| Property | Value | -| ---------- | ----------------------------------------------------------------------------- | -| Format | csv | -| Purpose | TypeScript type names to extract from this file for documentation | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-extract-shapes DeciderInput, ValidationResult, ProcessViolation` | +| Property | Value | +| ---------- | ---------------------------------------------------------------------------- | +| Format | csv | +| Purpose | TypeScript type names to extract from this file for documentation | +| Required | No | +| Repeatable | No | +| Example | `@architect-extract-shapes DeciderInput, ValidationResult, ProcessViolation` | ### `shape` @@ -542,7 +542,7 @@ | Purpose | Marks declaration as documentable shape, optionally with group name | | Required | No | | Repeatable | No | -| Example | `@libar-docs-shape api-types` | +| Example | `@architect-shape api-types` | ### `arch-role` @@ -553,7 +553,7 @@ | Required | No | | Repeatable | No | | Valid Values | bounded-context, command-handler, projection, saga, process-manager, infrastructure, repository, decider, read-model, service | -| Example | `@libar-docs-arch-role projection` | +| Example | `@architect-arch-role projection` | ### `arch-context` @@ -563,7 +563,7 @@ | Purpose | Bounded context this component belongs to (for subgraph grouping) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-arch-context orders` | +| Example | `@architect-arch-context orders` | ### `arch-layer` @@ -574,7 +574,7 @@ | Required | No | | Repeatable | No | | Valid Values | domain, application, infrastructure | -| Example | `@libar-docs-arch-layer application` | +| Example | `@architect-arch-layer application` | ### `include` @@ -584,17 +584,17 @@ | Purpose | Cross-cutting document inclusion for content routing and diagram scoping | | Required | No | | Repeatable | No | -| Example | `@libar-docs-include reference-sample,codec-system` | +| Example | `@architect-include reference-sample,codec-system` | ### `target` -| Property | Value | -| ---------- | --------------------------------------------- | -| Format | value | -| Purpose | Target implementation path for stub files | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-target src/api/stub-resolver.ts` | +| Property | Value | +| ---------- | -------------------------------------------- | +| Format | value | +| Purpose | Target implementation path for stub files | +| Required | No | +| Repeatable | No | +| Example | `@architect-target src/api/stub-resolver.ts` | ### `since` @@ -604,7 +604,7 @@ | Purpose | Design session that created this pattern | | Required | No | | Repeatable | No | -| Example | `@libar-docs-since DS-A` | +| Example | `@architect-since DS-A` | ### `convention` @@ -615,7 +615,7 @@ | Required | No | | Repeatable | No | | Valid Values | testing-policy, fsm-rules, cli-patterns, output-format, pattern-naming, session-workflow, config-presets, annotation-system, pipeline-architecture, publishing, doc-generation, taxonomy-rules, codec-registry, process-guard-errors | -| Example | `@libar-docs-convention fsm-rules, testing-policy` | +| Example | `@architect-convention fsm-rules, testing-policy` | ### `claude-module` @@ -625,7 +625,7 @@ | Purpose | Module identifier for CLAUDE.md module generation (becomes filename) | | Required | No | | Repeatable | No | -| Example | `@libar-docs-claude-module process-guard` | +| Example | `@architect-claude-module process-guard` | ### `claude-section` @@ -636,17 +636,17 @@ | Required | No | | Repeatable | No | | Valid Values | core, delivery-process, testing, infrastructure, workflow | -| Example | `@libar-docs-claude-section delivery-process` | +| Example | `@architect-claude-section delivery-process` | ### `claude-tags` -| Property | Value | -| ---------- | ---------------------------------------------------------- | -| Format | csv | -| Purpose | Variation filtering tags for modular-claude-md inclusion | -| Required | No | -| Repeatable | No | -| Example | `@libar-docs-claude-tags core-mandatory, delivery-process` | +| Property | Value | +| ---------- | --------------------------------------------------------- | +| Format | csv | +| Purpose | Variation filtering tags for modular-claude-md inclusion | +| Required | No | +| Repeatable | No | +| Example | `@architect-claude-tags core-mandatory, delivery-process` | ### `sequence-orchestrator` @@ -656,7 +656,7 @@ | Purpose | Identifies the coordinator module for sequence diagram generation | | Required | No | | Repeatable | No | -| Example | `@libar-docs-sequence-orchestrator:init-cli` | +| Example | `@architect-sequence-orchestrator:init-cli` | ### `sequence-step` @@ -666,7 +666,7 @@ | Purpose | Explicit execution ordering number for sequence diagram steps | | Required | No | | Repeatable | No | -| Example | `@libar-docs-sequence-step:1` | +| Example | `@architect-sequence-step:1` | ### `sequence-module` @@ -676,7 +676,7 @@ | Purpose | Maps Rule to deliverable module(s) for sequence diagram participants | | Required | No | | Repeatable | No | -| Example | `@libar-docs-sequence-module:detect-context` | +| Example | `@architect-sequence-module:detect-context` | ### `sequence-error` @@ -686,7 +686,7 @@ | Purpose | Marks scenario as error/alternative path in sequence diagram | | Required | No | | Repeatable | No | -| Example | `@libar-docs-sequence-error` | +| Example | `@architect-sequence-error` | --- diff --git a/docs-live/validation/error-catalog.md b/docs-live/validation/error-catalog.md index 7f6e28b0..818ad379 100644 --- a/docs-live/validation/error-catalog.md +++ b/docs-live/validation/error-catalog.md @@ -21,12 +21,12 @@ Complete error messages and fix instructions for all 6 validation rules. ### `completed-protection` -| Property | Value | -| ----------- | ------------------------------------------------------------------ | -| Severity | error | -| Description | Completed specs require unlock-reason tag to modify | -| Cause | File has `completed` status but no `@libar-docs-unlock-reason` tag | -| Fix | Add `@libar-docs-unlock-reason:'your reason'` to proceed | +| Property | Value | +| ----------- | ----------------------------------------------------------------- | +| Severity | error | +| Description | Completed specs require unlock-reason tag to modify | +| Cause | File has `completed` status but no `@architect-unlock-reason` tag | +| Fix | Add `@architect-unlock-reason:'your reason'` to proceed | ### `invalid-status-transition` diff --git a/docs-live/validation/fsm-transitions.md b/docs-live/validation/fsm-transitions.md index 62512d5f..1eb46e8b 100644 --- a/docs-live/validation/fsm-transitions.md +++ b/docs-live/validation/fsm-transitions.md @@ -37,7 +37,7 @@ Complete transition matrix showing all valid state changes per PDR-005. ### From `completed` -**Terminal state** - no valid transitions. Use `@libar-docs-unlock-reason` to modify. +**Terminal state** - no valid transitions. Use `@architect-unlock-reason` to modify. ### From `deferred` diff --git a/docs-sources/annotation-guide.md b/docs-sources/annotation-guide.md index 31b5d270..e5e85db4 100644 --- a/docs-sources/annotation-guide.md +++ b/docs-sources/annotation-guide.md @@ -1,6 +1,6 @@ ## Getting Started -Every file that participates in the annotation system must have a `@libar-docs` opt-in marker. Files without this marker are invisible to the scanner. +Every file that participates in the annotation system must have a `@architect` opt-in marker. Files without this marker are invisible to the scanner. ### File-Level Opt-In @@ -8,10 +8,10 @@ Every file that participates in the annotation system must have a `@libar-docs` ```typescript /** - * @libar-docs - * @libar-docs-pattern MyPattern - * @libar-docs-status roadmap - * @libar-docs-uses EventStore, CommandBus + * @architect + * @architect-pattern MyPattern + * @architect-status roadmap + * @architect-uses EventStore, CommandBus * * ## My Pattern - Description */ @@ -20,10 +20,10 @@ Every file that participates in the annotation system must have a `@libar-docs` **Gherkin** -- file-level tags before `Feature:`: ```gherkin -@libar-docs -@libar-docs-pattern:MyPattern -@libar-docs-status:roadmap -@libar-docs-phase:14 +@architect +@architect-pattern:MyPattern +@architect-status:roadmap +@architect-phase:14 Feature: My Pattern **Problem:** @@ -32,11 +32,11 @@ Feature: My Pattern ### Tag Prefix by Preset -| Preset | Prefix | Categories | Use Case | -| ------------------------- | -------------- | ---------- | ----------------------------- | -| `libar-generic` (default) | `@libar-docs-` | 3 | Simple projects | -| `ddd-es-cqrs` | `@libar-docs-` | 21 | DDD/Event Sourcing monorepos | -| `generic` | `@docs-` | 3 | Simple projects, short prefix | +| Preset | Prefix | Categories | Use Case | +| ------------------------- | ------------- | ---------- | ----------------------------- | +| `libar-generic` (default) | `@architect-` | 3 | Simple projects | +| `ddd-es-cqrs` | `@architect-` | 21 | DDD/Event Sourcing monorepos | +| `generic` | `@docs-` | 3 | Simple projects, short prefix | ### Dual-Source Ownership @@ -57,8 +57,8 @@ List specific declaration names in the file-level JSDoc: ```typescript /** - * @libar-docs - * @libar-docs-extract-shapes MasterDatasetSchema, StatusGroupsSchema + * @architect + * @architect-extract-shapes MasterDatasetSchema, StatusGroupsSchema */ ``` @@ -68,8 +68,8 @@ Names appear in the generated output in the order listed. ```typescript /** - * @libar-docs - * @libar-docs-extract-shapes * + * @architect + * @architect-extract-shapes * */ ``` @@ -77,17 +77,17 @@ Wildcard must be the sole value -- `*, Foo` is invalid. ### Mode 3: Declaration-Level Tagging -Tag individual declarations with `@libar-docs-shape`, optionally with a group name: +Tag individual declarations with `@architect-shape`, optionally with a group name: ```typescript -/** @libar-docs-shape api-types */ +/** @architect-shape api-types */ export interface CommandInput { readonly aggregateId: string; readonly payload: unknown; } ``` -The optional group name (`api-types`) enables filtering in diagram scopes and product area documents via `@libar-docs-include`. +The optional group name (`api-types`) enables filtering in diagram scopes and product area documents via `@architect-include`. --- @@ -108,10 +108,10 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern MasterDataset - * @libar-docs-status completed - * @libar-docs-extract-shapes MasterDatasetSchema, StatusGroupsSchema, PhaseGroupSchema + * @architect + * @architect-pattern MasterDataset + * @architect-status completed + * @architect-extract-shapes MasterDatasetSchema, StatusGroupsSchema, PhaseGroupSchema */ ``` @@ -119,10 +119,10 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern DocumentGenerator - * @libar-docs-status completed - * @libar-docs-extract-shapes DocumentGenerator, GeneratorContext, GeneratorOutput + * @architect + * @architect-pattern DocumentGenerator + * @architect-status completed + * @architect-extract-shapes DocumentGenerator, GeneratorContext, GeneratorOutput */ ``` @@ -130,23 +130,23 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern TransformDataset - * @libar-docs-status completed - * @libar-docs-arch-context generator - * @libar-docs-arch-layer application - * @libar-docs-extract-shapes transformToMasterDataset, RuntimeMasterDataset + * @architect + * @architect-pattern TransformDataset + * @architect-status completed + * @architect-arch-context generator + * @architect-arch-layer application + * @architect-extract-shapes transformToMasterDataset, RuntimeMasterDataset */ ``` ### Gherkin Feature Files ```gherkin -@libar-docs -@libar-docs-pattern:ProcessGuardLinter -@libar-docs-status:roadmap -@libar-docs-phase:99 -@libar-docs-depends-on:StateMachine,ValidationRules +@architect +@architect-pattern:ProcessGuardLinter +@architect-status:roadmap +@architect-phase:99 +@architect-depends-on:StateMachine,ValidationRules Feature: Process Guard Linter Background: Deliverables @@ -195,16 +195,16 @@ Tags are organized into 12 functional groups. For the complete reference with al ```bash # Tag usage inventory (counts per tag and value) -pnpm process:query -- tags +pnpm architect:query -- tags -# Find files missing @libar-docs opt-in marker -pnpm process:query -- unannotated --path src/types +# Find files missing @architect opt-in marker +pnpm architect:query -- unannotated --path src/types # File inventory by type (TS, Gherkin, Stubs) -pnpm process:query -- sources +pnpm architect:query -- sources # Full pattern JSON including extractedShapes -pnpm process:query -- query getPattern MyPattern +pnpm architect:query -- query getPattern MyPattern # Generate complete tag reference npx generate-tag-taxonomy -o TAG_TAXONOMY.md -f @@ -214,11 +214,11 @@ npx generate-tag-taxonomy -o TAG_TAXONOMY.md -f ## Common Issues -| Symptom | Cause | Fix | -| ------------------------------- | ----------------------------------- | ------------------------------------------------ | -| Pattern not in scanner output | Missing `@libar-docs` opt-in marker | Add file-level `@libar-docs` JSDoc/tag | -| Shape shows `z.infer<>` wrapper | Extracted type alias, not schema | Use schema constant name (e.g., `FooSchema`) | -| Shape not in product area doc | Missing `@libar-docs-product-area` | Add product-area tag to file-level annotation | -| Declaration-level shape missing | No `@libar-docs-shape` on decl | Add `@libar-docs-shape` JSDoc to the declaration | -| Tag value rejected | Wrong format or invalid enum value | Check format type in taxonomy reference | -| Anti-pattern validation error | Tag on wrong source type | Move tag to correct source (TS vs Gherkin) | +| Symptom | Cause | Fix | +| ------------------------------- | ---------------------------------- | ----------------------------------------------- | +| Pattern not in scanner output | Missing `@architect` opt-in marker | Add file-level `@architect` JSDoc/tag | +| Shape shows `z.infer<>` wrapper | Extracted type alias, not schema | Use schema constant name (e.g., `FooSchema`) | +| Shape not in product area doc | Missing `@architect-product-area` | Add product-area tag to file-level annotation | +| Declaration-level shape missing | No `@architect-shape` on decl | Add `@architect-shape` JSDoc to the declaration | +| Tag value rejected | Wrong format or invalid enum value | Check format type in taxonomy reference | +| Anti-pattern validation error | Tag on wrong source type | Move tag to correct source (TS vs Gherkin) | diff --git a/docs-sources/configuration-guide.md b/docs-sources/configuration-guide.md index 7db4889b..5912a059 100644 --- a/docs-sources/configuration-guide.md +++ b/docs-sources/configuration-guide.md @@ -1,14 +1,14 @@ ## Quick Reference -| Preset | Tag Prefix | Categories | Use Case | -| ----------------------------- | -------------- | ---------- | ------------------------------------ | -| **`libar-generic`** (default) | `@libar-docs-` | 3 | Simple projects (this package) | -| `generic` | `@docs-` | 3 | Simple projects with `@docs-` prefix | -| `ddd-es-cqrs` | `@libar-docs-` | 21 | DDD/Event Sourcing architectures | +| Preset | Tag Prefix | Categories | Use Case | +| ----------------------------- | ------------- | ---------- | ------------------------------------ | +| **`libar-generic`** (default) | `@architect-` | 3 | Simple projects (this package) | +| `generic` | `@docs-` | 3 | Simple projects with `@docs-` prefix | +| `ddd-es-cqrs` | `@architect-` | 21 | DDD/Event Sourcing architectures | ```typescript -// delivery-process.config.ts -import { defineConfig } from '@libar-dev/delivery-process/config'; +// architect.config.ts +import { defineConfig } from '@libar-dev/architect/config'; // Default: libar-generic preset (simple 3-category taxonomy) export default defineConfig({ @@ -29,7 +29,7 @@ export default defineConfig({ | Preset | Use When | Categories | | --------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------- | -| `libar-generic` | Simple projects, standard `@libar-docs-` prefix | 3 (core, api, infra) | +| `libar-generic` | Simple projects, standard `@architect-` prefix | 3 (core, api, infra) | | `generic` | Prefer shorter `@docs-` prefix | 3 (core, api, infra) | | `ddd-es-cqrs` | DDD architecture with bounded contexts, event sourcing, CQRS | 21 (domain, ddd, bounded-context, event-sourcing, decider, cqrs, saga, projection, etc.) | @@ -49,26 +49,26 @@ All entry points default to `libar-generic`: ## Unified Config File -The `defineConfig()` function centralizes taxonomy, sources, output, and generator overrides in a single `delivery-process.config.ts` file. CLI tools discover this file automatically. +The `defineConfig()` function centralizes taxonomy, sources, output, and generator overrides in a single `architect.config.ts` file. CLI tools discover this file automatically. ### Discovery Order -1. Current directory: check `delivery-process.config.ts`, then `.js` +1. Current directory: check `architect.config.ts`, then `.js` 2. Walk up to repo root (`.git` folder), checking each directory -3. Fall back to libar-generic preset (3 categories, `@libar-docs-` prefix) +3. Fall back to libar-generic preset (3 categories, `@architect-` prefix) ### Config File Format ```typescript -// delivery-process.config.ts -import { defineConfig } from '@libar-dev/delivery-process/config'; +// architect.config.ts +import { defineConfig } from '@libar-dev/architect/config'; export default defineConfig({ preset: 'libar-generic', sources: { typescript: ['src/**/*.ts'], - stubs: ['delivery-process/stubs/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + stubs: ['architect/stubs/**/*.ts'], + features: ['architect/specs/*.feature'], }, output: { directory: 'docs-generated', @@ -104,15 +104,15 @@ export default defineConfig({ preset: 'libar-generic', sources: { typescript: ['src/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + features: ['architect/specs/*.feature'], }, output: { directory: 'docs-generated', overwrite: true }, generatorOverrides: { changelog: { - additionalFeatures: ['delivery-process/decisions/*.feature'], + additionalFeatures: ['architect/decisions/*.feature'], }, 'doc-from-decision': { - replaceFeatures: ['delivery-process/decisions/*.feature'], + replaceFeatures: ['architect/decisions/*.feature'], }, }, }); @@ -133,10 +133,10 @@ export default defineConfig({ ``` my-monorepo/ - delivery-process.config.ts # Repo-level: ddd-es-cqrs + architect.config.ts # Repo-level: ddd-es-cqrs packages/ my-package/ - delivery-process.config.ts # Package-level: generic + architect.config.ts # Package-level: generic ``` CLI tools use the nearest config file to the working directory. Each package can have its own preset and source globs. @@ -199,7 +199,7 @@ export default defineConfig({ For tools that need to load configuration files: ```typescript -import { loadProjectConfig } from '@libar-dev/delivery-process/config'; +import { loadProjectConfig } from '@libar-dev/architect/config'; const result = await loadProjectConfig(process.cwd()); @@ -209,7 +209,7 @@ if (!result.ok) { } const resolved = result.value; -// resolved.instance - DeliveryProcessInstance (registry + regexBuilders) +// resolved.instance - ArchitectInstance (registry + regexBuilders) // resolved.project - ResolvedProjectConfig (sources, output, generators) // resolved.isDefault - true if no config file found // resolved.configPath - config file path (if found) @@ -218,7 +218,7 @@ const resolved = result.value; For per-generator source resolution: ```typescript -import { mergeSourcesForGenerator } from '@libar-dev/delivery-process/config'; +import { mergeSourcesForGenerator } from '@libar-dev/architect/config'; const effectiveSources = mergeSourcesForGenerator( resolved.project.sources, @@ -233,12 +233,12 @@ const effectiveSources = mergeSourcesForGenerator( ## Backward Compatibility -The legacy `createDeliveryProcess()` API is still exported and supported. Config files using the old format are detected automatically by `loadProjectConfig()` and wrapped in a `ResolvedConfig` with default project settings. +The legacy `createArchitect()` API is still exported and supported. Config files using the old format are detected automatically by `loadProjectConfig()` and wrapped in a `ResolvedConfig` with default project settings. ```typescript // Legacy format (still works) -import { createDeliveryProcess } from '@libar-dev/delivery-process'; -export default createDeliveryProcess({ preset: 'ddd-es-cqrs' }); +import { createArchitect } from '@libar-dev/architect'; +export default createArchitect({ preset: 'ddd-es-cqrs' }); ``` New projects should use `defineConfig()` for the unified configuration experience. diff --git a/docs-sources/gherkin-patterns.md b/docs-sources/gherkin-patterns.md index f10f6e82..32f5ceb7 100644 --- a/docs-sources/gherkin-patterns.md +++ b/docs-sources/gherkin-patterns.md @@ -5,10 +5,10 @@ Roadmap specs define planned work with Problem/Solution descriptions and a Background deliverables table. ```gherkin -@libar-docs -@libar-docs-pattern:ProcessGuardLinter -@libar-docs-status:roadmap -@libar-docs-phase:99 +@architect +@architect-pattern:ProcessGuardLinter +@architect-status:roadmap +@architect-phase:99 Feature: Process Guard Linter **Problem:** @@ -32,9 +32,9 @@ Feature: Process Guard Linter **Key elements:** -- `@libar-docs` -- bare opt-in marker (required) -- `@libar-docs-pattern:Name` -- unique identifier (required) -- `@libar-docs-status:roadmap` -- FSM state +- `@architect` -- bare opt-in marker (required) +- `@architect-pattern:Name` -- unique identifier (required) +- `@architect-status:roadmap` -- FSM state - `**Problem:**` / `**Solution:**` -- extracted by generators - Background deliverables table -- tracks implementation progress @@ -102,7 +102,7 @@ Test features focus on behavior verification with section dividers for organizat ```gherkin @behavior @scanner-core -@libar-docs-pattern:ScannerCore +@architect-pattern:ScannerCore Feature: Scanner Core Integration Background: @@ -155,11 +155,11 @@ Use `"""typescript` for code blocks. Essential when content contains pipes or sp Scenario: Extract directive from TypeScript Given a file with content: """typescript - /** @libar-docs */ + /** @architect */ export function authenticate() {} """ When scanning the file - Then directive should have tag "@libar-docs-core" + Then directive should have tag "@architect-core" ``` --- @@ -207,7 +207,7 @@ Feature files serve dual purposes: **executable specs** and **documentation sour | DocStrings (`"""typescript`) | Brief examples (5-10 lines), current/target state comparison | | Code stub reference | Complex APIs, interfaces, full implementations | -Code stubs are annotated TypeScript files with `throw new Error("not yet implemented")`, located in `delivery-process/stubs/{pattern-name}/`. +Code stubs are annotated TypeScript files with `throw new Error("not yet implemented")`, located in `architect/stubs/{pattern-name}/`. ### Valid Rich Content @@ -237,15 +237,15 @@ Code stubs are annotated TypeScript files with `throw new Error("not yet impleme **Tag values cannot contain spaces.** Use hyphens: -| Invalid | Valid | -| -------------------------------- | ------------------------------- | -| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | -| `@libar-docs-pattern:My Pattern` | `@libar-docs-pattern:MyPattern` | +| Invalid | Valid | +| ------------------------------- | ------------------------------ | +| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | +| `@architect-pattern:My Pattern` | `@architect-pattern:MyPattern` | For values with spaces, use the `quoted-value` format where supported: ```gherkin -@libar-docs-usecase "When handling command failures" +@architect-usecase "When handling command failures" ``` --- diff --git a/docs-sources/process-api-recipes.md b/docs-sources/process-api-recipes.md index f15d03be..b36d6753 100644 --- a/docs-sources/process-api-recipes.md +++ b/docs-sources/process-api-recipes.md @@ -12,16 +12,16 @@ The CLI has two output modes: - **Text commands** (6) -- formatted for terminal reading or AI context. Use `===` section markers for structure. - **JSON commands** (12+) -- wrapped in a `QueryResult` envelope. Pipeable to `jq`. -Run `process-api --help` for the full command reference with all flags and 26 available API methods. +Run `architect --help` for the full command reference with all flags and 26 available API methods. ## Quick Start The recommended session startup is three commands: ```bash -pnpm process:query -- overview -pnpm process:query -- scope-validate MyPattern implement -pnpm process:query -- context MyPattern --session implement +pnpm architect:query -- overview +pnpm architect:query -- scope-validate MyPattern implement +pnpm architect:query -- context MyPattern --session implement ``` Example `overview` output: @@ -38,7 +38,7 @@ Phase 25: DataAPIStubIntegration (1 active) StepLintExtendedRules blocked by: StepLintVitestCucumber === DATA API === -pnpm process:query -- +pnpm architect:query -- overview, context, scope-validate, dep-tree, list, stubs, files, rules, arch blocking ``` diff --git a/docs-sources/process-guard.md b/docs-sources/process-guard.md index 880ee0fd..b3d3292a 100644 --- a/docs-sources/process-guard.md +++ b/docs-sources/process-guard.md @@ -22,9 +22,9 @@ | Situation | Solution | Example | | ----------------------------- | ---------------------------------- | --------------------------------------------- | -| Fix bug in completed spec | Add `@*-unlock-reason:'reason'` | `@libar-docs-unlock-reason:'Fix typo'` | -| Modify outside session scope | `--ignore-session` flag | `lint-process --staged --ignore-session` | -| CI treats warnings as errors | `--strict` flag | `lint-process --all --strict` | +| Fix bug in completed spec | Add `@*-unlock-reason:'reason'` | `@architect-unlock-reason:'Fix typo'` | +| Modify outside session scope | `--ignore-session` flag | `architect-guard --staged --ignore-session` | +| CI treats warnings as errors | `--strict` flag | `architect-guard --all --strict` | | Skip workflow (legacy import) | Multiple transitions in one commit | Set `roadmap` then `completed` in same commit | --- @@ -64,11 +64,11 @@ lint-process [options] ### Examples ```bash -lint-process --staged # Pre-commit hook (recommended) -lint-process --all --strict # CI pipeline with strict mode -lint-process --file specs/my-feature.feature # Validate specific file -lint-process --staged --show-state # Debug: see derived state -lint-process --staged --ignore-session # Override session scope +architect-guard --staged # Pre-commit hook (recommended) +architect-guard --all --strict # CI pipeline with strict mode +architect-guard --file specs/my-feature.feature # Validate specific file +architect-guard --staged --show-state # Debug: see derived state +architect-guard --staged --ignore-session # Override session scope ``` --- @@ -81,7 +81,7 @@ Configure Process Guard as a pre-commit hook using Husky. #!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh" -npx lint-process --staged +npx architect-guard --staged ``` ### package.json Scripts @@ -89,8 +89,8 @@ npx lint-process --staged ```json { "scripts": { - "lint:process": "lint-process --staged", - "lint:process:ci": "lint-process --all --strict" + "lint:process": "architect-guard --staged", + "lint:process:ci": "architect-guard --all --strict" } } ``` @@ -108,7 +108,7 @@ import { validateChanges, hasErrors, summarizeResult, -} from '@libar-dev/delivery-process/lint'; +} from '@libar-dev/architect/lint'; // 1. Derive state from annotations const state = (await deriveProcessState({ baseDir: '.' })).value; diff --git a/docs-sources/session-workflow-guide.md b/docs-sources/session-workflow-guide.md index 9f2aa185..2fbcbc5b 100644 --- a/docs-sources/session-workflow-guide.md +++ b/docs-sources/session-workflow-guide.md @@ -35,7 +35,7 @@ graph TD Implementation sessions MUST follow this strict 5-step sequence. Skipping steps causes Process Guard rejection at commit time. 1. **Transition to `active` FIRST** (before any code changes) -2. **Create executable spec stubs** (if `@libar-docs-executable-specs` present) +2. **Create executable spec stubs** (if `@architect-executable-specs` present) 3. **For each deliverable:** implement, test, update status to `complete` 4. **Transition to `completed`** (only when ALL deliverables done) 5. **Regenerate docs:** `pnpm docs:all` @@ -58,8 +58,8 @@ Implementation sessions MUST follow this strict 5-step sequence. Skipping steps ### Context Gathering ```bash -pnpm process:query -- overview # Project health -pnpm process:query -- list --status roadmap --names-only # Available patterns +pnpm architect:query -- overview # Project health +pnpm architect:query -- list --status roadmap --names-only # Available patterns ``` ### Planning Checklist @@ -69,7 +69,7 @@ pnpm process:query -- list --status roadmap --names-only # Available patter - [ ] **Structure the feature** with Problem/Solution, tags, deliverables table - [ ] **Convert constraints to Rule: blocks** with Invariant/Rationale - [ ] **Add scenarios** per Rule: 1 happy-path + 1 validation minimum -- [ ] **Set executable specs location** via `@libar-docs-executable-specs` tag +- [ ] **Set executable specs location** via `@architect-executable-specs` tag ### Planning Do NOT @@ -86,9 +86,9 @@ pnpm process:query -- list --status roadmap --names-only # Available patter ### Context Gathering ```bash -pnpm process:query -- context --session design # Full context bundle -pnpm process:query -- dep-tree # Dependency chain -pnpm process:query -- stubs # Existing design stubs +pnpm architect:query -- context --session design # Full context bundle +pnpm architect:query -- dep-tree # Dependency chain +pnpm architect:query -- stubs # Existing design stubs ``` ### When to Use Design Sessions @@ -101,12 +101,12 @@ pnpm process:query -- stubs # Existing design ### Design Checklist -- [ ] **Record decisions** as PDR `.feature` files in `delivery-process/decisions/` +- [ ] **Record decisions** as PDR `.feature` files in `architect/decisions/` - [ ] **Document options** with at least 2-3 approaches and pros/cons - [ ] **Get approval** from user on recommended approach -- [ ] **Create code stubs** in `delivery-process/stubs/{pattern-name}/` +- [ ] **Create code stubs** in `architect/stubs/{pattern-name}/` - [ ] **Verify stub identifier spelling** before committing -- [ ] **List canonical helpers** in `@libar-docs-uses` tags +- [ ] **List canonical helpers** in `@architect-uses` tags ### Design Do NOT @@ -136,8 +136,8 @@ pnpm process:query -- stubs # Existing design For multi-session work, capture state at session boundaries using the Process Data API. ```bash -pnpm process:query -- handoff --pattern -pnpm process:query -- handoff --pattern --git # include recent commits +pnpm architect:query -- handoff --pattern +pnpm architect:query -- handoff --pattern --git # include recent commits ``` --- diff --git a/docs-sources/validation-tools-guide.md b/docs-sources/validation-tools-guide.md index c0d5da69..cdc4dea6 100644 --- a/docs-sources/validation-tools-guide.md +++ b/docs-sources/validation-tools-guide.md @@ -14,17 +14,17 @@ Need cross-source or DoD validation? Yes -> validate-patterns Running pre-commit hook? - lint-process --staged (default) + architect-guard --staged (default) ``` ## Command Summary -| Command | Purpose | When to Use | -| ------------------- | --------------------------------- | --------------------------------------------- | -| `lint-patterns` | Annotation quality | Ensure patterns have required tags | -| `lint-steps` | vitest-cucumber compatibility | After writing/modifying feature or step files | -| `lint-process` | FSM workflow enforcement | Pre-commit hooks, CI pipelines | -| `validate-patterns` | Cross-source + DoD + anti-pattern | Release validation, comprehensive | +| Command | Purpose | When to Use | +| ------------------------- | --------------------------------- | --------------------------------------------- | +| `architect-lint-patterns` | Annotation quality | Ensure patterns have required tags | +| `architect-lint-steps` | vitest-cucumber compatibility | After writing/modifying feature or step files | +| `architect-guard` | FSM workflow enforcement | Pre-commit hooks, CI pipelines | +| `architect-validate` | Cross-source + DoD + anti-pattern | Release validation, comprehensive | --- @@ -117,8 +117,8 @@ pnpm lint:steps --strict # CI FSM validation for delivery workflow. Enforces status transitions and protection levels. ```bash -npx lint-process --staged # Pre-commit (default) -npx lint-process --all --strict # CI pipeline +npx architect-guard --staged # Pre-commit (default) +npx architect-guard --all --strict # CI pipeline ``` **What it validates:** @@ -197,8 +197,8 @@ For patterns with `completed` status, checks: "lint:patterns": "lint-patterns -i 'src/**/*.ts'", "lint:steps": "lint-steps", "lint:steps:ci": "lint-steps --strict", - "lint:process": "lint-process --staged", - "lint:process:ci": "lint-process --all --strict", + "lint:process": "architect-guard --staged", + "lint:process:ci": "architect-guard --all --strict", "validate:all": "validate-patterns -i 'src/**/*.ts' -F 'specs/**/*.feature' --dod --anti-patterns" } } @@ -207,7 +207,7 @@ For patterns with `completed` status, checks: ### Pre-commit Hook ```bash -npx lint-process --staged +npx architect-guard --staged ``` ### GitHub Actions @@ -241,14 +241,14 @@ All validation tools expose programmatic APIs: ```typescript // Pattern linting -import { lintFiles, hasFailures } from '@libar-dev/delivery-process/lint'; +import { lintFiles, hasFailures } from '@libar-dev/architect/lint'; // Step linting -import { runStepLint, STEP_LINT_RULES } from '@libar-dev/delivery-process/lint'; +import { runStepLint, STEP_LINT_RULES } from '@libar-dev/architect/lint'; // Process guard -import { deriveProcessState, validateChanges } from '@libar-dev/delivery-process/lint'; +import { deriveProcessState, validateChanges } from '@libar-dev/architect/lint'; // Anti-patterns and DoD -import { detectAntiPatterns, validateDoD } from '@libar-dev/delivery-process/validation'; +import { detectAntiPatterns, validateDoD } from '@libar-dev/architect/validation'; ``` diff --git a/docs/ANNOTATION-GUIDE.md b/docs/ANNOTATION-GUIDE.md index 23be8da7..e9cbca6b 100644 --- a/docs/ANNOTATION-GUIDE.md +++ b/docs/ANNOTATION-GUIDE.md @@ -12,16 +12,16 @@ For the **complete tag reference** (all 50+ tags with formats, values, and examp ### File-Level Opt-In -Every file that participates in the annotation system must have a `@libar-docs` opt-in marker. Files without this marker are invisible to the scanner. +Every file that participates in the annotation system must have a `@architect` opt-in marker. Files without this marker are invisible to the scanner. **TypeScript** — file-level JSDoc block: ```typescript /** - * @libar-docs - * @libar-docs-pattern MyPattern - * @libar-docs-status roadmap - * @libar-docs-uses EventStore, CommandBus + * @architect + * @architect-pattern MyPattern + * @architect-status roadmap + * @architect-uses EventStore, CommandBus * * ## My Pattern - Description * @@ -32,11 +32,11 @@ Every file that participates in the annotation system must have a `@libar-docs` **Gherkin** — file-level tags before `Feature:`: ```gherkin -@libar-docs -@libar-docs-pattern:MyPattern -@libar-docs-status:roadmap -@libar-docs-phase:14 -@libar-docs-depends-on:EventStore,CommandBus +@architect +@architect-pattern:MyPattern +@architect-status:roadmap +@architect-phase:14 +@architect-depends-on:EventStore,CommandBus Feature: My Pattern **Problem:** @@ -45,13 +45,13 @@ Feature: My Pattern ### Tag Prefix by Preset -The tag prefix is configurable via presets. All examples in this guide use the default `@libar-docs-` prefix. +The tag prefix is configurable via presets. All examples in this guide use the default `@architect-` prefix. -| Preset | Prefix | Categories | Use Case | -| ------------------------- | -------------- | ---------- | ----------------------------- | -| `libar-generic` (default) | `@libar-docs-` | 3 | Simple projects | -| `ddd-es-cqrs` | `@libar-docs-` | 21 | DDD/Event Sourcing monorepos | -| `generic` | `@docs-` | 3 | Simple projects, short prefix | +| Preset | Prefix | Categories | Use Case | +| ------------------------- | ------------- | ---------- | ----------------------------- | +| `libar-generic` (default) | `@architect-` | 3 | Simple projects | +| `ddd-es-cqrs` | `@architect-` | 21 | DDD/Event Sourcing monorepos | +| `generic` | `@docs-` | 3 | Simple projects, short prefix | See [CONFIGURATION.md](./CONFIGURATION.md) for preset details and custom configuration. @@ -78,8 +78,8 @@ List specific declaration names in the file-level JSDoc: ```typescript /** - * @libar-docs - * @libar-docs-extract-shapes MasterDatasetSchema, StatusGroupsSchema, RelationshipEntry + * @architect + * @architect-extract-shapes MasterDatasetSchema, StatusGroupsSchema, RelationshipEntry */ ``` @@ -91,8 +91,8 @@ Extract all exported declarations automatically: ```typescript /** - * @libar-docs - * @libar-docs-extract-shapes * + * @architect + * @architect-extract-shapes * */ ``` @@ -100,20 +100,20 @@ Wildcard must be the sole value — `*, Foo` is invalid. ### Mode 3: Declaration-Level Tagging -Tag individual declarations with `@libar-docs-shape`, optionally with a group name: +Tag individual declarations with `@architect-shape`, optionally with a group name: ```typescript -/** @libar-docs-shape api-types */ +/** @architect-shape api-types */ export interface CommandInput { readonly aggregateId: string; readonly payload: unknown; } -/** @libar-docs-shape api-types */ +/** @architect-shape api-types */ export type CommandResult = Result; ``` -Declaration-level shapes work on both exported and non-exported declarations. The optional group name (`api-types`) enables filtering in diagram scopes and product area documents via `@libar-docs-include`. +Declaration-level shapes work on both exported and non-exported declarations. The optional group name (`api-types`) enables filtering in diagram scopes and product area documents via `@architect-include`. ### Critical Gotcha: Zod Schemas @@ -132,10 +132,10 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern MasterDataset - * @libar-docs-status completed - * @libar-docs-extract-shapes MasterDatasetSchema, StatusGroupsSchema, PhaseGroupSchema + * @architect + * @architect-pattern MasterDataset + * @architect-status completed + * @architect-extract-shapes MasterDatasetSchema, StatusGroupsSchema, PhaseGroupSchema */ ``` @@ -143,10 +143,10 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern DocumentGenerator - * @libar-docs-status completed - * @libar-docs-extract-shapes DocumentGenerator, GeneratorContext, GeneratorOutput + * @architect + * @architect-pattern DocumentGenerator + * @architect-status completed + * @architect-extract-shapes DocumentGenerator, GeneratorContext, GeneratorOutput */ ``` @@ -154,23 +154,23 @@ For Zod files, extract the **schema constant** (with `Schema` suffix), not the i ```typescript /** - * @libar-docs - * @libar-docs-pattern TransformDataset - * @libar-docs-status completed - * @libar-docs-arch-context generator - * @libar-docs-arch-layer application - * @libar-docs-extract-shapes transformToMasterDataset, RuntimeMasterDataset + * @architect + * @architect-pattern TransformDataset + * @architect-status completed + * @architect-arch-context generator + * @architect-arch-layer application + * @architect-extract-shapes transformToMasterDataset, RuntimeMasterDataset */ ``` ### Gherkin Feature Files ```gherkin -@libar-docs -@libar-docs-pattern:ProcessGuardLinter -@libar-docs-status:roadmap -@libar-docs-phase:99 -@libar-docs-depends-on:StateMachine,ValidationRules +@architect +@architect-pattern:ProcessGuardLinter +@architect-status:roadmap +@architect-phase:99 +@architect-depends-on:StateMachine,ValidationRules Feature: Process Guard Linter Background: Deliverables @@ -215,14 +215,14 @@ Tags are organized into 12 functional groups. This table shows representative ta ### Format Types -| Format | Syntax Example | Parsing | -| -------------- | ------------------------------ | ------------------------------ | -| `flag` | `@libar-docs-core` | Boolean presence (no value) | -| `value` | `@libar-docs-pattern Foo` | Simple string | -| `enum` | `@libar-docs-status roadmap` | Constrained to predefined list | -| `csv` | `@libar-docs-uses A, B, C` | Comma-separated values | -| `number` | `@libar-docs-phase 14` | Numeric value | -| `quoted-value` | `@libar-docs-title:'My Title'` | Preserves spaces in value | +| Format | Syntax Example | Parsing | +| -------------- | ----------------------------- | ------------------------------ | +| `flag` | `@architect-core` | Boolean presence (no value) | +| `value` | `@architect-pattern Foo` | Simple string | +| `enum` | `@architect-status roadmap` | Constrained to predefined list | +| `csv` | `@architect-uses A, B, C` | Comma-separated values | +| `number` | `@architect-phase 14` | Numeric value | +| `quoted-value` | `@architect-title:'My Title'` | Preserves spaces in value | --- @@ -232,16 +232,16 @@ Tags are organized into 12 functional groups. This table shows representative ta ```bash # Tag usage inventory (counts per tag and value) -pnpm process:query -- tags +pnpm architect:query -- tags -# Find files missing @libar-docs opt-in marker -pnpm process:query -- unannotated --path src/types +# Find files missing @architect opt-in marker +pnpm architect:query -- unannotated --path src/types # File inventory by type (TS, Gherkin, Stubs) -pnpm process:query -- sources +pnpm architect:query -- sources # Full pattern JSON including extractedShapes -pnpm process:query -- query getPattern MyPattern +pnpm architect:query -- query getPattern MyPattern # Generate complete tag reference npx generate-tag-taxonomy -o TAG_TAXONOMY.md -f @@ -249,14 +249,14 @@ npx generate-tag-taxonomy -o TAG_TAXONOMY.md -f ### Common Issues -| Symptom | Cause | Fix | -| ------------------------------- | ----------------------------------- | ------------------------------------------------ | -| Pattern not in scanner output | Missing `@libar-docs` opt-in marker | Add file-level `@libar-docs` JSDoc/tag | -| Shape shows `z.infer<>` wrapper | Extracted type alias, not schema | Use schema constant name (e.g., `FooSchema`) | -| Shape not in product area doc | Missing `@libar-docs-product-area` | Add product-area tag to file-level annotation | -| Declaration-level shape missing | No `@libar-docs-shape` on decl | Add `@libar-docs-shape` JSDoc to the declaration | -| Tag value rejected | Wrong format or invalid enum value | Check format type in taxonomy reference | -| Anti-pattern validation error | Tag on wrong source type | Move tag to correct source (TS vs Gherkin) | +| Symptom | Cause | Fix | +| ------------------------------- | ---------------------------------- | ----------------------------------------------- | +| Pattern not in scanner output | Missing `@architect` opt-in marker | Add file-level `@architect` JSDoc/tag | +| Shape shows `z.infer<>` wrapper | Extracted type alias, not schema | Use schema constant name (e.g., `FooSchema`) | +| Shape not in product area doc | Missing `@architect-product-area` | Add product-area tag to file-level annotation | +| Declaration-level shape missing | No `@architect-shape` on decl | Add `@architect-shape` JSDoc to the declaration | +| Tag value rejected | Wrong format or invalid enum value | Check format type in taxonomy reference | +| Anti-pattern validation error | Tag on wrong source type | Move tag to correct source (TS vs Gherkin) | --- diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md index dad5be57..8d6799a1 100644 --- a/docs/ARCHITECTURE.md +++ b/docs/ARCHITECTURE.md @@ -1,10 +1,10 @@ -# Architecture: @libar-dev/delivery-process +# Architecture: @libar-dev/architect > **Deprecated:** Architecture documentation is now auto-generated across multiple reference docs: [Architecture Diagram](../docs-live/ARCHITECTURE.md), [Architecture Codecs](../docs-live/reference/ARCHITECTURE-CODECS.md), and [Architecture Types](../docs-live/reference/ARCHITECTURE-TYPES.md). This file is preserved for reference only. > **Code-Driven Documentation Generator with Codec-Based Transformation Pipeline** -This document describes the architecture of the `@libar-dev/delivery-process` package, a documentation generator that extracts patterns from TypeScript and Gherkin sources, transforms them through a unified pipeline, and renders them as markdown via typed codecs. +This document describes the architecture of the `@libar-dev/architect` package, a documentation generator that extracts patterns from TypeScript and Gherkin sources, transforms them through a unified pipeline, and renders them as markdown via typed codecs. --- @@ -31,9 +31,9 @@ This document describes the architecture of the `@libar-dev/delivery-process` pa ### What This Package Does -The `@libar-dev/delivery-process` package generates LLM-optimized documentation from dual sources: +The `@libar-dev/architect` package generates LLM-optimized documentation from dual sources: -- **TypeScript code** with configurable JSDoc annotations (e.g., `@docs-*` or `@libar-docs-*`) +- **TypeScript code** with configurable JSDoc annotations (e.g., `@docs-*` or `@architect-*`) - **Gherkin feature files** with matching tags The tag prefix is configurable via presets or custom configuration (see [Configuration Architecture](#configuration-architecture)). @@ -76,8 +76,8 @@ The package supports configurable tag prefixes via the Configuration API. ### Entry Point ```typescript -// delivery-process.config.ts -import { defineConfig } from '@libar-dev/delivery-process/config'; +// architect.config.ts +import { defineConfig } from '@libar-dev/architect/config'; export default defineConfig({ preset: 'libar-generic', @@ -127,12 +127,12 @@ defineConfig(userConfig) | File | Purpose | | ------------------------------------- | ---------------------------------------------------------- | | `src/config/define-config.ts` | `defineConfig()` identity function for type-safe authoring | -| `src/config/project-config.ts` | `DeliveryProcessProjectConfig`, `ResolvedConfig` types | +| `src/config/project-config.ts` | `ArchitectProjectConfig`, `ResolvedConfig` types | | `src/config/project-config-schema.ts` | Zod validation schema, `isProjectConfig()` type guard | | `src/config/resolve-config.ts` | `resolveProjectConfig()` — defaults + taxonomy resolution | | `src/config/merge-sources.ts` | `mergeSourcesForGenerator()` — per-generator sources | | `src/config/config-loader.ts` | `loadProjectConfig()` — file discovery + loading | -| `src/config/factory.ts` | `createDeliveryProcess()` — taxonomy factory (internal) | +| `src/config/factory.ts` | `createArchitect()` — taxonomy factory (internal) | | `src/config/presets.ts` | GENERIC_PRESET, LIBAR_GENERIC_PRESET, DDD_ES_CQRS_PRESET | > **See:** [CONFIGURATION.md](./CONFIGURATION.md) for usage examples and API reference. @@ -147,16 +147,16 @@ The pipeline has two entry points. The orchestrator (`src/generators/orchestrato **Purpose:** Discover source files and parse them into structured AST representations. -| Scanner Type | Input | Output | Key File | -| ------------ | ------------------------------ | ---------------------- | -------------------------------- | -| TypeScript | `.ts` files with `@libar-docs` | `ScannedFile[]` | `src/scanner/pattern-scanner.ts` | -| Gherkin | `.feature` files | `ScannedGherkinFile[]` | `src/scanner/gherkin-scanner.ts` | +| Scanner Type | Input | Output | Key File | +| ------------ | ----------------------------- | ---------------------- | -------------------------------- | +| TypeScript | `.ts` files with `@architect` | `ScannedFile[]` | `src/scanner/pattern-scanner.ts` | +| Gherkin | `.feature` files | `ScannedGherkinFile[]` | `src/scanner/gherkin-scanner.ts` | **TypeScript Scanning Flow:** ``` findFilesToScan() → hasFileOptIn() → parseFileDirectives() -(glob patterns) (@libar-docs check) (AST extraction) +(glob patterns) (@architect check) (AST extraction) ``` **Gherkin Scanning Flow:** @@ -177,13 +177,13 @@ findFeatureFiles() → parseFeatureFile() → extractPatternTags() **Shape Extraction Modes:** -| Mode | Trigger | Behavior | -| ----------------------- | -------------------------------------- | ---------------------------------------------- | -| Explicit names | `@libar-docs-extract-shapes Foo, Bar` | Extracts named declarations only | -| Wildcard auto-discovery | `@libar-docs-extract-shapes *` | Extracts all exported declarations from file | -| Declaration-level | `@libar-docs-shape` on individual decl | Extracts tagged declarations (exported or not) | +| Mode | Trigger | Behavior | +| ----------------------- | ------------------------------------- | ---------------------------------------------- | +| Explicit names | `@architect-extract-shapes Foo, Bar` | Extracts named declarations only | +| Wildcard auto-discovery | `@architect-extract-shapes *` | Extracts all exported declarations from file | +| Declaration-level | `@architect-shape` on individual decl | Extracts tagged declarations (exported or not) | -Shapes now include `params`, `returns`, and `throws` fields (parsed from `@param`/`@returns`/`@throws` JSDoc tags on function shapes), and an optional `group` field from the `@libar-docs-shape` tag value. `ExportInfo` includes an optional `signature` field for function/const/class declarations. +Shapes now include `params`, `returns`, and `throws` fields (parsed from `@param`/`@returns`/`@throws` JSDoc tags on function shapes), and an optional `group` field from the `@architect-shape` tag value. `ExportInfo` includes an optional `signature` field for function/const/class declarations. ```typescript interface ExtractedPattern { @@ -278,11 +278,11 @@ function buildMasterDataset( **Consumer Table:** -| Consumer | `mergeConflictStrategy` | Error Handling | -| ------------------- | -------------------------------- | --------------------------- | -| `process-api` | `'fatal'` | Maps to `process.exit(1)` | -| `validate-patterns` | `'concatenate'` | Falls back to concatenation | -| `orchestrator` | inline (equivalent to `'fatal'`) | Inline error reporting | +| Consumer | `mergeConflictStrategy` | Error Handling | +| -------------------- | -------------------------------- | --------------------------- | +| `architect` | `'fatal'` | Maps to `process.exit(1)` | +| `architect-validate` | `'concatenate'` | Falls back to concatenation | +| `orchestrator` | inline (equivalent to `'fatal'`) | Inline error reporting | **Consumer Layers (ADR-006):** @@ -392,12 +392,12 @@ interface MasterDataset { string, { // Forward relationships (from annotations) - uses: string[]; // @libar-docs-uses - dependsOn: string[]; // @libar-docs-depends-on - implementsPatterns: string[]; // @libar-docs-implements - extendsPattern?: string; // @libar-docs-extends - seeAlso: string[]; // @libar-docs-see-also - apiRef: string[]; // @libar-docs-api-ref + uses: string[]; // @architect-uses + dependsOn: string[]; // @architect-depends-on + implementsPatterns: string[]; // @architect-implements + extendsPattern?: string; // @architect-extends + seeAlso: string[]; // @architect-see-also + apiRef: string[]; // @architect-api-ref // Reverse lookups (computed by transformer) usedBy: string[]; // inverse of uses @@ -484,7 +484,7 @@ export function transformToMasterDataset(raw: RawDataset): RuntimeMasterDataset ### Key Concepts -The delivery-process package uses a codec-based architecture for document generation: +The Architect package uses a codec-based architecture for document generation: ``` MasterDataset → Codec.decode() → RenderableDocument ─┬→ renderToMarkdown → Markdown Files @@ -701,7 +701,7 @@ const doc = codec.decode(dataset); #### AdrDocumentCodec -**Purpose:** Architecture Decision Records extracted from patterns with @libar-docs-adr tags. +**Purpose:** Architecture Decision Records extracted from patterns with @architect-adr tags. **Output Files:** @@ -817,7 +817,7 @@ const doc = codec.decode(dataset); **4-Layer Composition (in order):** -1. **Convention content** — Extracted from `@libar-docs-convention`-tagged patterns (rules, invariants, tables) +1. **Convention content** — Extracted from `@architect-convention`-tagged patterns (rules, invariants, tables) 2. **Scoped diagrams** — Mermaid diagrams filtered by `archContext`, `archLayer`, `patterns`, or `archView` 3. **TypeScript shapes** — API surfaces from `shapeSources` globs or `shapeSelectors` (declaration-level filtering) 4. **Behavior content** — Gherkin-sourced patterns from `behaviorCategories` @@ -928,21 +928,21 @@ The `detailLevel` option controls output verbosity: - `src/scanner/ast-parser.ts` - TypeScript AST parsing > **Note:** The scanner uses `RegexBuilders` from configuration to detect tags. -> The examples below use `@libar-docs-*` (DDD_ES_CQRS_PRESET). For other prefixes, substitute accordingly. +> The examples below use `@architect-*` (DDD_ES_CQRS_PRESET). For other prefixes, substitute accordingly. **Annotation Format:** ```typescript /** - * @libar-docs // Required opt-in (file level) - * @libar-docs-core @libar-docs-infra // Category tags - * @libar-docs-pattern MyPatternName // Pattern name - * @libar-docs-status completed // Status: roadmap|active|completed|deferred - * @libar-docs-phase 14 // Roadmap phase number - * @libar-docs-uses OtherPattern, Another // Dependencies (CSV) - * @libar-docs-usecase "When doing X" // Use cases (repeatable) - * @libar-docs-convention fsm-rules // Convention tag (CSV, links to decisions) - * @libar-docs-extract-shapes * // Auto-shape discovery (wildcard = all exports) + * @architect // Required opt-in (file level) + * @architect-core @architect-infra // Category tags + * @architect-pattern MyPatternName // Pattern name + * @architect-status completed // Status: roadmap|active|completed|deferred + * @architect-phase 14 // Roadmap phase number + * @architect-uses OtherPattern, Another // Dependencies (CSV) + * @architect-usecase "When doing X" // Use cases (repeatable) + * @architect-convention fsm-rules // Convention tag (CSV, links to decisions) + * @architect-extract-shapes * // Auto-shape discovery (wildcard = all exports) * * ## Pattern Description // Markdown description * @@ -952,11 +952,11 @@ The `detailLevel` option controls output verbosity: **Declaration-Level Shape Tagging:** -Individual declarations can be tagged with `@libar-docs-shape` in their JSDoc, without requiring a file-level `@libar-docs-extract-shapes` tag: +Individual declarations can be tagged with `@architect-shape` in their JSDoc, without requiring a file-level `@architect-extract-shapes` tag: ```typescript /** - * @libar-docs-shape api-types + * @architect-shape api-types * Configuration for the delivery process pipeline. */ export interface PipelineConfig { ... } @@ -976,11 +976,11 @@ The optional value (e.g., `api-types`) sets the shape's `group` field, enabling **Annotation Format:** ```gherkin -@libar-docs-pattern:MyPattern @libar-docs-phase:15 @libar-docs-status:roadmap -@libar-docs-quarter:Q1-2025 @libar-docs-effort:2w @libar-docs-team:platform -@libar-docs-depends-on:OtherPattern @libar-docs-enables:NextPattern -@libar-docs-product-area:Generators @libar-docs-user-role:Developer -@libar-docs-release:v0.1.0 +@architect-pattern:MyPattern @architect-phase:15 @architect-status:roadmap +@architect-quarter:Q1-2025 @architect-effort:2w @architect-team:platform +@architect-depends-on:OtherPattern @architect-enables:NextPattern +@architect-product-area:Generators @architect-user-role:Developer +@architect-release:v0.1.0 Feature: My Pattern Implementation Background: @@ -1001,17 +1001,17 @@ The Gherkin parser uses a data-driven approach — a `TAG_LOOKUP` map is built f **Tag Mapping:** -| Gherkin Tag | ExtractedPattern Field | -| ------------------------------ | ---------------------- | -| `@libar-docs-pattern:Name` | `patternName` | -| `@libar-docs-phase:N` | `phase` | -| `@libar-docs-status:*` | `status` | -| `@libar-docs-quarter:*` | `quarter` | -| `@libar-docs-release:*` | `release` | -| `@libar-docs-depends-on:*` | `dependsOn` | -| `@libar-docs-product-area:*` | `productArea` | -| `@libar-docs-convention:*` | `convention` | -| `@libar-docs-discovered-gap:*` | `discoveredGaps` | +| Gherkin Tag | ExtractedPattern Field | +| ----------------------------- | ---------------------- | +| `@architect-pattern:Name` | `patternName` | +| `@architect-phase:N` | `phase` | +| `@architect-status:*` | `status` | +| `@architect-quarter:*` | `quarter` | +| `@architect-release:*` | `release` | +| `@architect-depends-on:*` | `dependsOn` | +| `@architect-product-area:*` | `productArea` | +| `@architect-convention:*` | `convention` | +| `@architect-discovered-gap:*` | `discoveredGaps` | ### Status Normalization @@ -1099,7 +1099,7 @@ Data-driven configuration for pattern categorization: **Category Inference Algorithm:** -1. Extract tag parts (e.g., `@libar-docs-core-utils` → `["core", "utils"]`) +1. Extract tag parts (e.g., `@architect-core-utils` → `["core", "utils"]`) 2. Find matching categories in registry (with aliases) 3. Select highest priority (lowest number) 4. Fallback to "uncategorized" @@ -1298,7 +1298,7 @@ buildMasterDataset(options) Use planning codecs to prepare for implementation: ```typescript -import { createSessionPlanCodec, createPlanningChecklistCodec } from '@libar-dev/delivery-process'; +import { createSessionPlanCodec, createPlanningChecklistCodec } from '@libar-dev/architect'; // Generate planning documents const planCodec = createSessionPlanCodec({ @@ -1322,7 +1322,7 @@ const checklistCodec = createPlanningChecklistCodec({ Use session context and PR changes for active development: ```typescript -import { createSessionContextCodec, createPrChangesCodec } from '@libar-dev/delivery-process'; +import { createSessionContextCodec, createPrChangesCodec } from '@libar-dev/architect'; // Current session context const sessionCodec = createSessionContextCodec({ @@ -1347,7 +1347,7 @@ const prCodec = createPrChangesCodec({ Use milestone and changelog codecs for release documentation: ```typescript -import { createMilestonesCodec, createChangelogCodec } from '@libar-dev/delivery-process'; +import { createMilestonesCodec, createChangelogCodec } from '@libar-dev/architect'; // Quarter-filtered milestones const milestonesCodec = createMilestonesCodec({ @@ -1374,7 +1374,7 @@ import { createSessionContextCodec, createRemainingWorkCodec, createCurrentWorkCodec, -} from '@libar-dev/delivery-process'; +} from '@libar-dev/architect'; // Full session context bundle const sessionCodec = createSessionContextCodec({ @@ -1407,8 +1407,8 @@ const currentCodec = createCurrentWorkCodec({ ### Direct Codec Usage ```typescript -import { createPatternsCodec, type MasterDataset } from '@libar-dev/delivery-process'; -import { renderToMarkdown } from '@libar-dev/delivery-process/renderable'; +import { createPatternsCodec, type MasterDataset } from '@libar-dev/architect'; +import { renderToMarkdown } from '@libar-dev/architect/renderable'; // Create custom codec const codec = createPatternsCodec({ @@ -1426,7 +1426,7 @@ const markdown = renderToMarkdown(document); ### Using generateDocument ```typescript -import { generateDocument, type DocumentType } from '@libar-dev/delivery-process/renderable'; +import { generateDocument, type DocumentType } from '@libar-dev/architect/renderable'; // Generate with default options const files = generateDocument('patterns', masterDataset); @@ -1504,8 +1504,8 @@ export function createMyCodec(options?: MyCodecOptions) { ### Registering a Custom Generator ```typescript -import { generatorRegistry } from '@libar-dev/delivery-process/generators'; -import { createCodecGenerator } from '@libar-dev/delivery-process/generators/codec-based'; +import { generatorRegistry } from '@libar-dev/architect/generators'; +import { createCodecGenerator } from '@libar-dev/architect/generators/codec-based'; // Register if using existing document type generatorRegistry.register(createCodecGenerator('my-patterns', 'patterns')); diff --git a/docs/CONFIGURATION.md b/docs/CONFIGURATION.md index 45dd5f22..cd46f89b 100644 --- a/docs/CONFIGURATION.md +++ b/docs/CONFIGURATION.md @@ -2,7 +2,7 @@ > **Deprecated:** This document is superseded by the auto-generated [Configuration Guide](../docs-live/reference/CONFIGURATION-GUIDE.md). This file is preserved for reference only. -Configure tag prefixes, presets, sources, output, and custom taxonomies for `@libar-dev/delivery-process`. +Configure tag prefixes, presets, sources, output, and custom taxonomies for `@libar-dev/architect`. > **Prerequisites:** See [README.md](../README.md) for installation and basic usage. > **Tag Reference:** Run `npx generate-tag-taxonomy -o TAG_TAXONOMY.md -f` for a complete tag list. See [TAXONOMY.md](./TAXONOMY.md) for concepts. @@ -11,15 +11,15 @@ Configure tag prefixes, presets, sources, output, and custom taxonomies for `@li ## Quick Reference -| Preset | Tag Prefix | Categories | Use Case | -| ----------------------------- | -------------- | ---------- | ------------------------------------ | -| **`libar-generic`** (default) | `@libar-docs-` | 3 | Simple projects (this package) | -| `generic` | `@docs-` | 3 | Simple projects with `@docs-` prefix | -| `ddd-es-cqrs` | `@libar-docs-` | 21 | DDD/Event Sourcing architectures | +| Preset | Tag Prefix | Categories | Use Case | +| ----------------------------- | ------------- | ---------- | ------------------------------------ | +| **`libar-generic`** (default) | `@architect-` | 3 | Simple projects (this package) | +| `generic` | `@docs-` | 3 | Simple projects with `@docs-` prefix | +| `ddd-es-cqrs` | `@architect-` | 21 | DDD/Event Sourcing architectures | ```typescript -// delivery-process.config.ts -import { defineConfig } from '@libar-dev/delivery-process/config'; +// architect.config.ts +import { defineConfig } from '@libar-dev/architect/config'; // Default: libar-generic preset (simple 3-category taxonomy) export default defineConfig({ @@ -36,8 +36,8 @@ export default defineConfig({ preset: 'ddd-es-cqrs', sources: { typescript: ['packages/*/src/**/*.ts'], - features: ['delivery-process/specs/**/*.feature'], - stubs: ['delivery-process/stubs/**/*.ts'], + features: ['architect/specs/**/*.feature'], + stubs: ['architect/stubs/**/*.ts'], }, output: { directory: 'docs-living', overwrite: true }, }); @@ -87,21 +87,21 @@ All entry points use the same default: ### Libar-Generic Preset (Default) -The default preset used by this package. Same 3 categories as `generic` but with `@libar-docs-` prefix. +The default preset used by this package. Same 3 categories as `generic` but with `@architect-` prefix. | Property | Value | | --------------- | -------------------- | -| **Tag Prefix** | `@libar-docs-` | -| **File Opt-In** | `@libar-docs` | +| **Tag Prefix** | `@architect-` | +| **File Opt-In** | `@architect` | | **Categories** | 3 (core, api, infra) | ```typescript /** - * @libar-docs - * @libar-docs-pattern PatternScanner - * @libar-docs-status completed - * @libar-docs-core - * @libar-docs-uses FileDiscovery, ASTParser + * @architect + * @architect-pattern PatternScanner + * @architect-status completed + * @architect-core + * @architect-uses FileDiscovery, ASTParser */ export function scanPatterns(config: ScanConfig): Promise { ... } ``` @@ -133,18 +133,18 @@ Full taxonomy for domain-driven architectures with 21 categories. | Property | Value | | --------------- | ---------------------------------------------------------------------- | -| **Tag Prefix** | `@libar-docs-` | -| **File Opt-In** | `@libar-docs` | +| **Tag Prefix** | `@architect-` | +| **File Opt-In** | `@architect` | | **Categories** | 21 (domain, ddd, bounded-context, event-sourcing, decider, cqrs, etc.) | ```typescript /** - * @libar-docs - * @libar-docs-pattern TransformDataset - * @libar-docs-status completed - * @libar-docs-core - * @libar-docs-uses MasterDataset, ExtractedPattern - * @libar-docs-used-by Orchestrator + * @architect + * @architect-pattern TransformDataset + * @architect-status completed + * @architect-core + * @architect-uses MasterDataset, ExtractedPattern + * @architect-used-by Orchestrator */ export function transformToMasterDataset(input: TransformInput): MasterDataset { ... } ``` @@ -155,26 +155,26 @@ export function transformToMasterDataset(input: TransformInput): MasterDataset { ## Unified Config File -The `defineConfig()` function centralizes taxonomy, sources, output, and generator overrides in a single `delivery-process.config.ts` file. CLI tools discover this file automatically. +The `defineConfig()` function centralizes taxonomy, sources, output, and generator overrides in a single `architect.config.ts` file. CLI tools discover this file automatically. ### Discovery Order -1. Current directory: check `delivery-process.config.ts`, then `.js` +1. Current directory: check `architect.config.ts`, then `.js` 2. Walk up to repo root (`.git` folder), checking each directory -3. Fall back to libar-generic preset (3 categories, `@libar-docs-` prefix) +3. Fall back to libar-generic preset (3 categories, `@architect-` prefix) ### Config File Format ```typescript -// delivery-process.config.ts -import { defineConfig } from '@libar-dev/delivery-process/config'; +// architect.config.ts +import { defineConfig } from '@libar-dev/architect/config'; export default defineConfig({ preset: 'libar-generic', sources: { typescript: ['src/**/*.ts'], - stubs: ['delivery-process/stubs/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + stubs: ['architect/stubs/**/*.ts'], + features: ['architect/specs/*.feature'], }, output: { directory: 'docs-generated', @@ -210,15 +210,15 @@ export default defineConfig({ preset: 'libar-generic', sources: { typescript: ['src/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + features: ['architect/specs/*.feature'], }, output: { directory: 'docs-generated', overwrite: true }, generatorOverrides: { changelog: { - additionalFeatures: ['delivery-process/decisions/*.feature'], + additionalFeatures: ['architect/decisions/*.feature'], }, 'doc-from-decision': { - replaceFeatures: ['delivery-process/decisions/*.feature'], + replaceFeatures: ['architect/decisions/*.feature'], }, }, }); @@ -237,10 +237,10 @@ export default defineConfig({ ``` my-monorepo/ -├── delivery-process.config.ts # Repo: ddd-es-cqrs +├── architect.config.ts # Repo: ddd-es-cqrs └── packages/ └── my-package/ - └── delivery-process.config.ts # Package: generic + └── architect.config.ts # Package: generic ``` CLI tools use the nearest config file to the working directory. @@ -303,7 +303,7 @@ export default defineConfig({ For tools that need to load configuration files: ```typescript -import { loadProjectConfig } from '@libar-dev/delivery-process/config'; +import { loadProjectConfig } from '@libar-dev/architect/config'; const result = await loadProjectConfig(process.cwd()); @@ -313,7 +313,7 @@ if (!result.ok) { } const resolved = result.value; -// resolved.instance - DeliveryProcessInstance (registry + regexBuilders) +// resolved.instance - ArchitectInstance (registry + regexBuilders) // resolved.project - ResolvedProjectConfig (sources, output, generators) // resolved.isDefault - true if no config file found // resolved.configPath - config file path (if found) @@ -322,7 +322,7 @@ const resolved = result.value; For per-generator source resolution: ```typescript -import { mergeSourcesForGenerator } from '@libar-dev/delivery-process/config'; +import { mergeSourcesForGenerator } from '@libar-dev/architect/config'; const effectiveSources = mergeSourcesForGenerator( resolved.project.sources, @@ -337,12 +337,12 @@ const effectiveSources = mergeSourcesForGenerator( ## Backward Compatibility -The legacy `createDeliveryProcess()` API is still exported and supported. Config files using the old format are detected automatically by `loadProjectConfig()` and wrapped in a `ResolvedConfig` with default project settings. +The legacy `createArchitect()` API is still exported and supported. Config files using the old format are detected automatically by `loadProjectConfig()` and wrapped in a `ResolvedConfig` with default project settings. ```typescript // Legacy format (still works) -import { createDeliveryProcess } from '@libar-dev/delivery-process'; -export default createDeliveryProcess({ preset: 'ddd-es-cqrs' }); +import { createArchitect } from '@libar-dev/architect'; +export default createArchitect({ preset: 'ddd-es-cqrs' }); ``` New projects should use `defineConfig()` for the unified configuration experience. diff --git a/docs/DOCS-GAP-ANALYSIS.md b/docs/DOCS-GAP-ANALYSIS.md index 070ac1ec..1664c8b1 100644 --- a/docs/DOCS-GAP-ANALYSIS.md +++ b/docs/DOCS-GAP-ANALYSIS.md @@ -65,7 +65,7 @@ curated content is maintained alongside generated reference material. ### Master Roadmap: DocsConsolidationStrategy -**Spec:** `delivery-process/specs/docs-consolidation-strategy.feature` +**Spec:** `architect/specs/docs-consolidation-strategy.feature` **Status:** roadmap | **Phase:** 35 | **Depends on:** CodecDrivenReferenceGeneration (completed) This is the **canonical plan** for the entire consolidation initiative. It defines a @@ -118,7 +118,7 @@ generated equivalents. Work packages in this gap analysis should map to its phas | `reference-doc-showcase.feature` | ReferenceDocShowcase | completed | 30 | All 9 content block types across 3 detail levels | | `validator-read-model-consolidation.feature` | ValidatorReadModelConsolidation | completed | 100 | MasterDataset as single read model (ADR-006) | -**Query these specs:** `pnpm process:query -- decisions DocsConsolidationStrategy` +**Query these specs:** `pnpm architect:query -- decisions DocsConsolidationStrategy` ### Completed Foundation Work @@ -131,7 +131,7 @@ The following capabilities are already in place and available for new work: - **9 content block types** -- headings, paragraphs, tables, code, mermaid, lists, sections, metadata, collapsible (all exercised in REFERENCE-SAMPLE.md) - **CLI schema extraction** -- `src/cli/cli-schema.ts` drives both help text and doc generation -- **Convention tag mechanism** -- `@libar-docs-convention` annotations compose into reference docs +- **Convention tag mechanism** -- `@architect-convention` annotations compose into reference docs - **Product area meta with diagram scopes** -- C4Context + graph LR per area --- @@ -147,11 +147,11 @@ is defined in DocsConsolidationStrategy Rule 1 and implemented by CodecDrivenRef Step 1: Register convention tag value in src/taxonomy/conventions.ts e.g., 'codec-registry', 'pipeline-architecture', 'taxonomy-rules' -Step 2: Annotate source files with @libar-docs-convention: +Step 2: Annotate source files with @architect-convention: TypeScript: JSDoc blocks with structured content Gherkin: Rule: blocks with Invariant/Rationale markers -Step 3: Add ReferenceDocConfig in delivery-process.config.ts +Step 3: Add ReferenceDocConfig in architect.config.ts { title: 'Available Codecs Reference', conventionTags: ['codec-registry'], // <-- matches step 2 @@ -178,7 +178,7 @@ Step 5: Replace manual doc section with pointer to generated output | Include tags | `includeTags` | Filter patterns by tag for scoped reference | | Editorial preamble | `preamble` | Hand-authored SectionBlock[] prepended to output | -### Existing Convention Tags (from delivery-process.config.ts) +### Existing Convention Tags (from architect.config.ts) | Tag Value | Used By | Produces | | ----------------------- | ---------------------- | ------------------------------------ | @@ -191,7 +191,7 @@ Step 5: Replace manual doc section with pointer to generated output To consolidate a manual doc section, a design session needs to decide: 1. **Which convention tag value** to register (or reuse existing) -2. **Which source files** to annotate with `@libar-docs-convention:` +2. **Which source files** to annotate with `@architect-convention:` 3. **What content structure** the JSDoc/Gherkin annotations should use 4. **Which ReferenceDocConfig fields** to populate (shapes? diagrams? behaviors?) 5. **Whether preamble** is needed for editorial context that can't be annotated @@ -207,7 +207,7 @@ should follow the same recipe. ### Directory Layout After Commit 223ace6 ``` -delivery-process/ +architect/ docs/ 11 manual files (~4,985 lines) -- human-authored reference docs-live/ 48 generated files (~20,548 lines) -- auto-generated, committed docs-generated/ empty after pnpm docs:all -- gitignored build cache @@ -268,7 +268,7 @@ sync-content.mjs docs/ -> guides/ + reference/ (manual docs) docs-live/ -> product-areas/ + decisions/ (generated) docs-generated/ -> generated/ (business-rules, taxonomy) - output: src/content/docs/delivery-process/ + output: src/content/docs/architect/ ``` ### Website Section Structure (from content-manifest.mjs) @@ -551,7 +551,7 @@ This replaces the manual PROCESS-GUARD.md "Error Messages and Fixes" section. - Enhance `ValidationRulesCodec` or create separate `ErrorGuideCodec`? - Convention tag approach: annotate error-handling code in `src/lint/` with - `@libar-docs-convention:process-guard-errors`, or use existing behavior extraction? + `@architect-convention:process-guard-errors`, or use existing behavior extraction? - Preamble for Husky/CI setup content that can't come from annotations? ### WP-6: Create CLI Recipe Codec (P2) @@ -587,7 +587,7 @@ restructure, pending) and Phase 39 (Session workflow module generation, pending blocked on ClaudeModuleGeneration Phase 25). Also relates to Phase 5 (Guide trimming). **Note on Phase 39:** The session-guides-module-source.feature spec already has -`@libar-docs-claude-module` and `@libar-docs-claude-section:workflow` tags. Once +`@architect-claude-module` and `@architect-claude-section:workflow` tags. Once Phase 25 ships ClaudeModuleCodec, the CLAUDE.md session section auto-generates. This WP addresses the **public-facing** SESSION-GUIDES.md, not the AI context version. @@ -628,7 +628,7 @@ The master spec already decided to keep it. Design session should confirm and de **Recommendation:** Option 1, with option 2 as enhancement. The philosophy is inherently editorial, but encoding core thesis as Rule: blocks would make it -queryable (`pnpm process:query -- rules --pattern Methodology`) without replacing +queryable (`pnpm architect:query -- rules --pattern Methodology`) without replacing the human-readable prose. ### WP-9: Quality Polish for Website Publication (P1) diff --git a/docs/GHERKIN-PATTERNS.md b/docs/GHERKIN-PATTERNS.md index 94097a24..f7b7f8fc 100644 --- a/docs/GHERKIN-PATTERNS.md +++ b/docs/GHERKIN-PATTERNS.md @@ -13,9 +13,9 @@ Practical patterns for writing Gherkin specs that work with `delivery-process` g Roadmap specs define planned work with Problem/Solution descriptions and a Background deliverables table. ```gherkin -@libar-docs-pattern:ProcessGuardLinter -@libar-docs-status:roadmap -@libar-docs-phase:99 +@architect-pattern:ProcessGuardLinter +@architect-status:roadmap +@architect-phase:99 Feature: Process Guard Linter **Problem:** @@ -39,8 +39,8 @@ Feature: Process Guard Linter **Key elements:** -- `@libar-docs-pattern:Name` - Unique identifier (required) -- `@libar-docs-status:roadmap` - FSM state +- `@architect-pattern:Name` - Unique identifier (required) +- `@architect-status:roadmap` - FSM state - `**Problem:**` / `**Solution:**` - Extracted by generators - Background deliverables table - Tracks implementation progress @@ -104,13 +104,13 @@ Test features focus on behavior verification with section dividers for organizat ```gherkin @behavior @scanner-core -@libar-docs-pattern:ScannerCore +@architect-pattern:ScannerCore Feature: Scanner Core Integration The scanPatterns function orchestrates file discovery and AST parsing. **Problem:** - Need to scan codebases for documentation directives efficiently - - Files without @libar-docs opt-in should be skipped + - Files without @architect opt-in should be skipped **Solution:** - Two-phase filtering: quick regex check, then file opt-in validation @@ -127,9 +127,9 @@ Feature: Scanner Core Integration Scenario: Scan files and extract directives Given a file "src/auth.ts" with content: """ - /** @libar-docs */ + /** @architect */ - /** @libar-docs-core */ + /** @architect-core */ export function authenticate() {} """ When scanning with pattern "src/**/*.ts" @@ -188,16 +188,16 @@ Use `"""typescript` for code blocks. Essential when content contains pipes or sp Scenario: Extract directive from TypeScript Given a file with content: """typescript - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * Authentication utilities */ export function authenticate() {} """ When scanning the file - Then directive should have tag "@libar-docs-core" + Then directive should have tag "@architect-core" ``` --- @@ -237,7 +237,7 @@ Combine scenario-level tags with feature-level tags for filtering: ```gherkin @behavior @scanner-core -@libar-docs-pattern:ScannerCore +@architect-pattern:ScannerCore Feature: Scanner Core Integration ``` @@ -330,29 +330,29 @@ Given the following code: **Tag values cannot contain spaces.** Use hyphens: -| Invalid | Valid | -| -------------------------------- | ------------------------------- | -| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | -| `@libar-docs-pattern:My Pattern` | `@libar-docs-pattern:MyPattern` | +| Invalid | Valid | +| ------------------------------- | ------------------------------ | +| `@unlock-reason:Fix for issue` | `@unlock-reason:Fix-for-issue` | +| `@architect-pattern:My Pattern` | `@architect-pattern:MyPattern` | For values with spaces, use the `quoted-value` format where supported: ```gherkin -@libar-docs-usecase "When handling command failures" +@architect-usecase "When handling command failures" ``` --- ## Quick Reference -| Element | Use For | Example Location | -| -------------------- | -------------------------------------- | -------------------------------------------------------- | -| Background DataTable | Deliverables, shared reference data | `delivery-process/specs/process-guard-linter.feature` | -| Rule: | Group scenarios by business constraint | `tests/features/validation/*.feature` | -| Scenario Outline | Same pattern with variations | `tests/features/validation/fsm-validator.feature` | -| DocString `"""` | Code examples, content with pipes | `tests/features/behavior/scanner-*.feature` | -| Section comments `#` | Organize large feature files | Most test features | -| `lint-steps` | Catch vitest-cucumber traps statically | [VALIDATION.md — lint-steps](./VALIDATION.md#lint-steps) | +| Element | Use For | Example Location | +| ---------------------- | -------------------------------------- | -------------------------------------------------------- | +| Background DataTable | Deliverables, shared reference data | `architect/specs/process-guard-linter.feature` | +| Rule: | Group scenarios by business constraint | `tests/features/validation/*.feature` | +| Scenario Outline | Same pattern with variations | `tests/features/validation/fsm-validator.feature` | +| DocString `"""` | Code examples, content with pipes | `tests/features/behavior/scanner-*.feature` | +| Section comments `#` | Organize large feature files | Most test features | +| `architect-lint-steps` | Catch vitest-cucumber traps statically | [VALIDATION.md — lint-steps](./VALIDATION.md#lint-steps) | --- diff --git a/docs/INDEX.md b/docs/INDEX.md index e18aa9bd..26228936 100644 --- a/docs/INDEX.md +++ b/docs/INDEX.md @@ -2,13 +2,13 @@ > **Deprecated:** This document is superseded by the auto-generated [Documentation Index](../docs-live/INDEX.md) which includes live statistics, audience-based navigation, and document roles. This file is preserved for reference only. -**Navigate the full documentation set for `@libar-dev/delivery-process`.** Use section links below for targeted reading. +**Navigate the full documentation set for `@libar-dev/architect`.** Use section links below for targeted reading. ## Package Metadata | Field | Value | | ---------------- | ---------------------------------------------------- | -| **Package** | @libar-dev/delivery-process | +| **Package** | @libar-dev/architect | | **Version** | 1.0.0-pre.0 | | **Purpose** | Context engineering for AI-assisted codebases | | **Key Features** | Living docs, FSM enforcement, AI-native Data API CLI | @@ -96,7 +96,7 @@ | Unified Config File | 154-244 | defineConfig(), sources, output, gen overrides | | Custom Configuration | 248-295 | Custom tag prefix, custom categories | | Programmatic Config | 299-331 | loadProjectConfig(), mergeSourcesForGenerator() | -| Backward Compatibility | 336-346 | Legacy createDeliveryProcess() support | +| Backward Compatibility | 336-346 | Legacy createArchitect() support | | Related Documentation | 350-357 | Links to README, TAXONOMY, ARCHITECTURE | --- @@ -305,10 +305,10 @@ It queries annotated sources in real time — not generated snapshots. See [PROCESS-API.md](./PROCESS-API.md). ```bash -pnpm process:query -- scope-validate MyPattern implement # ALWAYS run first -pnpm process:query -- context MyPattern --session implement # Curated context bundle -pnpm process:query -- files MyPattern --related # Implementation paths -pnpm process:query -- handoff --pattern MyPattern # Capture session end state +pnpm architect:query -- scope-validate MyPattern implement # ALWAYS run first +pnpm architect:query -- context MyPattern --session implement # Curated context bundle +pnpm architect:query -- files MyPattern --related # Implementation paths +pnpm architect:query -- handoff --pattern MyPattern # Capture session end state ``` --- diff --git a/docs/MCP-SETUP.md b/docs/MCP-SETUP.md index 343cd82e..64e498b3 100644 --- a/docs/MCP-SETUP.md +++ b/docs/MCP-SETUP.md @@ -1,6 +1,6 @@ # MCP Server Setup -> delivery-process MCP server exposes ProcessStateAPI as native Claude Code tools with sub-millisecond dispatch. +> Architect MCP server exposes ProcessStateAPI as native Claude Code tools with sub-millisecond dispatch. ## Quick Start @@ -11,9 +11,9 @@ Add to your project's `.mcp.json`: ```json { "mcpServers": { - "delivery-process": { + "architect": { "command": "npx", - "args": ["dp-mcp-server"], + "args": ["architect-mcp"], "cwd": "${workspaceFolder}" } } @@ -25,9 +25,9 @@ Add to your project's `.mcp.json`: ```json { "mcpServers": { - "delivery-process": { + "architect": { "command": "npx", - "args": ["dp-mcp-server"], + "args": ["architect-mcp"], "cwd": "/path/to/your/project" } } @@ -41,9 +41,9 @@ Auto-rebuild the dataset when source files change: ```json { "mcpServers": { - "delivery-process": { + "architect": { "command": "npx", - "args": ["dp-mcp-server", "--watch"], + "args": ["architect-mcp", "--watch"], "cwd": "${workspaceFolder}" } } @@ -57,10 +57,10 @@ Override config auto-detection for monorepo setups: ```json { "mcpServers": { - "delivery-process": { + "architect": { "command": "npx", "args": [ - "dp-mcp-server", + "architect-mcp", "--input", "packages/core/src/**/*.ts", "--features", @@ -84,38 +84,38 @@ The MCP server: ## Available Tools -| Tool | Description | -| ---------------------- | ---------------------------------------------------- | -| `dp_overview` | Project health summary (start here) | -| `dp_context` | Session-aware context bundle for a pattern | -| `dp_pattern` | Full pattern metadata | -| `dp_list` | List patterns with filters (status, phase, category) | -| `dp_search` | Fuzzy search patterns by name | -| `dp_status` | Status counts and completion percentage | -| `dp_files` | File reading list for a pattern | -| `dp_dep_tree` | Dependency chain with status | -| `dp_scope_validate` | Pre-flight check for implementation | -| `dp_handoff` | Session-end state for continuity | -| `dp_rules` | Business rules and invariants | -| `dp_tags` | Tag usage report | -| `dp_sources` | Source file inventory | -| `dp_stubs` | Design stubs with resolution status | -| `dp_decisions` | Design decisions from stubs | -| `dp_arch_context` | Bounded contexts with members | -| `dp_arch_layer` | Architecture layers with members | -| `dp_arch_neighborhood` | Pattern uses/used-by/peers | -| `dp_arch_blocking` | Patterns blocked by dependencies | -| `dp_arch_dangling` | Broken pattern references | -| `dp_arch_coverage` | Annotation coverage analysis | -| `dp_unannotated` | Files missing @libar-docs | -| `dp_rebuild` | Force dataset rebuild | -| `dp_config` | Show current configuration | -| `dp_help` | List all tools | +| Tool | Description | +| ----------------------------- | ---------------------------------------------------- | +| `architect_overview` | Project health summary (start here) | +| `architect_context` | Session-aware context bundle for a pattern | +| `architect_pattern` | Full pattern metadata | +| `architect_list` | List patterns with filters (status, phase, category) | +| `architect_search` | Fuzzy search patterns by name | +| `architect_status` | Status counts and completion percentage | +| `architect_files` | File reading list for a pattern | +| `architect_dep_tree` | Dependency chain with status | +| `architect_scope_validate` | Pre-flight check for implementation | +| `architect_handoff` | Session-end state for continuity | +| `architect_rules` | Business rules and invariants | +| `architect_tags` | Tag usage report | +| `architect_sources` | Source file inventory | +| `architect_stubs` | Design stubs with resolution status | +| `architect_decisions` | Design decisions from stubs | +| `architect_arch_context` | Bounded contexts with members | +| `architect_arch_layer` | Architecture layers with members | +| `architect_arch_neighborhood` | Pattern uses/used-by/peers | +| `architect_arch_blocking` | Patterns blocked by dependencies | +| `architect_arch_dangling` | Broken pattern references | +| `architect_arch_coverage` | Annotation coverage analysis | +| `architect_unannotated` | Files missing @architect | +| `architect_rebuild` | Force dataset rebuild | +| `architect_config` | Show current configuration | +| `architect_help` | List all tools | ## CLI Options ```text -dp-mcp-server [options] +architect-mcp [options] -i, --input TypeScript source globs (repeatable) -f, --features Gherkin feature globs (repeatable) @@ -129,11 +129,11 @@ dp-mcp-server [options] ### Server fails to start -Check that `delivery-process.config.ts` exists in your project root, or provide explicit `--input` and `--features` globs. +Check that `architect.config.ts` exists in your project root, or provide explicit `--input` and `--features` globs. ### Tools return stale data -Call `dp_rebuild` to force a dataset refresh, or start the server with `--watch` for automatic rebuilds. +Call `architect_rebuild` to force a dataset refresh, or start the server with `--watch` for automatic rebuilds. ### Config not found in monorepo diff --git a/docs/METHODOLOGY.md b/docs/METHODOLOGY.md index 3a4b6d75..7beda20f 100644 --- a/docs/METHODOLOGY.md +++ b/docs/METHODOLOGY.md @@ -4,7 +4,7 @@ > **Git is the event store. Documentation artifacts are projections. Annotated code is the single source of truth.** -This document explains the _why_ behind `@libar-dev/delivery-process`. For _how_, see [README.md](../README.md) and [TAXONOMY.md](./TAXONOMY.md). +This document explains the _why_ behind `@libar-dev/architect`. For _how_, see [README.md](../README.md) and [TAXONOMY.md](./TAXONOMY.md). --- @@ -29,7 +29,7 @@ Event sourcing teaches us: **derive state, don't store it**. Apply this to docum - **Projections** = Generated docs (PATTERNS.md, ROADMAP.md) - **Read Model** = MasterDataset (consumed by codecs, validators, and Data API CLI) -When you run `generate-docs`, you're rebuilding read models from the event stream. The source annotations are always authoritative. +When you run `architect-generate`, you're rebuilding read models from the event stream. The source annotations are always authoritative. --- @@ -41,11 +41,11 @@ Every pattern in this package uses its own annotation system. Real examples: ```typescript /** - * @libar-docs - * @libar-docs-pattern Document Extractor - * @libar-docs-status completed - * @libar-docs-uses Pattern Scanner, Tag Registry, Zod - * @libar-docs-used-by Orchestrator, Generators + * @architect + * @architect-pattern Document Extractor + * @architect-status completed + * @architect-uses Pattern Scanner, Tag Registry, Zod + * @architect-used-by Orchestrator, Generators */ export function extractPatterns( scannedFiles: readonly ScannedFile[], baseDir: string, registry?: TagRegistry @@ -56,11 +56,11 @@ export function extractPatterns( ```typescript /** - * @libar-docs - * @libar-docs-pattern Pattern Scanner - * @libar-docs-status completed - * @libar-docs-uses glob, AST Parser - * @libar-docs-used-by Doc Extractor, Orchestrator + * @architect + * @architect-pattern Pattern Scanner + * @architect-status completed + * @architect-uses glob, AST Parser + * @architect-used-by Doc Extractor, Orchestrator */ export async function scanPatterns( config: ScannerConfig, registry?: TagRegistry @@ -118,12 +118,12 @@ Run `pnpm docs:patterns` and these annotations become a searchable pattern regis **Feature file** (specs/my-pattern.feature): ```gherkin -@libar-docs -@libar-docs-pattern:EventStoreDurability -@libar-docs-status:roadmap -@libar-docs-phase:18 -@libar-docs-depends-on:EventStoreFoundation -@libar-docs-enables:SagaEngine +@architect +@architect-pattern:EventStoreDurability +@architect-status:roadmap +@architect-phase:18 +@architect-depends-on:EventStoreFoundation +@architect-enables:SagaEngine Feature: Event Store Durability ``` @@ -131,11 +131,11 @@ Feature: Event Store Durability ```typescript /** - * @libar-docs - * @libar-docs-status roadmap - * @libar-docs-event-sourcing - * @libar-docs-uses EventStoreFoundation, Workpool - * @libar-docs-used-by SagaEngine, CommandOrchestrator + * @architect + * @architect-status roadmap + * @architect-event-sourcing + * @architect-uses EventStoreFoundation, Workpool + * @architect-used-by SagaEngine, CommandOrchestrator */ ``` @@ -145,10 +145,10 @@ Note: Code stubs must NOT use `@-pattern`. The feature file is the canon ## Two-Tier Spec Architecture -| Tier | Location | Purpose | Executable | -| ----------- | ------------------------- | ------------------------------------------- | ---------- | -| **Roadmap** | `delivery-process/specs/` | Planning, deliverables, acceptance criteria | No | -| **Package** | `{pkg}/tests/features/` | Implementation proof, regression testing | Yes | +| Tier | Location | Purpose | Executable | +| ----------- | ----------------------- | ------------------------------------------- | ---------- | +| **Roadmap** | `architect/specs/` | Planning, deliverables, acceptance criteria | No | +| **Package** | `{pkg}/tests/features/` | Implementation proof, regression testing | Yes | **Traceability:** @@ -165,8 +165,8 @@ Code is the source of truth. Feature files reference code, not duplicate it. ```typescript /** - * @libar-docs - * @libar-docs-status roadmap + * @architect + * @architect-status roadmap * * ## Reservation Pattern - TTL-Based Pre-Creation Uniqueness */ @@ -192,7 +192,7 @@ Two types of stubs serve different purposes and live in different locations: Design session code stubs define API shapes with `throw new Error("Not implemented")`. They live **outside `src/`** to avoid TypeScript compilation and ESLint issues: ``` -delivery-process/ +architect/ ├── stubs/ # Design session code stubs (not compiled) │ └── {pattern-name}/ # One directory per pattern │ └── *.ts # API shapes, interfaces, throw-not-implemented @@ -200,13 +200,13 @@ delivery-process/ └── ... ``` -| Phase | Location | Status | -| -------------- | ----------------------------------- | ------------------------------------ | -| Design | `delivery-process/stubs/{pattern}/` | `throw new Error("Not implemented")` | -| Implementation | Move/copy to `src/` | Replace with real logic | -| Completed | `src/` | Production code | +| Phase | Location | Status | +| -------------- | ---------------------------- | ------------------------------------ | +| Design | `architect/stubs/{pattern}/` | `throw new Error("Not implemented")` | +| Implementation | Move/copy to `src/` | Replace with real logic | +| Completed | `src/` | Production code | -Stubs are scanned by the documentation pipeline (via `-i 'delivery-process/stubs/**/*.ts'`) but excluded from TypeScript compilation (`tsconfig.json` includes only `src/**/*`) and ESLint (`eslint` targets `src tests`). +Stubs are scanned by the documentation pipeline (via `-i 'architect/stubs/**/*.ts'`) but excluded from TypeScript compilation (`tsconfig.json` includes only `src/**/*`) and ESLint (`eslint` targets `src tests`). ### Planning Stubs (Test Step Definition Stubs) diff --git a/docs/PROCESS-GUARD.md b/docs/PROCESS-GUARD.md index 3298a0ec..9cfc915c 100644 --- a/docs/PROCESS-GUARD.md +++ b/docs/PROCESS-GUARD.md @@ -30,9 +30,9 @@ Process Guard validates delivery workflow changes at commit time. For FSM concep | Situation | Solution | Example | | ----------------------------- | ---------------------------------- | --------------------------------------------- | -| Fix bug in completed spec | Add `@*-unlock-reason:'reason'` | `@libar-docs-unlock-reason:'Fix typo'` | -| Modify outside session scope | `--ignore-session` flag | `lint-process --staged --ignore-session` | -| CI treats warnings as errors | `--strict` flag | `lint-process --all --strict` | +| Fix bug in completed spec | Add `@*-unlock-reason:'reason'` | `@architect-unlock-reason:'Fix typo'` | +| Modify outside session scope | `--ignore-session` flag | `architect-guard --staged --ignore-session` | +| CI treats warnings as errors | `--strict` flag | `architect-guard --all --strict` | | Skip workflow (legacy import) | Multiple transitions in one commit | Set `roadmap` then `completed` in same commit | --- @@ -46,18 +46,18 @@ Process Guard validates delivery workflow changes at commit time. For FSM concep ```text [ERROR] specs/phase-state-machine.feature Cannot modify completed spec without unlock reason - Suggestion: Add @libar-docs-unlock-reason:'reason for modification' + Suggestion: Add @architect-unlock-reason:'reason for modification' ``` -**Cause:** File has `@libar-docs-status:completed` but no unlock annotation. +**Cause:** File has `@architect-status:completed` but no unlock annotation. **Fix:** Add unlock reason explaining why modification is necessary: ```gherkin -@libar-docs -@libar-docs-pattern:PhaseStateMachine -@libar-docs-status:completed -@libar-docs-unlock-reason:'Fix incorrect FSM diagram in documentation' +@architect +@architect-pattern:PhaseStateMachine +@architect-status:completed +@architect-unlock-reason:'Fix incorrect FSM diagram in documentation' Feature: Phase State Machine ``` @@ -87,10 +87,10 @@ Feature: Phase State Machine ```gherkin # Step 1: Move to active -@libar-docs-status:active +@architect-status:active # Step 2: After implementation complete, move to completed -@libar-docs-status:completed +@architect-status:completed ``` **Common invalid transitions:** @@ -121,9 +121,9 @@ Feature: Phase State Machine 1. **Remove the new deliverable** — Keep scope locked during implementation 2. **Revert to roadmap** — If scope genuinely needs to expand: ```gherkin - @libar-docs-status:roadmap # Temporarily revert + @architect-status:roadmap # Temporarily revert # Add deliverable, then: - @libar-docs-status:active # Resume implementation + @architect-status:active # Resume implementation ``` **Why this rule exists:** Prevents scope creep during implementation. Plan fully before starting; implement what was planned. @@ -147,7 +147,7 @@ Feature: Phase State Machine 1. **Add to session scope** — If this file should be in scope 2. **Use `--ignore-session`** — For intentional out-of-scope changes: ```bash - lint-process --staged --ignore-session + architect-guard --staged --ignore-session ``` --- @@ -169,7 +169,7 @@ Feature: Phase State Machine 1. **Remove from exclusion list** — If exclusion was a mistake 2. **Use `--ignore-session`** — For emergency changes: ```bash - lint-process --staged --ignore-session + architect-guard --staged --ignore-session ``` --- @@ -226,19 +226,19 @@ lint-process [options] ```bash # Pre-commit hook (recommended) -lint-process --staged +architect-guard --staged # CI pipeline with strict mode -lint-process --all --strict +architect-guard --all --strict # Validate specific file -lint-process --file specs/my-feature.feature +architect-guard --file specs/my-feature.feature # Debug: see what state was derived -lint-process --staged --show-state +architect-guard --staged --show-state # Override session scope for emergency fix -lint-process --staged --ignore-session +architect-guard --staged --ignore-session ``` --- @@ -252,7 +252,7 @@ lint-process --staged --ignore-session #!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh" -npx lint-process --staged +npx architect-guard --staged ``` ### package.json @@ -260,8 +260,8 @@ npx lint-process --staged ```json { "scripts": { - "lint:process": "lint-process --staged", - "lint:process:ci": "lint-process --all --strict" + "lint:process": "architect-guard --staged", + "lint:process:ci": "architect-guard --all --strict" } } ``` @@ -277,7 +277,7 @@ import { validateChanges, hasErrors, summarizeResult, -} from '@libar-dev/delivery-process/lint'; +} from '@libar-dev/architect/lint'; // 1. Derive state from annotations const state = (await deriveProcessState({ baseDir: '.' })).value; diff --git a/docs/SESSION-GUIDES.md b/docs/SESSION-GUIDES.md index 27ce05cb..65a69063 100644 --- a/docs/SESSION-GUIDES.md +++ b/docs/SESSION-GUIDES.md @@ -33,8 +33,8 @@ Starting from pattern brief? ### Context Gathering ```bash -pnpm process:query -- overview # Project health -pnpm process:query -- list --status roadmap --names-only # Available patterns +pnpm architect:query -- overview # Project health +pnpm architect:query -- list --status roadmap --names-only # Available patterns ``` ### Checklist @@ -99,9 +99,9 @@ See [`tests/features/validation/fsm-validator.feature`](../tests/features/valida ### Context Gathering ```bash -pnpm process:query -- context --session design # Full context bundle -pnpm process:query -- dep-tree # Dependency chain -pnpm process:query -- stubs # Existing design stubs +pnpm architect:query -- context --session design # Full context bundle +pnpm architect:query -- dep-tree # Dependency chain +pnpm architect:query -- stubs # Existing design stubs ``` Use these **before** launching explore agents. See [PROCESS-API.md](./PROCESS-API.md). @@ -116,16 +116,16 @@ Use these **before** launching explore agents. See [PROCESS-API.md](./PROCESS-AP ### Checklist -- [ ] **Record decisions** as PDR `.feature` files in `delivery-process/decisions/` +- [ ] **Record decisions** as PDR `.feature` files in `architect/decisions/` - [ ] **Document options** — At least 2-3 approaches with pros/cons - [ ] **Get approval** — User must approve recommended approach -- [ ] **Create code stubs** in `delivery-process/stubs/{pattern-name}/`: +- [ ] **Create code stubs** in `architect/stubs/{pattern-name}/`: ```typescript - // delivery-process/stubs/{pattern-name}/my-function.ts + // architect/stubs/{pattern-name}/my-function.ts /** * @ * @-status roadmap @@ -147,7 +147,7 @@ Use these **before** launching explore agents. See [PROCESS-API.md](./PROCESS-AP } ``` - Stubs live outside `src/` to avoid TypeScript compilation and ESLint issues. They are scanned by the documentation pipeline via `-i 'delivery-process/stubs/**/*.ts'`. + Stubs live outside `src/` to avoid TypeScript compilation and ESLint issues. They are scanned by the documentation pipeline via `-i 'architect/stubs/**/*.ts'`. - [ ] **Verify stub identifier spelling** — Check all exported function/type/interface names for typos before committing stubs @@ -170,13 +170,13 @@ Use these **before** launching explore agents. See [PROCESS-API.md](./PROCESS-AP ```bash # Pre-flight — catches FSM violations, missing deps, incomplete deliverables -pnpm process:query -- scope-validate implement +pnpm architect:query -- scope-validate implement # Curated context — deliverables, FSM state, test files -pnpm process:query -- context --session implement +pnpm architect:query -- context --session implement # File paths for implementation -pnpm process:query -- files --related +pnpm architect:query -- files --related ``` The `scope-validate` command replaces the manual pre-flight checklist — it checks @@ -212,7 +212,7 @@ See [PROCESS-API.md](./PROCESS-API.md#scope-validate). ``` 4. **Verify all design decisions addressed:** - - [ ] Run `pnpm process:query -- decisions ` and confirm each DD-N has a corresponding `// DD-N:` comment in the implementation + - [ ] Run `pnpm architect:query -- decisions ` and confirm each DD-N has a corresponding `// DD-N:` comment in the implementation 5. **Transition to completed** (only when ALL done): @@ -324,8 +324,8 @@ For multi-session work, capture state at session boundaries. ```bash # Generate handoff from actual annotation state (preferred over manual template) -pnpm process:query -- handoff --pattern -pnpm process:query -- handoff --pattern --git # include recent commits +pnpm architect:query -- handoff --pattern +pnpm architect:query -- handoff --pattern --git # include recent commits ``` The CLI handoff always reflects current annotation state. The template below is for additional context: diff --git a/docs/TAXONOMY.md b/docs/TAXONOMY.md index 1c337636..aa633dde 100644 --- a/docs/TAXONOMY.md +++ b/docs/TAXONOMY.md @@ -8,7 +8,7 @@ The taxonomy defines the vocabulary for pattern annotations: what tags exist, th ## Concept -A **taxonomy** is a classification system. In `@libar-dev/delivery-process`, the taxonomy defines: +A **taxonomy** is a classification system. In `@libar-dev/architect`, the taxonomy defines: | Component | Purpose | | ---------------- | --------------------------------------------------------- | @@ -45,11 +45,11 @@ src/taxonomy/ The `buildRegistry()` function creates a `TagRegistry` containing all taxonomy definitions: ```typescript -import { buildRegistry } from '@libar-dev/delivery-process/taxonomy'; +import { buildRegistry } from '@libar-dev/architect/taxonomy'; const registry = buildRegistry(); -// registry.tagPrefix → "@libar-docs-" -// registry.fileOptInTag → "@libar-docs" +// registry.tagPrefix → "@architect-" +// registry.fileOptInTag → "@architect" // registry.categories → CategoryDefinition[] // registry.metadataTags → MetadataTagDefinition[] // registry.aggregationTags → AggregationTagDefinition[] @@ -58,11 +58,11 @@ const registry = buildRegistry(); ### Presets Select Taxonomy Subsets -| Preset | Categories | Tag Prefix | Use Case | -| ------------------------- | ---------- | -------------- | ---------------------------------- | -| `libar-generic` (default) | 3 | `@libar-docs-` | Simple projects (this package) | -| `ddd-es-cqrs` | 21 | `@libar-docs-` | DDD/Event Sourcing architectures | -| `generic` | 3 | `@docs-` | Simple projects with @docs- prefix | +| Preset | Categories | Tag Prefix | Use Case | +| ------------------------- | ---------- | ------------- | ---------------------------------- | +| `libar-generic` (default) | 3 | `@architect-` | Simple projects (this package) | +| `ddd-es-cqrs` | 21 | `@architect-` | DDD/Event Sourcing architectures | +| `generic` | 3 | `@docs-` | Simple projects with @docs- prefix | The preset determines which categories are available. All presets share the same status values and format types. diff --git a/docs/VALIDATION.md b/docs/VALIDATION.md index 484225b0..edba06e7 100644 --- a/docs/VALIDATION.md +++ b/docs/VALIDATION.md @@ -22,17 +22,17 @@ Need cross-source or DoD validation? ├─ Yes → validate-patterns │ Running pre-commit hook? -└─ lint-process --staged (default) +└─ architect-guard --staged (default) ``` ## Command Summary -| Command | Purpose | When to Use | -| ------------------- | --------------------------------- | --------------------------------------------- | -| `lint-patterns` | Annotation quality | Ensure patterns have required tags | -| `lint-steps` | vitest-cucumber compatibility | After writing/modifying feature or step files | -| `lint-process` | FSM workflow enforcement | Pre-commit hooks, CI pipelines | -| `validate-patterns` | Cross-source + DoD + anti-pattern | Release validation, comprehensive | +| Command | Purpose | When to Use | +| ------------------------- | --------------------------------- | --------------------------------------------- | +| `architect-lint-patterns` | Annotation quality | Ensure patterns have required tags | +| `architect-lint-steps` | vitest-cucumber compatibility | After writing/modifying feature or step files | +| `architect-guard` | FSM workflow enforcement | Pre-commit hooks, CI pipelines | +| `architect-validate` | Cross-source + DoD + anti-pattern | Release validation, comprehensive | --- @@ -220,8 +220,8 @@ describeFeature(feature, ({ Given, When, Then, And }) => { ... }); ``` Feature files: tests/features/**/*.feature - delivery-process/specs/**/*.feature - delivery-process/decisions/**/*.feature + architect/specs/**/*.feature + architect/decisions/**/*.feature Step files: tests/steps/**/*.steps.ts ``` @@ -240,10 +240,10 @@ FSM validation for delivery workflow (PDR-005). Enforces status transitions and ```bash # Pre-commit (default) -npx lint-process --staged +npx architect-guard --staged # CI pipeline -npx lint-process --all --strict +npx architect-guard --all --strict ``` **What it validates:** @@ -345,8 +345,8 @@ Add these scripts to your project's `package.json`: "lint:patterns": "lint-patterns -i 'src/**/*.ts'", "lint:steps": "lint-steps", "lint:steps:ci": "lint-steps --strict", - "lint:process": "lint-process --staged", - "lint:process:ci": "lint-process --all --strict", + "lint:process": "architect-guard --staged", + "lint:process:ci": "architect-guard --all --strict", "validate:all": "validate-patterns -i 'src/**/*.ts' -F 'specs/**/*.feature' --dod --anti-patterns" } } @@ -356,7 +356,7 @@ Add these scripts to your project's `package.json`: ```bash # .husky/pre-commit -npx lint-process --staged +npx architect-guard --staged ``` ### GitHub Actions @@ -376,11 +376,11 @@ npx lint-process --staged ## Exit Codes -| Code | `lint-patterns` / `lint-steps` / `lint-process` | `validate-patterns` | -| ---- | ----------------------------------------------- | ------------------------------------- | -| `0` | No errors (warnings allowed unless `--strict`) | No issues found | -| `1` | Errors found (or warnings with `--strict`) | Errors found | -| `2` | — | Warnings found (with `--strict` only) | +| Code | `architect-lint-patterns` / `architect-lint-steps` / `architect-guard` | `architect-validate` | +| ---- | ---------------------------------------------------------------------- | ------------------------------------- | +| `0` | No errors (warnings allowed unless `--strict`) | No issues found | +| `1` | Errors found (or warnings with `--strict`) | Errors found | +| `2` | — | Warnings found (with `--strict` only) | --- @@ -390,19 +390,19 @@ All validation tools expose programmatic APIs. Import from subpaths: ```typescript // Pattern linting -import { lintFiles, hasFailures } from '@libar-dev/delivery-process/lint'; +import { lintFiles, hasFailures } from '@libar-dev/architect/lint'; // Step linting -import { runStepLint, STEP_LINT_RULES } from '@libar-dev/delivery-process/lint'; +import { runStepLint, STEP_LINT_RULES } from '@libar-dev/architect/lint'; // Process guard -import { deriveProcessState, validateChanges } from '@libar-dev/delivery-process/lint'; +import { deriveProcessState, validateChanges } from '@libar-dev/architect/lint'; // Anti-patterns and DoD -import { detectAntiPatterns, validateDoD } from '@libar-dev/delivery-process/validation'; +import { detectAntiPatterns, validateDoD } from '@libar-dev/architect/validation'; ``` -`validatePatterns()` now accepts a `RuntimeMasterDataset`. Build one via `buildMasterDataset()` from `@libar-dev/delivery-process/generators`. +`validatePatterns()` now accepts a `RuntimeMasterDataset`. Build one via `buildMasterDataset()` from `@libar-dev/architect/generators`. See [ARCHITECTURE.md](./ARCHITECTURE.md) for detailed API documentation. diff --git a/package.json b/package.json index 0dd852b0..6dc746a1 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { - "name": "@libar-dev/delivery-process", + "name": "@libar-dev/architect", "version": "1.0.0-pre.2", - "description": "Context engineering toolkit: extract patterns from TypeScript and Gherkin into a queryable delivery state with living docs, architecture graphs, and FSM-enforced workflows.", + "description": "Context engineering platform: extract patterns from TypeScript and Gherkin into a queryable state with living docs, architecture graphs, and FSM-enforced workflows.", "type": "module", "sideEffects": false, "main": "dist/index.js", @@ -63,14 +63,14 @@ } }, "bin": { - "generate-docs": "./dist/cli/generate-docs.js", - "lint-patterns": "./dist/cli/lint-patterns.js", - "lint-process": "./dist/cli/lint-process.js", - "generate-tag-taxonomy": "./dist/cli/generate-tag-taxonomy.js", - "validate-patterns": "./dist/cli/validate-patterns.js", - "process-api": "./dist/cli/process-api.js", - "lint-steps": "./dist/cli/lint-steps.js", - "dp-mcp-server": "./dist/cli/mcp-server.js" + "architect": "./dist/cli/process-api.js", + "architect-generate": "./dist/cli/generate-docs.js", + "architect-lint-patterns": "./dist/cli/lint-patterns.js", + "architect-guard": "./dist/cli/lint-process.js", + "architect-taxonomy": "./dist/cli/generate-tag-taxonomy.js", + "architect-validate": "./dist/cli/validate-patterns.js", + "architect-lint-steps": "./dist/cli/lint-steps.js", + "architect-mcp": "./dist/cli/mcp-server.js" }, "scripts": { "build": "tsc", @@ -82,10 +82,10 @@ "test:coverage": "vitest run --coverage", "lint": "eslint src tests", "lint:fix": "eslint src tests --fix", - "lint:process": "tsx src/cli/lint-process.ts --staged", - "lint:process:all": "tsx src/cli/lint-process.ts --all", - "lint:steps": "tsx src/cli/lint-steps.ts", - "lint-patterns": "tsx src/cli/lint-patterns.ts --input 'src/**/*.ts' --input 'delivery-process/stubs/**/*.ts'", + "architect:guard": "tsx src/cli/lint-process.ts --staged", + "architect:guard:all": "tsx src/cli/lint-process.ts --all", + "architect:lint-steps": "tsx src/cli/lint-steps.ts", + "architect:lint-patterns": "tsx src/cli/lint-patterns.ts --input 'src/**/*.ts' --input 'architect/stubs/**/*.ts'", "validate:patterns": "tsx src/cli/validate-patterns.ts", "validate:dod": "tsx src/cli/validate-patterns.ts --dod", "validate:anti-patterns": "tsx src/cli/validate-patterns.ts --anti-patterns", @@ -111,9 +111,9 @@ "docs:design-review": "tsx src/cli/generate-docs.ts -g design-review", "docs:all": "pnpm docs:decisions && pnpm docs:product-areas && pnpm docs:taxonomy && pnpm docs:business-rules && pnpm docs:validation && pnpm docs:reference && pnpm docs:claude-modules && pnpm docs:process-api-reference && pnpm docs:cli-recipe && pnpm docs:architecture && pnpm docs:changelog && pnpm docs:design-review && pnpm docs:index", "docs:all-preview": "pnpm docs:patterns && pnpm docs:roadmap && pnpm docs:remaining && pnpm docs:changelog && pnpm docs:architecture && pnpm docs:decisions && pnpm docs:reference && pnpm docs:product-areas && pnpm docs:taxonomy && pnpm docs:validation && pnpm docs:requirements && pnpm docs:current && pnpm docs:milestones && pnpm docs:business-rules", - "process:query": "tsx src/cli/process-api.ts", - "process:q": "tsx src/cli/process-api.ts", - "docs:tag-taxonomy": "tsx src/cli/generate-tag-taxonomy.ts --output delivery-process/tag-taxonomy.md --overwrite", + "architect:query": "tsx src/cli/process-api.ts", + "architect:q": "tsx src/cli/process-api.ts", + "docs:tag-taxonomy": "tsx src/cli/generate-tag-taxonomy.ts --output architect/tag-taxonomy.md --overwrite", "format": "prettier --write \"src/**/*.ts\" \"tests/**/*.ts\" \"*.{json,md,yml}\"", "format:check": "prettier --check \"src/**/*.ts\" \"tests/**/*.ts\" \"*.{json,md,yml}\"", "preversion": "pnpm test && pnpm typecheck && pnpm lint && pnpm format:check", @@ -153,7 +153,8 @@ "living-documentation", "documentation-generator", "technical-documentation", - "delivery-process", + "architect", + "libar-architect", "workflow-enforcement", "fsm-enforcement", "pre-commit-hooks", @@ -171,7 +172,7 @@ "cli" ], "author": "Libar AI", - "license": "MIT", + "license": "(MIT AND BUSL-1.1)", "repository": { "type": "git", "url": "git+https://github.com/libar-dev/delivery-process.git" @@ -213,6 +214,7 @@ "docs-live", "README.md", "LICENSE", + "LICENSE-MCP", "CHANGELOG.md" ], "private": false, diff --git a/src/api/arch-queries.ts b/src/api/arch-queries.ts index 961f79d1..c85ff056 100644 --- a/src/api/arch-queries.ts +++ b/src/api/arch-queries.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-pattern ArchQueriesImpl - * @libar-docs-status active - * @libar-docs-implements DataAPIArchitectureQueries - * @libar-docs-uses ProcessStateAPI, MasterDataset - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer domain + * @architect + * @architect-pattern ArchQueriesImpl + * @architect-status active + * @architect-implements DataAPIArchitectureQueries + * @architect-uses ProcessStateAPI, MasterDataset + * @architect-used-by ProcessAPICLIImpl + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer domain * * ## ArchQueries — Neighborhood, Comparison, Tags, Sources * diff --git a/src/api/context-assembler.ts b/src/api/context-assembler.ts index 96fc94c7..2b3d8153 100644 --- a/src/api/context-assembler.ts +++ b/src/api/context-assembler.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-pattern ContextAssemblerImpl - * @libar-docs-status active - * @libar-docs-implements DataAPIContextAssembly - * @libar-docs-uses ProcessStateAPI, MasterDataset, PatternSummarizerImpl, FuzzyMatcherImpl, StubResolverImpl - * @libar-docs-used-by ProcessAPICLIImpl, ContextFormatterImpl - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer application + * @architect + * @architect-pattern ContextAssemblerImpl + * @architect-status active + * @architect-implements DataAPIContextAssembly + * @architect-uses ProcessStateAPI, MasterDataset, PatternSummarizerImpl, FuzzyMatcherImpl, StubResolverImpl + * @architect-used-by ProcessAPICLIImpl, ContextFormatterImpl + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer application * * ## ContextAssembler — Session-Oriented Context Bundle Builder * diff --git a/src/api/context-formatter.ts b/src/api/context-formatter.ts index c9897cca..5022676f 100644 --- a/src/api/context-formatter.ts +++ b/src/api/context-formatter.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-pattern ContextFormatterImpl - * @libar-docs-status active - * @libar-docs-implements DataAPIContextAssembly - * @libar-docs-uses ContextAssemblerImpl - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer application + * @architect + * @architect-pattern ContextFormatterImpl + * @architect-status active + * @architect-implements DataAPIContextAssembly + * @architect-uses ContextAssemblerImpl + * @architect-used-by ProcessAPICLIImpl + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer application * * ## ContextFormatter — Plain Text Renderer for Context Bundles * diff --git a/src/api/coverage-analyzer.ts b/src/api/coverage-analyzer.ts index 70841c37..1a18620a 100644 --- a/src/api/coverage-analyzer.ts +++ b/src/api/coverage-analyzer.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-pattern CoverageAnalyzerImpl - * @libar-docs-status active - * @libar-docs-implements DataAPIArchitectureQueries - * @libar-docs-uses Pattern Scanner, MasterDataset - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer application + * @architect + * @architect-pattern CoverageAnalyzerImpl + * @architect-status active + * @architect-implements DataAPIArchitectureQueries + * @architect-uses Pattern Scanner, MasterDataset + * @architect-used-by ProcessAPICLIImpl + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer application * * ## CoverageAnalyzer — Annotation Coverage and Taxonomy Gap Detection * diff --git a/src/api/fuzzy-match.ts b/src/api/fuzzy-match.ts index f19b8fda..51c790c3 100644 --- a/src/api/fuzzy-match.ts +++ b/src/api/fuzzy-match.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern FuzzyMatcherImpl - * @libar-docs-status active - * @libar-docs-implements DataAPIOutputShaping - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer application + * @architect + * @architect-core + * @architect-pattern FuzzyMatcherImpl + * @architect-status active + * @architect-implements DataAPIOutputShaping + * @architect-used-by ProcessAPICLIImpl + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer application * * ## FuzzyMatcher — Pattern Name Fuzzy Search * diff --git a/src/api/handoff-generator.ts b/src/api/handoff-generator.ts index 093b49f0..272b504d 100644 --- a/src/api/handoff-generator.ts +++ b/src/api/handoff-generator.ts @@ -1,14 +1,14 @@ /** - * @libar-docs - * @libar-docs-pattern HandoffGeneratorImpl - * @libar-docs-status completed - * @libar-docs-implements DataAPIDesignSessionSupport - * @libar-docs-uses ProcessStateAPI, MasterDataset, ContextFormatterImpl - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-target src/api/handoff-generator.ts - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer application + * @architect + * @architect-pattern HandoffGeneratorImpl + * @architect-status completed + * @architect-implements DataAPIDesignSessionSupport + * @architect-uses ProcessStateAPI, MasterDataset, ContextFormatterImpl + * @architect-used-by ProcessAPICLIImpl + * @architect-target src/api/handoff-generator.ts + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer application * * ## HandoffGenerator — Session-End State Summary * diff --git a/src/api/index.ts b/src/api/index.ts index 7763d132..8cad8779 100644 --- a/src/api/index.ts +++ b/src/api/index.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern APIModule - * @libar-docs-status active + * @architect + * @architect-core + * @architect-pattern APIModule + * @architect-status active * * ## API Module - Programmatic Process State Interface * @@ -22,7 +22,7 @@ * createProcessStateAPI, * type ProcessStateAPI, * type QueryResult, - * } from "@libar-dev/delivery-process/api"; + * } from "@libar-dev/architect/api"; * * const api = createProcessStateAPI(masterDataset); * diff --git a/src/api/pattern-helpers.ts b/src/api/pattern-helpers.ts index 7c86110d..e5ed91b7 100644 --- a/src/api/pattern-helpers.ts +++ b/src/api/pattern-helpers.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-pattern PatternHelpers - * @libar-docs-status active - * @libar-docs-implements DataAPIOutputShaping - * @libar-docs-arch-context api - * @libar-docs-arch-layer domain + * @architect + * @architect-pattern PatternHelpers + * @architect-status active + * @architect-implements DataAPIOutputShaping + * @architect-arch-context api + * @architect-arch-layer domain * * ## Pattern Helpers — Shared Lookup Utilities * diff --git a/src/api/process-state.ts b/src/api/process-state.ts index 7bc616f1..c6cbb8f7 100644 --- a/src/api/process-state.ts +++ b/src/api/process-state.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern ProcessStateAPI - * @libar-docs-status active - * @libar-docs-implements PhaseStateMachineValidation - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer application - * @libar-docs-uses MasterDataset, FSMValidator + * @architect + * @architect-core + * @architect-pattern ProcessStateAPI + * @architect-status active + * @architect-implements PhaseStateMachineValidation + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer application + * @architect-uses MasterDataset, FSMValidator * * ## Process State API - Programmatic Query Interface * @@ -32,7 +32,7 @@ * ### Usage * * ```typescript - * import { createProcessStateAPI } from "@libar-dev/delivery-process"; + * import { createProcessStateAPI } from "@libar-dev/architect"; * * const api = createProcessStateAPI(masterDataset); * @@ -214,7 +214,7 @@ export interface ProcessStateAPI { getPatternRelationships(name: string): PatternRelationships | undefined; /** - * Get related patterns (from @libar-docs-see-also tag) + * Get related patterns (from @architect-see-also tag) * * Returns patterns that are related for cross-reference without implying * dependency. Used for planning session scoping. @@ -224,7 +224,7 @@ export interface ProcessStateAPI { getRelatedPatterns(name: string): readonly string[]; /** - * Get API references (from @libar-docs-api-ref tag) + * Get API references (from @architect-api-ref tag) * * Returns file paths to implementation APIs. Used for code navigation * from spec to implementation. diff --git a/src/api/rules-query.ts b/src/api/rules-query.ts index 50bfe5a1..62fd327e 100644 --- a/src/api/rules-query.ts +++ b/src/api/rules-query.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern RulesQueryModule - * @libar-docs-status completed - * @libar-docs-implements ProcessAPILayeredExtraction - * @libar-docs-product-area DataAPI - * @libar-docs-uses BusinessRulesCodec, CodecHelpers + * @architect + * @architect-core + * @architect-pattern RulesQueryModule + * @architect-status completed + * @architect-implements ProcessAPILayeredExtraction + * @architect-product-area DataAPI + * @architect-uses BusinessRulesCodec, CodecHelpers * * ## RulesQueryModule - Business Rules Domain Query * diff --git a/src/api/scope-validator.ts b/src/api/scope-validator.ts index 043586f8..0a395972 100644 --- a/src/api/scope-validator.ts +++ b/src/api/scope-validator.ts @@ -1,14 +1,14 @@ /** - * @libar-docs - * @libar-docs-pattern ScopeValidatorImpl - * @libar-docs-status completed - * @libar-docs-implements DataAPIDesignSessionSupport - * @libar-docs-uses ProcessStateAPI, MasterDataset, StubResolverImpl - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-target src/api/scope-validator.ts - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer application + * @architect + * @architect-pattern ScopeValidatorImpl + * @architect-status completed + * @architect-implements DataAPIDesignSessionSupport + * @architect-uses ProcessStateAPI, MasterDataset, StubResolverImpl + * @architect-used-by ProcessAPICLIImpl + * @architect-target src/api/scope-validator.ts + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer application * * ## ScopeValidator — Pre-flight Session Readiness Checker * diff --git a/src/api/stub-resolver.ts b/src/api/stub-resolver.ts index 2b12f55e..f7551fd5 100644 --- a/src/api/stub-resolver.ts +++ b/src/api/stub-resolver.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-pattern StubResolverImpl - * @libar-docs-status active - * @libar-docs-implements DataAPIStubIntegration - * @libar-docs-uses ProcessStateAPI - * @libar-docs-used-by ProcessAPICLIImpl + * @architect + * @architect-pattern StubResolverImpl + * @architect-status active + * @architect-implements DataAPIStubIntegration + * @architect-uses ProcessStateAPI + * @architect-used-by ProcessAPICLIImpl * * ## StubResolver — Design Stub Discovery and Resolution * @@ -13,10 +13,10 @@ * * Stub identification heuristic: * - Source file path contains `/stubs/` (lives in stubs directory), OR - * - Pattern has a `targetPath` field (from @libar-docs-target tag) + * - Pattern has a `targetPath` field (from @architect-target tag) * * Resolution uses a `fileExists` callback (defaulting to `fs.existsSync()`) on - * targetPath — not pipeline data — because target files may not have `@libar-docs` + * targetPath — not pipeline data — because target files may not have `@architect` * annotations. The callback enables testing without filesystem side effects. * * **When to Use:** When querying design stub status via the `stubs` CLI subcommand or when checking stub resolution in scope validation. @@ -40,11 +40,11 @@ export interface StubResolution { readonly stubName: string; /** Source file path of the stub */ readonly stubFile: string; - /** Target implementation path (from @libar-docs-target) */ + /** Target implementation path (from @architect-target) */ readonly targetPath: string; - /** Design session that created this stub (from @libar-docs-since) */ + /** Design session that created this stub (from @architect-since) */ readonly since: string | undefined; - /** Parent pattern this stub implements (from @libar-docs-implements) */ + /** Parent pattern this stub implements (from @architect-implements) */ readonly implementsPattern: string | undefined; /** Whether the target file exists on disk */ readonly targetExists: boolean; @@ -97,7 +97,7 @@ export interface PdrReference { * * A pattern is a stub if: * 1. Its source file path contains '/stubs/' (lives in stubs directory), OR - * 2. It has a `targetPath` field (from @libar-docs-target tag) + * 2. It has a `targetPath` field (from @architect-target tag) */ export function findStubPatterns(dataset: MasterDataset): readonly ExtractedPattern[] { return dataset.patterns.filter( diff --git a/src/api/summarize.ts b/src/api/summarize.ts index 32333a38..dae2a09a 100644 --- a/src/api/summarize.ts +++ b/src/api/summarize.ts @@ -1,14 +1,14 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern PatternSummarizerImpl - * @libar-docs-status active - * @libar-docs-implements DataAPIOutputShaping - * @libar-docs-uses ProcessStateAPI - * @libar-docs-used-by OutputPipeline, ProcessAPICLIImpl - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer application + * @architect + * @architect-core + * @architect-pattern PatternSummarizerImpl + * @architect-status active + * @architect-implements DataAPIOutputShaping + * @architect-uses ProcessStateAPI + * @architect-used-by OutputPipeline, ProcessAPICLIImpl + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer application * * ## PatternSummarizer — Compact Pattern Projection * @@ -78,7 +78,7 @@ export function deriveSource(filePath: string): 'typescript' | 'gherkin' { /** * Project an ExtractedPattern to a compact PatternSummary. * - * - `patternName` prefers explicit @libar-docs-pattern tag, falls back to `name` + * - `patternName` prefers explicit @architect-pattern tag, falls back to `name` * - `source` is derived from file extension (.feature -> gherkin, else typescript) * - Optional fields (status, phase) are included when present, omitted when undefined * diff --git a/src/api/types.ts b/src/api/types.ts index 1d60936d..d36c9f2f 100644 --- a/src/api/types.ts +++ b/src/api/types.ts @@ -1,9 +1,9 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern ProcessStateTypes - * @libar-docs-status active - * @libar-docs-depends-on:MasterDataset + * @architect + * @architect-core + * @architect-pattern ProcessStateTypes + * @architect-status active + * @architect-depends-on:MasterDataset * * ## Process State API Types * @@ -163,25 +163,25 @@ export interface PatternDependencies { * relationship graph from the MasterDataset's relationshipIndex. */ export interface PatternRelationships { - /** Patterns this pattern depends on (from @libar-docs-depends-on) */ + /** Patterns this pattern depends on (from @architect-depends-on) */ dependsOn: readonly string[]; - /** Patterns this pattern enables (from @libar-docs-enables) */ + /** Patterns this pattern enables (from @architect-enables) */ enables: readonly string[]; - /** Patterns this pattern uses (from @libar-docs-uses) */ + /** Patterns this pattern uses (from @architect-uses) */ uses: readonly string[]; - /** Patterns that use this pattern (from @libar-docs-used-by) */ + /** Patterns that use this pattern (from @architect-used-by) */ usedBy: readonly string[]; - /** Patterns this code implements (from @libar-docs-implements) */ + /** Patterns this code implements (from @architect-implements) */ implementsPatterns: readonly string[]; /** Files that implement this pattern with metadata (computed inverse) */ implementedBy: readonly ImplementationRef[]; - /** Pattern this extends (from @libar-docs-extends) */ + /** Pattern this extends (from @architect-extends) */ extendsPattern: string | undefined; /** Patterns that extend this pattern (computed inverse) */ extendedBy: readonly string[]; - /** Related patterns for cross-reference without dependency (from @libar-docs-see-also) */ + /** Related patterns for cross-reference without dependency (from @architect-see-also) */ seeAlso: readonly string[]; - /** File paths to implementation APIs (from @libar-docs-api-ref) */ + /** File paths to implementation APIs (from @architect-api-ref) */ apiRef: readonly string[]; } diff --git a/src/cache/file-cache.ts b/src/cache/file-cache.ts index 45079f77..435e7511 100644 --- a/src/cache/file-cache.ts +++ b/src/cache/file-cache.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-pattern FileCache - * @libar-docs-status active - * @libar-docs-arch-role infrastructure - * @libar-docs-arch-context generator - * @libar-docs-arch-layer infrastructure + * @architect + * @architect-pattern FileCache + * @architect-status active + * @architect-arch-role infrastructure + * @architect-arch-context generator + * @architect-arch-layer infrastructure * * ## File Cache - Request-Scoped Content Caching * diff --git a/src/cli/cli-schema.ts b/src/cli/cli-schema.ts index cbfa527a..266cf335 100644 --- a/src/cli/cli-schema.ts +++ b/src/cli/cli-schema.ts @@ -1,16 +1,16 @@ /** - * @libar-docs - * @libar-docs-pattern CLISchema - * @libar-docs-status completed - * @libar-docs-unlock-reason:Add-recipe-and-narrative-fields-for-CliRecipeCodec - * @libar-docs-implements ProcessApiHybridGeneration - * @libar-docs-arch-context cli - * @libar-docs-arch-layer domain - * @libar-docs-product-area:DataAPI + * @architect + * @architect-pattern CLISchema + * @architect-status completed + * @architect-unlock-reason:Add-recipe-and-narrative-fields-for-CliRecipeCodec + * @architect-implements ProcessApiHybridGeneration + * @architect-arch-context cli + * @architect-arch-layer domain + * @architect-product-area:DataAPI * * ## CLI Schema — Single Source of Truth for CLI Reference * - * Declarative schema defining all CLI options for the process-api command. + * Declarative schema defining all CLI options for the architect command. * Consumed by: * - `showHelp()` in process-api.ts (terminal help text) * - `ProcessApiReferenceGenerator` (generated markdown reference) @@ -100,7 +100,7 @@ export const CLI_SCHEMA: CLISchema = { globalOptions: { title: 'Global Options', postNote: - '**Config auto-detection:** If `--input` and `--features` are not provided, the CLI loads defaults from `delivery-process.config.ts` in the current directory. If no config file exists, it falls back to filesystem-based detection. If neither works, `--input` is required.', + '**Config auto-detection:** If `--input` and `--features` are not provided, the CLI loads defaults from `architect.config.ts` in the current directory. If no config file exists, it falls back to filesystem-based detection. If neither works, `--input` is required.', options: [ { flag: '--input ', @@ -240,7 +240,7 @@ export const CLI_SCHEMA: CLISchema = { command: 'overview', description: 'Executive summary: progress percentage, active phases, blocking patterns, and a CLI cheat sheet.', - usageExample: 'pnpm process:query -- overview', + usageExample: 'pnpm architect:query -- overview', expectedOutput: [ '=== PROGRESS ===', '318 patterns (224 completed, 47 active, 47 planned) = 70%', @@ -253,7 +253,7 @@ export const CLI_SCHEMA: CLISchema = { 'StepLintExtendedRules blocked by: StepLintVitestCucumber', '', '=== DATA API \u2014 Use Instead of Explore Agents ===', - 'pnpm process:query -- ', + 'pnpm architect:query -- ', ' overview, context, scope-validate, dep-tree, list, stubs, files, rules, arch blocking', ].join('\n'), }, @@ -261,7 +261,7 @@ export const CLI_SCHEMA: CLISchema = { command: 'scope-validate', description: '**Highest-impact command.** Pre-flight readiness check that prevents wasted sessions. Returns a PASS/BLOCKED/WARN verdict covering: dependency completion, deliverable definitions, FSM transition validity, and design decisions.', - usageExample: 'pnpm process:query -- scope-validate MyPattern implement', + usageExample: 'pnpm architect:query -- scope-validate MyPattern implement', details: 'Checks: dependency completion, deliverable definitions, FSM transition validity, design decisions, executable spec location. Valid session types for scope-validate: `implement`, `design`.', expectedOutput: [ @@ -280,7 +280,7 @@ export const CLI_SCHEMA: CLISchema = { { command: 'context', description: 'Curated context bundle tailored to session type.', - usageExample: 'pnpm process:query -- context MyPattern --session design', + usageExample: 'pnpm architect:query -- context MyPattern --session design', expectedOutput: [ '=== PATTERN: ContextAssemblerImpl ===', 'Status: active | Category: pattern', @@ -307,15 +307,15 @@ export const CLI_SCHEMA: CLISchema = { command: 'dep-tree', description: 'Dependency chain with status indicators. Shows what a pattern depends on, recursively.', - usageExample: 'pnpm process:query -- dep-tree MyPattern', + usageExample: 'pnpm architect:query -- dep-tree MyPattern', details: - 'Use `--depth` to limit recursion depth: `pnpm process:query -- dep-tree MyPattern --depth 2`.', + 'Use `--depth` to limit recursion depth: `pnpm architect:query -- dep-tree MyPattern --depth 2`.', }, { command: 'files', description: 'File reading list with implementation paths. Use `--related` to include architecture neighbors.', - usageExample: 'pnpm process:query -- files MyPattern --related', + usageExample: 'pnpm architect:query -- files MyPattern --related', expectedOutput: [ '=== PRIMARY ===', 'src/cli/process-api.ts', @@ -330,7 +330,7 @@ export const CLI_SCHEMA: CLISchema = { command: 'handoff', description: 'Captures session-end state: deliverable statuses, blockers, and modification date.', - usageExample: 'pnpm process:query -- handoff --pattern MyPattern', + usageExample: 'pnpm architect:query -- handoff --pattern MyPattern', details: 'Use `--git` to include recent commits. Use `--session` to tag the handoff with a session id.', expectedOutput: [ @@ -356,7 +356,7 @@ export const CLI_SCHEMA: CLISchema = { { command: 'status', description: 'Status counts and completion percentage.', - usageExample: 'pnpm process:query -- status', + usageExample: 'pnpm architect:query -- status', details: '**Output:** `{ counts: { completed, active, planned, total }, completionPercentage, distribution }`', }, @@ -364,7 +364,7 @@ export const CLI_SCHEMA: CLISchema = { command: 'list', description: 'Filtered pattern listing. Composable with output modifiers and list filters.', - usageExample: 'pnpm process:query -- list --status roadmap --names-only', + usageExample: 'pnpm architect:query -- list --status roadmap --names-only', details: 'See Output Modifiers and List Filters for all options. Examples: `list --status active --count`, `list --phase 25 --fields patternName,status,file`.', }, @@ -372,34 +372,34 @@ export const CLI_SCHEMA: CLISchema = { command: 'search', description: 'Fuzzy name search with match scores. Suggests close matches when a pattern is not found.', - usageExample: 'pnpm process:query -- search EventStore', + usageExample: 'pnpm architect:query -- search EventStore', }, { command: 'pattern', description: 'Full detail for one pattern including deliverables, dependencies, and all relationship fields.', - usageExample: 'pnpm process:query -- pattern TransformDataset', + usageExample: 'pnpm architect:query -- pattern TransformDataset', details: '**Warning:** Completed patterns can produce ~66KB of output. Prefer `context --session` for interactive sessions.', }, { command: 'stubs', description: 'Design stubs with target paths and resolution status.', - usageExample: 'pnpm process:query -- stubs MyPattern', + usageExample: 'pnpm architect:query -- stubs MyPattern', details: - 'Use `--unresolved` to show only stubs missing target files: `pnpm process:query -- stubs --unresolved`.', + 'Use `--unresolved` to show only stubs missing target files: `pnpm architect:query -- stubs --unresolved`.', }, { command: 'decisions', description: 'AD-N design decisions extracted from stub descriptions.', - usageExample: 'pnpm process:query -- decisions MyPattern', + usageExample: 'pnpm architect:query -- decisions MyPattern', details: '**Note:** Returns exit code 1 when no decisions are found (unlike `list`/`search` which return empty arrays).', }, { command: 'pdr', description: 'Cross-reference patterns mentioning a PDR number.', - usageExample: 'pnpm process:query -- pdr 1', + usageExample: 'pnpm architect:query -- pdr 1', details: '**Note:** Returns exit code 1 when no PDR references are found, same as `decisions`.', }, @@ -407,7 +407,7 @@ export const CLI_SCHEMA: CLISchema = { command: 'rules', description: 'Business rules and invariants extracted from Gherkin `Rule:` blocks, grouped by product area, phase, and feature.', - usageExample: 'pnpm process:query -- rules --pattern ProcessGuardDecider', + usageExample: 'pnpm architect:query -- rules --pattern ProcessGuardDecider', details: '**Warning:** Unfiltered `rules` output can exceed 600KB. Always use `--pattern` or `--product-area` filters. **Output shape:** `{ productAreas: [{ productArea, ruleCount, invariantCount, phases: [{ phase, features: [{ pattern, source, rules }] }] }], totalRules, totalInvariants }`', }, @@ -418,62 +418,62 @@ export const CLI_SCHEMA: CLISchema = { { title: 'Architecture Queries', description: - 'All architecture queries output JSON. They use `@libar-docs-arch-*` annotations.', + 'All architecture queries output JSON. They use `@architect-arch-*` annotations.', commands: [ { command: 'arch roles', description: 'All arch-roles with pattern counts', - usageExample: 'pnpm process:query -- arch roles', + usageExample: 'pnpm architect:query -- arch roles', }, { command: 'arch context', description: 'All bounded contexts', - usageExample: 'pnpm process:query -- arch context', + usageExample: 'pnpm architect:query -- arch context', }, { command: 'arch context ', description: 'Patterns in one bounded context', - usageExample: 'pnpm process:query -- arch context scanner', + usageExample: 'pnpm architect:query -- arch context scanner', }, { command: 'arch layer', description: 'All architecture layers', - usageExample: 'pnpm process:query -- arch layer', + usageExample: 'pnpm architect:query -- arch layer', }, { command: 'arch layer ', description: 'Patterns in one layer', - usageExample: 'pnpm process:query -- arch layer domain', + usageExample: 'pnpm architect:query -- arch layer domain', }, { command: 'arch neighborhood ', description: 'Uses, usedBy, dependsOn, same-context', - usageExample: 'pnpm process:query -- arch neighborhood EventStore', + usageExample: 'pnpm architect:query -- arch neighborhood EventStore', }, { command: 'arch compare ', description: 'Cross-context shared deps + integration', - usageExample: 'pnpm process:query -- arch compare scanner codec', + usageExample: 'pnpm architect:query -- arch compare scanner codec', }, { command: 'arch coverage', description: 'Annotation completeness across input files', - usageExample: 'pnpm process:query -- arch coverage', + usageExample: 'pnpm architect:query -- arch coverage', }, { command: 'arch dangling', description: "Broken references (names that don't exist)", - usageExample: 'pnpm process:query -- arch dangling', + usageExample: 'pnpm architect:query -- arch dangling', }, { command: 'arch orphans', description: 'Patterns with no relationships (isolated)', - usageExample: 'pnpm process:query -- arch orphans', + usageExample: 'pnpm architect:query -- arch orphans', }, { command: 'arch blocking', description: 'Patterns blocked by incomplete deps', - usageExample: 'pnpm process:query -- arch blocking', + usageExample: 'pnpm architect:query -- arch blocking', }, ], }, @@ -486,26 +486,26 @@ export const CLI_SCHEMA: CLISchema = { command: 'tags', description: 'Tag usage report \u2014 counts per tag and value across all annotated sources.', - usageExample: 'pnpm process:query -- tags', + usageExample: 'pnpm architect:query -- tags', }, { command: 'sources', description: 'File inventory by type (TypeScript, Gherkin, Stubs, Decisions).', - usageExample: 'pnpm process:query -- sources', + usageExample: 'pnpm architect:query -- sources', }, { command: 'unannotated', description: - 'TypeScript files missing the `@libar-docs` opt-in marker. Use `--path` to scope to a directory.', - usageExample: 'pnpm process:query -- unannotated --path src/types', + 'TypeScript files missing the `@architect` opt-in marker. Use `--path` to scope to a directory.', + usageExample: 'pnpm architect:query -- unannotated --path src/types', }, { command: 'query', description: 'Execute any of the 26 query API methods directly by name. This is the escape hatch for methods not exposed as dedicated subcommands.', - usageExample: 'pnpm process:query -- query getStatusCounts', + usageExample: 'pnpm architect:query -- query getStatusCounts', details: - 'Integer-like arguments are automatically coerced to numbers. Run `process-api --help` for the full list of available API methods. Examples: `query isValidTransition roadmap active`, `query getPatternsByPhase 18`, `query getRecentlyCompleted 5`.', + 'Integer-like arguments are automatically coerced to numbers. Run `architect --help` for the full list of available API methods. Examples: `query isValidTransition roadmap active`, `query getPatternsByPhase 18`, `query getRecentlyCompleted 5`.', }, ], }, @@ -525,15 +525,15 @@ export const CLI_SCHEMA: CLISchema = { purpose: 'The recommended session startup is three commands.', steps: [ { - command: 'pnpm process:query -- overview', + command: 'pnpm architect:query -- overview', comment: 'project health', }, { - command: 'pnpm process:query -- scope-validate MyPattern implement', + command: 'pnpm architect:query -- scope-validate MyPattern implement', comment: 'pre-flight', }, { - command: 'pnpm process:query -- context MyPattern --session implement', + command: 'pnpm architect:query -- context MyPattern --session implement', comment: 'curated context', }, ], @@ -543,15 +543,15 @@ export const CLI_SCHEMA: CLISchema = { purpose: 'Discover available patterns, blockers, and missing implementations.', steps: [ { - command: 'pnpm process:query -- list --status roadmap --names-only', + command: 'pnpm architect:query -- list --status roadmap --names-only', comment: 'available patterns', }, { - command: 'pnpm process:query -- arch blocking', + command: 'pnpm architect:query -- arch blocking', comment: 'stuck patterns', }, { - command: 'pnpm process:query -- stubs --unresolved', + command: 'pnpm architect:query -- stubs --unresolved', comment: 'missing implementations', }, ], @@ -561,19 +561,19 @@ export const CLI_SCHEMA: CLISchema = { purpose: 'Deep-dive into a specific pattern: search, dependencies, neighbors, and files.', steps: [ { - command: 'pnpm process:query -- search EventStore', + command: 'pnpm architect:query -- search EventStore', comment: 'fuzzy name search', }, { - command: 'pnpm process:query -- dep-tree MyPattern --depth 2', + command: 'pnpm architect:query -- dep-tree MyPattern --depth 2', comment: 'dependency chain', }, { - command: 'pnpm process:query -- arch neighborhood MyPattern', + command: 'pnpm architect:query -- arch neighborhood MyPattern', comment: 'what it touches', }, { - command: 'pnpm process:query -- files MyPattern --related', + command: 'pnpm architect:query -- files MyPattern --related', comment: 'file paths', }, ], @@ -583,15 +583,15 @@ export const CLI_SCHEMA: CLISchema = { purpose: 'Gather full context, design decisions, and stubs before a design session.', steps: [ { - command: 'pnpm process:query -- context MyPattern --session design', + command: 'pnpm architect:query -- context MyPattern --session design', comment: 'full context', }, { - command: 'pnpm process:query -- decisions MyPattern', + command: 'pnpm architect:query -- decisions MyPattern', comment: 'design decisions', }, { - command: 'pnpm process:query -- stubs MyPattern', + command: 'pnpm architect:query -- stubs MyPattern', comment: 'existing stubs', }, ], @@ -601,11 +601,11 @@ export const CLI_SCHEMA: CLISchema = { purpose: 'Capture session-end state for continuity.', steps: [ { - command: 'pnpm process:query -- handoff --pattern MyPattern', + command: 'pnpm architect:query -- handoff --pattern MyPattern', comment: 'capture state', }, { - command: 'pnpm process:query -- handoff --pattern MyPattern --git', + command: 'pnpm architect:query -- handoff --pattern MyPattern --git', comment: 'include commits', }, ], diff --git a/src/cli/dataset-cache.ts b/src/cli/dataset-cache.ts index 52829848..77c9480c 100644 --- a/src/cli/dataset-cache.ts +++ b/src/cli/dataset-cache.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-cli - * @libar-docs-pattern DatasetCache - * @libar-docs-status active - * @libar-docs-implements DataAPICLIErgonomics - * @libar-docs-arch-role infrastructure - * @libar-docs-arch-context cli - * @libar-docs-arch-layer infrastructure - * @libar-docs-uses PipelineFactory, WorkflowConfigSchema + * @architect + * @architect-cli + * @architect-pattern DatasetCache + * @architect-status active + * @architect-implements DataAPICLIErgonomics + * @architect-arch-role infrastructure + * @architect-arch-context cli + * @architect-arch-layer infrastructure + * @architect-uses PipelineFactory, WorkflowConfigSchema * * ## Dataset Cache - MasterDataset Persistence with mtime Invalidation * @@ -18,7 +18,7 @@ * ### Design Decisions * * - DD-1: Excludes LoadedWorkflow (contains Maps), reconstructs on load via createLoadedWorkflow() - * - DD-2: Cache at node_modules/.cache/delivery-process/dataset.json + * - DD-2: Cache at node_modules/.cache/architect/dataset.json * - DD-3: Cache key = sha256(sorted file mtimes + pipeline options hash) * - DD-4: All errors produce cache miss (never throw) */ @@ -63,7 +63,7 @@ const CACHE_VERSION = '1'; * Resolve the cache directory for a given base directory. */ export function getCacheDir(baseDir: string): string { - return path.join(path.resolve(baseDir), 'node_modules', '.cache', 'delivery-process'); + return path.join(path.resolve(baseDir), 'node_modules', '.cache', 'architect'); } /** @@ -108,7 +108,7 @@ export async function computeCacheKey(opts: PipelineOptions): Promise { } // Also include config file mtime if it exists (.ts or .js) - for (const configName of ['delivery-process.config.ts', 'delivery-process.config.js']) { + for (const configName of ['architect.config.ts', 'architect.config.js']) { const configPath = path.join(baseDir, configName); try { const configStat = await fsp.stat(configPath); diff --git a/src/cli/error-handler.ts b/src/cli/error-handler.ts index c4314948..e9c98599 100644 --- a/src/cli/error-handler.ts +++ b/src/cli/error-handler.ts @@ -1,12 +1,12 @@ #!/usr/bin/env node /** - * @libar-docs - * @libar-docs-cli - * @libar-docs-pattern CLIErrorHandler - * @libar-docs-status completed - * @libar-docs-uses DocError - * @libar-docs-used-by LintPatternsCLI, ValidatePatternsCLI, DocumentationGeneratorCLI + * @architect + * @architect-cli + * @architect-pattern CLIErrorHandler + * @architect-status completed + * @architect-uses DocError + * @architect-used-by LintPatternsCLI, ValidatePatternsCLI, DocumentationGeneratorCLI * * ## CLIErrorHandler - Unified CLI Error Handling Utilities * diff --git a/src/cli/generate-docs.ts b/src/cli/generate-docs.ts index 2bea6f59..535cd38d 100644 --- a/src/cli/generate-docs.ts +++ b/src/cli/generate-docs.ts @@ -1,16 +1,16 @@ #!/usr/bin/env node /** - * @libar-docs - * @libar-docs-core @libar-docs-cli - * @libar-docs-pattern Documentation Generator CLI - * @libar-docs-status completed - * @libar-docs-uses Orchestrator, Generator Registry - * @libar-docs-used-by npm scripts, CI pipelines - * @libar-docs-usecase "When generating documentation from command line" - * @libar-docs-usecase "When integrating doc generation into npm scripts" - * @libar-docs-extract-shapes CLIConfig + * @architect + * @architect-core @architect-cli + * @architect-pattern Documentation Generator CLI + * @architect-status completed + * @architect-uses Orchestrator, Generator Registry + * @architect-used-by npm scripts, CI pipelines + * @architect-usecase "When generating documentation from command line" + * @architect-usecase "When integrating doc generation into npm scripts" + * @architect-extract-shapes CLIConfig * - * ## generate-docs - Single Entry Point for All Documentation Generation + * ## architect-generate - Single Entry Point for All Documentation Generation * * Replaces multiple specialized CLIs with one unified interface that supports * multiple generators in a single run. @@ -19,7 +19,7 @@ * * - Generating any documentation from annotated TypeScript source * - Running multiple generators in one command - * - Using delivery-process.config.ts for reproducible builds + * - Using architect.config.ts for reproducible builds * * ### Key Concepts * @@ -220,7 +220,7 @@ function parseArgs(argv: string[] = process.argv.slice(2)): CLIConfig { function showHelp(): void { console.log(` -Usage: generate-docs [options] +Usage: architect-generate [options] Generate documentation from annotated TypeScript source code. @@ -242,18 +242,18 @@ PR Changes Options (for -g pr-changes): --changed-files Explicit file list (repeatable, overrides git) --release-filter Filter by release version (e.g., v0.2.0) - When delivery-process.config.ts provides sources, --input is optional. + When architect.config.ts provides sources, --input is optional. CLI flags override config when both are provided. Examples: - generate-docs -i "src/**/*.ts" -o docs - generate-docs -i "src/**/*.ts" -g patterns -g adrs -f - generate-docs --list-generators + architect-generate -i "src/**/*.ts" -o docs + architect-generate -i "src/**/*.ts" -g patterns -g adrs -f + architect-generate --list-generators PR Changes Examples: - generate-docs -g pr-changes --git-diff-base main -o docs-living -f - generate-docs -g pr-changes --release-filter v0.2.0 -o docs-living -f - generate-docs -g pr-changes --changed-files src/foo.ts --changed-files src/bar.ts -o docs + architect-generate -g pr-changes --git-diff-base main -o docs-living -f + architect-generate -g pr-changes --release-filter v0.2.0 -o docs-living -f + architect-generate -g pr-changes --changed-files src/foo.ts --changed-files src/bar.ts -o docs `); } @@ -262,7 +262,7 @@ async function main(): Promise { // Show version if (opts.version) { - printVersionAndExit('generate-docs'); + printVersionAndExit('architect-generate'); } // Show help @@ -299,7 +299,7 @@ async function main(): Promise { const resolvedConfig = configResult.value; if (resolvedConfig.isDefault) { - console.log(' (No delivery-process.config.ts found; using defaults)'); + console.log(' (No architect.config.ts found; using defaults)'); } // Determine generators to run (CLI -g overrides config) @@ -332,7 +332,7 @@ async function main(): Promise { }); } else if (resolvedConfig.project.sources.typescript.length > 0) { // No CLI input — use config-based sources - console.log('Using sources from delivery-process.config.ts...'); + console.log('Using sources from architect.config.ts...'); console.log('Scanning source files...'); result = await generateFromConfig(resolvedConfig, { @@ -344,12 +344,10 @@ async function main(): Promise { } else { console.error('Error: No source files specified.'); console.error(''); - console.error( - 'Either provide --input flags or configure sources in delivery-process.config.ts:' - ); + console.error('Either provide --input flags or configure sources in architect.config.ts:'); console.error(''); - console.error(' // delivery-process.config.ts'); - console.error(' import { defineConfig } from "@libar-dev/delivery-process/config";'); + console.error(' // architect.config.ts'); + console.error(' import { defineConfig } from "@libar-dev/architect/config";'); console.error(' export default defineConfig({'); console.error(' sources: { typescript: ["src/**/*.ts"] }'); console.error(' });'); diff --git a/src/cli/generate-tag-taxonomy.ts b/src/cli/generate-tag-taxonomy.ts index c6d148b0..2d878212 100644 --- a/src/cli/generate-tag-taxonomy.ts +++ b/src/cli/generate-tag-taxonomy.ts @@ -1,12 +1,12 @@ #!/usr/bin/env node /** - * @libar-docs - * @libar-docs-cli - * @libar-docs-pattern TagTaxonomyCLI - * @libar-docs-status deferred - * @libar-docs-uses ConfigLoader, TagTaxonomyGenerator - * @libar-docs-extract-shapes CLIConfig + * @architect + * @architect-cli + * @architect-pattern TagTaxonomyCLI + * @architect-status deferred + * @architect-uses ConfigLoader, TagTaxonomyGenerator + * @architect-extract-shapes CLIConfig * * ## TagTaxonomyCLI - Tag Registry Documentation Generator * @@ -103,10 +103,10 @@ function parseArgs(argv: string[] = process.argv.slice(2)): CLIConfig { */ function printHelp(): void { console.log(` -generate-tag-taxonomy - Generate TAG_TAXONOMY.md from configuration +architect-taxonomy - Generate TAG_TAXONOMY.md from configuration Usage: - generate-tag-taxonomy [options] + architect-taxonomy [options] Options: -o, --output Output path for TAG_TAXONOMY.md (default: docs/architecture/TAG_TAXONOMY.md) @@ -116,18 +116,18 @@ Options: -v, --version Show version number Configuration: - Uses delivery-process.config.ts for taxonomy configuration. + Uses architect.config.ts for taxonomy configuration. Falls back to libar-generic preset (3 categories) if no config file found. Examples: # Generate using discovered config or default - generate-tag-taxonomy + architect-taxonomy # Custom output path - generate-tag-taxonomy -o docs/TAG_TAXONOMY.md + architect-taxonomy -o docs/TAG_TAXONOMY.md # Overwrite existing file - generate-tag-taxonomy -f + architect-taxonomy -f `); } @@ -138,7 +138,7 @@ async function main(): Promise { const config = parseArgs(); if (config.version) { - printVersionAndExit('generate-tag-taxonomy'); + printVersionAndExit('architect-taxonomy'); } if (config.help) { @@ -147,7 +147,7 @@ async function main(): Promise { } // Deprecation warning - console.warn('\n⚠️ DEPRECATED: generate-tag-taxonomy is deprecated.'); + console.warn('\n⚠️ DEPRECATED: architect-taxonomy is deprecated.'); console.warn(' Use `pnpm docs:taxonomy` instead for codec-based generation.'); console.warn(' The new approach provides progressive disclosure, domain grouping,'); console.warn(' and fits the MasterDataset pipeline architecture.\n'); @@ -155,7 +155,7 @@ async function main(): Promise { try { console.log('Loading configuration...'); - // Load configuration (discovers delivery-process.config.ts) + // Load configuration (discovers architect.config.ts) const configResult = await loadConfig(config.baseDir); if (!configResult.ok) { console.error(formatConfigError(configResult.error)); diff --git a/src/cli/lint-patterns.ts b/src/cli/lint-patterns.ts index 41199fe6..8aebb5ba 100644 --- a/src/cli/lint-patterns.ts +++ b/src/cli/lint-patterns.ts @@ -1,12 +1,12 @@ #!/usr/bin/env node /** - * @libar-docs - * @libar-docs-cli - * @libar-docs-pattern LintPatternsCLI - * @libar-docs-status completed - * @libar-docs-uses LintEngine, LintRules, PatternScanner - * @libar-docs-extract-shapes LintCLIConfig + * @architect + * @architect-cli + * @architect-pattern LintPatternsCLI + * @architect-status completed + * @architect-uses LintEngine, LintRules, PatternScanner + * @architect-extract-shapes LintCLIConfig * * ## LintPatternsCLI - Pattern Annotation Quality Checker * @@ -145,10 +145,10 @@ export function parseArgs(argv: string[] = process.argv.slice(2)): LintCLIConfig */ export function printHelp(): void { console.log(` -lint-patterns - Validate pattern annotation quality +architect-lint-patterns - Validate pattern annotation quality Usage: - lint-patterns [options] + architect-lint-patterns [options] Options: -i, --input Glob pattern for TypeScript files (required, repeatable) @@ -166,24 +166,24 @@ Exit Codes: 1 Errors found (or warnings with --strict) Lint Rules: - error missing-pattern-name Pattern must have @libar-docs-pattern name + error missing-pattern-name Pattern must have @architect-pattern name error tautological-description Description should not repeat pattern name - warning missing-status Pattern should have @libar-docs-status + warning missing-status Pattern should have @architect-status warning missing-when-to-use Pattern should have "When to Use" section - info missing-relationships Consider adding @libar-docs-uses/used-by + info missing-relationships Consider adding @architect-uses/used-by Examples: # Lint all @libar-dev/platform-* patterns - lint-patterns -i "packages/@libar-dev/platform-*/src/**/*.ts" + architect-lint-patterns -i "packages/@libar-dev/platform-*/src/**/*.ts" # Strict mode for CI (fail on warnings) - lint-patterns -i "packages/@libar-dev/platform-*/src/**/*.ts" --strict + architect-lint-patterns -i "packages/@libar-dev/platform-*/src/**/*.ts" --strict # JSON output for tooling - lint-patterns -i "src/**/*.ts" --format json + architect-lint-patterns -i "src/**/*.ts" --format json # Only show errors - lint-patterns -i "src/**/*.ts" --quiet + architect-lint-patterns -i "src/**/*.ts" --quiet `); } @@ -194,7 +194,7 @@ async function main(): Promise { const config = parseArgs(); if (config.version) { - printVersionAndExit('lint-patterns'); + printVersionAndExit('architect-lint-patterns'); } if (config.help) { @@ -209,7 +209,7 @@ async function main(): Promise { } try { - // Load configuration (discovers delivery-process.config.ts) + // Load configuration (discovers architect.config.ts) const configResult = await loadConfig(config.baseDir); if (!configResult.ok) { console.error(formatConfigError(configResult.error)); diff --git a/src/cli/lint-process.ts b/src/cli/lint-process.ts index f33fc9e9..8d092929 100644 --- a/src/cli/lint-process.ts +++ b/src/cli/lint-process.ts @@ -1,13 +1,13 @@ #!/usr/bin/env node /** - * @libar-docs - * @libar-docs-cli - * @libar-docs-lint - * @libar-docs-pattern LintProcessCLI - * @libar-docs-status active - * @libar-docs-uses ProcessGuardModule - * @libar-docs-extract-shapes ProcessGuardCLIConfig + * @architect + * @architect-cli + * @architect-lint + * @architect-pattern LintProcessCLI + * @architect-status active + * @architect-uses ProcessGuardModule + * @architect-extract-shapes ProcessGuardCLIConfig * * ## LintProcessCLI - Process Guard Linter CLI * @@ -139,10 +139,10 @@ export function parseArgs(argv: string[] = process.argv.slice(2)): ProcessGuardC */ export function printHelp(): void { console.log(` -lint-process - Validate changes against delivery process rules +architect-guard - Validate changes against delivery process rules Usage: - lint-process [options] [files...] + architect-guard [options] [files...] Modes: --staged Validate staged changes (default, for pre-commit) @@ -173,16 +173,16 @@ Rules Checked: Examples: # Pre-commit hook (default) - lint-process --staged + architect-guard --staged # CI/CD pipeline - lint-process --all --strict + architect-guard --all --strict # Check specific files - lint-process --file path/to/spec.feature + architect-guard --file path/to/spec.feature # Debugging - show derived state - lint-process --staged --show-state + architect-guard --staged --show-state `); } @@ -247,7 +247,7 @@ async function main(): Promise { const config = parseArgs(); if (config.version) { - printVersionAndExit('lint-process'); + printVersionAndExit('architect-guard'); } if (config.help) { diff --git a/src/cli/lint-steps.ts b/src/cli/lint-steps.ts index 0c955589..a3bbadbc 100644 --- a/src/cli/lint-steps.ts +++ b/src/cli/lint-steps.ts @@ -95,7 +95,7 @@ export function parseArgs(argv: string[] = process.argv.slice(2)): LintStepsCLIC */ export function printHelp(): void { console.log(` -lint-steps - Validate vitest-cucumber feature/step compatibility +architect-lint-steps - Validate vitest-cucumber feature/step compatibility Detects common traps statically before tests run: - {string} function params inside ScenarioOutline (should use variables) @@ -108,7 +108,7 @@ Detects common traps statically before tests run: - $ in step text (causes matching issues) Usage: - lint-steps [options] + architect-lint-steps [options] Options: --strict Treat warnings as errors (exit 1 on warnings) @@ -123,8 +123,8 @@ Exit Codes: Scan Scope: Feature files: tests/features/**/*.feature - delivery-process/specs/**/*.feature - delivery-process/decisions/**/*.feature + architect/specs/**/*.feature + architect/decisions/**/*.feature Step files: tests/steps/**/*.steps.ts Rules: @@ -143,13 +143,13 @@ Rules: Examples: # Standard check - lint-steps + architect-lint-steps # Strict mode (warnings are errors) - lint-steps --strict + architect-lint-steps --strict # JSON output for CI - lint-steps --format json + architect-lint-steps --format json `); } @@ -160,7 +160,7 @@ function main(): void { const config = parseArgs(); if (config.version) { - printVersionAndExit('lint-steps'); + printVersionAndExit('architect-lint-steps'); } if (config.help) { diff --git a/src/cli/mcp-server.ts b/src/cli/mcp-server.ts index 35376e16..bfa62704 100644 --- a/src/cli/mcp-server.ts +++ b/src/cli/mcp-server.ts @@ -1,14 +1,14 @@ #!/usr/bin/env node /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern MCPServerBin - * @libar-docs-status active - * @libar-docs-arch-role infrastructure - * @libar-docs-arch-context cli - * @libar-docs-arch-layer infrastructure - * @libar-docs-uses MCPServerImpl - * @libar-docs-implements MCPServerIntegration + * @architect + * @architect-core + * @architect-pattern MCPServerBin + * @architect-status active + * @architect-arch-role infrastructure + * @architect-arch-context cli + * @architect-arch-layer infrastructure + * @architect-uses MCPServerImpl + * @architect-implements MCPServerIntegration * * ## MCP Server CLI Entry Point * @@ -41,7 +41,7 @@ switch (parsed.type) { process.exit(0); break; case 'error': - console.error(`[dp-mcp] Error: ${parsed.message}`); + console.error(`[architect-mcp] Error: ${parsed.message}`); process.exit(1); break; case 'options': diff --git a/src/cli/output-pipeline.ts b/src/cli/output-pipeline.ts index 299710a2..e71b249f 100644 --- a/src/cli/output-pipeline.ts +++ b/src/cli/output-pipeline.ts @@ -1,14 +1,14 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern OutputPipelineImpl - * @libar-docs-status active - * @libar-docs-implements DataAPIOutputShaping - * @libar-docs-uses PatternSummarizerImpl - * @libar-docs-used-by ProcessAPICLIImpl - * @libar-docs-arch-role service - * @libar-docs-arch-context cli - * @libar-docs-arch-layer application + * @architect + * @architect-core + * @architect-pattern OutputPipelineImpl + * @architect-status active + * @architect-implements DataAPIOutputShaping + * @architect-uses PatternSummarizerImpl + * @architect-used-by ProcessAPICLIImpl + * @architect-arch-role service + * @architect-arch-context cli + * @architect-arch-layer application * * ## OutputPipeline — CLI Output Shaping and Formatting * @@ -72,9 +72,9 @@ export interface ListFilters { readonly category: string | null; /** Filter by source type */ readonly source: 'typescript' | 'gherkin' | null; - /** Filter by architecture context (@libar-docs-arch-context) */ + /** Filter by architecture context (@architect-arch-context) */ readonly archContext: string | null; - /** Filter by product area (@libar-docs-product-area) */ + /** Filter by product area (@architect-product-area) */ readonly productArea: string | null; /** Maximum number of results */ readonly limit: number | null; diff --git a/src/cli/process-api.ts b/src/cli/process-api.ts index c7a1eacc..b31d244c 100644 --- a/src/cli/process-api.ts +++ b/src/cli/process-api.ts @@ -1,19 +1,19 @@ #!/usr/bin/env node /** - * @libar-docs - * @libar-docs-core @libar-docs-cli - * @libar-docs-pattern ProcessAPICLIImpl - * @libar-docs-status active - * @libar-docs-implements ProcessStateAPICLI - * @libar-docs-arch-role service - * @libar-docs-arch-context cli - * @libar-docs-arch-layer application - * @libar-docs-uses ProcessStateAPI, MasterDataset, PipelineFactory, RulesQueryModule, PatternSummarizerImpl, FuzzyMatcherImpl, OutputPipelineImpl - * @libar-docs-used-by npm scripts, Claude Code sessions - * @libar-docs-usecase "When querying delivery process state from CLI" - * @libar-docs-usecase "When Claude Code needs real-time delivery state queries" + * @architect + * @architect-core @architect-cli + * @architect-pattern ProcessAPICLIImpl + * @architect-status active + * @architect-implements ProcessStateAPICLI + * @architect-arch-role service + * @architect-arch-context cli + * @architect-arch-layer application + * @architect-uses ProcessStateAPI, MasterDataset, PipelineFactory, RulesQueryModule, PatternSummarizerImpl, FuzzyMatcherImpl, OutputPipelineImpl + * @architect-used-by npm scripts, Claude Code sessions + * @architect-usecase "When querying delivery process state from CLI" + * @architect-usecase "When Claude Code needs real-time delivery state queries" * - * ## process-api - CLI Query Interface to ProcessStateAPI + * ## architect - CLI Query Interface to ProcessStateAPI * * Exposes ProcessStateAPI methods as CLI subcommands with JSON output. * Runs pipeline steps 1-8 (config -> scan -> extract -> transform), @@ -23,13 +23,13 @@ * * - When Claude Code needs real-time delivery state queries * - When AI agents need structured JSON instead of regenerating markdown - * - When scripting delivery process queries in CI/CD + * - When scripting architect queries in CI/CD * * ### Key Concepts * * - **Subcommand Routing**: CLI subcommands map to ProcessStateAPI methods * - **JSON Output**: All output is JSON to stdout, errors to stderr - * - **Pipeline Reuse**: Steps 1-8 match generate-docs exactly + * - **Pipeline Reuse**: Steps 1-8 match architect-generate exactly * - **QueryResult Envelope**: All output wrapped in success/error discriminated union * - **Output Shaping**: 594KB -> 4KB via summarization and modifiers */ @@ -389,12 +389,12 @@ function showHelp(): void { const sessions = formatHelpOptions(CLI_SCHEMA.sessionOptions); console.log(` -process-api - Query delivery process state from annotated sources +architect - Query delivery process state from annotated sources Use this instead of reading generated markdown or launching explore agents. Targeted queries use 5-10x less context than file reads. -Usage: process-api [options] [args...] +Usage: architect [options] [args...] Quick Start — Session Recipe: @@ -455,7 +455,7 @@ Metadata & Inventory: tags Tag usage report (counts per tag and value) sources File inventory by type (TS, Gherkin, Stubs) - unannotated [--path dir] TypeScript files missing @libar-docs annotations + unannotated [--path dir] TypeScript files missing @architect annotations query [args...] Execute any query API method directly Options: @@ -477,28 +477,28 @@ ${sessions} Common Recipes: Starting a session: - process-api overview - process-api scope-validate MyPattern implement - process-api context MyPattern --session implement + architect overview + architect scope-validate MyPattern implement + architect context MyPattern --session implement Finding what to work on: - process-api list --status roadmap --names-only - process-api arch blocking - process-api query getRoadmapItems --names-only + architect list --status roadmap --names-only + architect arch blocking + architect query getRoadmapItems --names-only Investigating a pattern: - process-api search EventStore - process-api dep-tree EventStoreDurability --depth 2 - process-api arch neighborhood EventStoreDurability - process-api stubs EventStoreDurability + architect search EventStore + architect dep-tree EventStoreDurability --depth 2 + architect arch neighborhood EventStoreDurability + architect stubs EventStoreDurability Design session prep: - process-api context MyPattern --session design - process-api decisions MyPattern - process-api stubs --unresolved + architect context MyPattern --session design + architect decisions MyPattern + architect stubs --unresolved Ending a session: - process-api handoff --pattern MyPattern + architect handoff --pattern MyPattern Session Types (for --session flag): @@ -536,7 +536,7 @@ function showSubcommandHelp(subcommand: string): void { for (const group of narratives) { for (const cmd of group.commands) { if (cmd.command === subcommand) { - console.log(`\nprocess-api ${subcommand} — ${cmd.description}\n`); + console.log(`\narchitect ${subcommand} — ${cmd.description}\n`); console.log(`Usage: ${cmd.usageExample}\n`); if (cmd.details !== undefined) { console.log(cmd.details); @@ -566,7 +566,7 @@ function showSubcommandHelp(subcommand: string): void { // Fallback: subcommand not found in narratives console.log(`\nNo detailed help available for '${subcommand}'.`); - console.log('Run process-api --help for the full command reference.\n'); + console.log('Run architect --help for the full command reference.\n'); } /** @@ -604,7 +604,7 @@ async function executeDryRun(opts: ProcessAPICLIConfig): Promise { const featureFiles = await glob(opts.features, { cwd: baseDir }); // Check config file - const configPath = path.join(baseDir, 'delivery-process.config.ts'); + const configPath = path.join(baseDir, 'architect.config.ts'); const hasConfig = fs.existsSync(configPath); // Check cache status @@ -613,7 +613,7 @@ async function executeDryRun(opts: ProcessAPICLIConfig): Promise { console.log('=== DRY RUN ==='); console.log( - `Config: ${hasConfig ? 'delivery-process.config.ts (auto-detected)' : 'none (filesystem fallback)'}` + `Config: ${hasConfig ? 'architect.config.ts (auto-detected)' : 'none (filesystem fallback)'}` ); console.log(`Base dir: ${baseDir}`); console.log(`Input patterns: ${opts.input.join(', ')}`); @@ -640,7 +640,7 @@ async function executeDryRun(opts: ProcessAPICLIConfig): Promise { /** * If --input and --features are not provided, try to load defaults from config. - * Prefers loadProjectConfig() for repos with delivery-process.config.ts, + * Prefers loadProjectConfig() for repos with architect.config.ts, * falls back to filesystem auto-detection for repos without one. */ async function applyConfigDefaults(config: ProcessAPICLIConfig): Promise { @@ -662,25 +662,25 @@ function applyConfigDefaultsFallback(config: ProcessAPICLIConfig): void { if (config.input.length === 0) { // Check for config file existence as signal to use defaults - const configPath = path.join(baseDir, 'delivery-process.config.ts'); + const configPath = path.join(baseDir, 'architect.config.ts'); if (fs.existsSync(configPath)) { config.input.push('src/**/*.ts'); // Also check for stubs directory - const stubsDir = path.join(baseDir, 'delivery-process', 'stubs'); + const stubsDir = path.join(baseDir, 'architect', 'stubs'); if (fs.existsSync(stubsDir)) { - config.input.push('delivery-process/stubs/**/*.ts'); + config.input.push('architect/stubs/**/*.ts'); } } } if (config.features.length === 0) { - const specsDir = path.join(baseDir, 'delivery-process', 'specs'); + const specsDir = path.join(baseDir, 'architect', 'specs'); if (fs.existsSync(specsDir)) { - config.features.push('delivery-process/specs/*.feature'); + config.features.push('architect/specs/*.feature'); } - const releasesDir = path.join(baseDir, 'delivery-process', 'releases'); + const releasesDir = path.join(baseDir, 'architect', 'releases'); if (fs.existsSync(releasesDir)) { - config.features.push('delivery-process/releases/*.feature'); + config.features.push('architect/releases/*.feature'); } } } @@ -763,7 +763,7 @@ function tryFsmShortCircuit(subcommand: string, subArgs: readonly string[]): unk switch (methodName) { case 'isValidTransition': { - const usage = 'Usage: process-api query isValidTransition '; + const usage = 'Usage: architect query isValidTransition '; const from = parseProcessStatus(fsmArgs[0], usage, 'fromStatus'); const to = parseProcessStatus(fsmArgs[1], usage, 'toStatus'); return fsmIsValidTransition(from, to); @@ -775,7 +775,7 @@ function tryFsmShortCircuit(subcommand: string, subArgs: readonly string[]): unk if (from === undefined || to === undefined) { throw new QueryApiError( 'INVALID_ARGUMENT', - 'Usage: process-api query checkTransition ' + 'Usage: architect query checkTransition ' ); } const result = fsmValidateTransition(from, to); @@ -791,7 +791,7 @@ function tryFsmShortCircuit(subcommand: string, subArgs: readonly string[]): unk case 'getValidTransitionsFrom': { const status = parseProcessStatus( fsmArgs[0], - 'Usage: process-api query getValidTransitionsFrom ', + 'Usage: architect query getValidTransitionsFrom ', 'status' ); return fsmGetValidTransitionsFrom(status); @@ -800,7 +800,7 @@ function tryFsmShortCircuit(subcommand: string, subArgs: readonly string[]): unk case 'getProtectionInfo': { const status = parseProcessStatus( fsmArgs[0], - 'Usage: process-api query getProtectionInfo ', + 'Usage: architect query getProtectionInfo ', 'status' ); const summary = fsmGetProtectionSummary(status); @@ -999,7 +999,7 @@ function handleQuery( if (!methodName) { throw new QueryApiError( 'INVALID_ARGUMENT', - 'Usage: process-api query [args...]\nMethods: ' + API_METHODS.join(', ') + 'Usage: architect query [args...]\nMethods: ' + API_METHODS.join(', ') ); } @@ -1018,7 +1018,7 @@ function handleQuery( function handlePattern(api: ProcessStateAPI, args: string[]): unknown { const name = args[0]; if (!name) { - throw new QueryApiError('INVALID_ARGUMENT', 'Usage: process-api pattern '); + throw new QueryApiError('INVALID_ARGUMENT', 'Usage: architect pattern '); } const pattern = api.getPattern(name); @@ -1178,7 +1178,7 @@ function handleList( function handleSearch(api: ProcessStateAPI, subArgs: string[]): unknown { const query = subArgs[0]; if (!query) { - throw new QueryApiError('INVALID_ARGUMENT', 'Usage: process-api search '); + throw new QueryApiError('INVALID_ARGUMENT', 'Usage: architect search '); } const names = allPatternNames(api.getMasterDataset()); @@ -1206,7 +1206,7 @@ async function handleArch(ctx: RouteContext): Promise { if (!archIndex || archIndex.all.length === 0) { throw new QueryApiError( 'PATTERN_NOT_FOUND', - 'No architecture data available. Ensure patterns have @libar-docs-arch-role annotations.' + 'No architecture data available. Ensure patterns have @architect-arch-role annotations.' ); } @@ -1261,10 +1261,7 @@ async function handleArch(ctx: RouteContext): Promise { case 'neighborhood': { const patternName = args[1]; if (!patternName) { - throw new QueryApiError( - 'INVALID_ARGUMENT', - 'Usage: process-api arch neighborhood ' - ); + throw new QueryApiError('INVALID_ARGUMENT', 'Usage: architect arch neighborhood '); } const neighborhood = computeNeighborhood(patternName, ctx.dataset); if (neighborhood === undefined) { @@ -1278,10 +1275,7 @@ async function handleArch(ctx: RouteContext): Promise { const ctx1Name = args[1]; const ctx2Name = args[2]; if (!ctx1Name || !ctx2Name) { - throw new QueryApiError( - 'INVALID_ARGUMENT', - 'Usage: process-api arch compare ' - ); + throw new QueryApiError('INVALID_ARGUMENT', 'Usage: architect arch compare '); } const comparison = compareContexts(ctx1Name, ctx2Name, ctx.dataset); if (comparison === undefined) { @@ -1568,7 +1562,7 @@ function handleContext(ctx: RouteContext): string { if (patternNames.length === 0) { throw new QueryApiError( 'CONTEXT_ASSEMBLY_ERROR', - 'Usage: process-api context [pattern2...] [--session planning|design|implement]' + 'Usage: architect context [pattern2...] [--session planning|design|implement]' ); } @@ -1586,7 +1580,7 @@ function handleFiles(ctx: RouteContext): string { if (patternName === undefined) { throw new QueryApiError( 'CONTEXT_ASSEMBLY_ERROR', - 'Usage: process-api files [--related]' + 'Usage: architect files [--related]' ); } @@ -1600,7 +1594,7 @@ function handleDepTreeCmd(ctx: RouteContext): string { if (patternName === undefined) { throw new QueryApiError( 'CONTEXT_ASSEMBLY_ERROR', - 'Usage: process-api dep-tree [--depth N]' + 'Usage: architect dep-tree [--depth N]' ); } @@ -1656,7 +1650,7 @@ function handleScopeValidate(ctx: RouteContext): string { } i++; } else if (arg === '--strict') { - // DD-4: promotes WARN → BLOCKED (consistent with lint-process --strict) + // DD-4: promotes WARN → BLOCKED (consistent with architect-guard --strict) strict = true; } else if (arg !== undefined && !arg.startsWith('-')) { if (patternName === undefined) { @@ -1671,7 +1665,7 @@ function handleScopeValidate(ctx: RouteContext): string { if (patternName === undefined) { throw new QueryApiError( 'INVALID_ARGUMENT', - 'Usage: process-api scope-validate [implement|design] [--type implement|design] [--strict]' + 'Usage: architect scope-validate [implement|design] [--type implement|design] [--strict]' ); } @@ -1730,7 +1724,7 @@ function handleHandoff(ctx: RouteContext): string { if (patternName === undefined) { throw new QueryApiError( 'INVALID_ARGUMENT', - 'Usage: process-api handoff --pattern [--git] [--session planning|design|implement|review]' + 'Usage: architect handoff --pattern [--git] [--session planning|design|implement|review]' ); } @@ -1900,7 +1894,7 @@ async function main(): Promise { const opts = parseArgs(); if (opts.version) { - printVersionAndExit('process-api'); + printVersionAndExit('architect'); } if (opts.help || !opts.subcommand) { @@ -1908,7 +1902,7 @@ async function main(): Promise { process.exit(opts.help ? 0 : 1); } - // Per-subcommand help (e.g., `process-api context --help`) + // Per-subcommand help (e.g., `architect context --help`) if (opts.subcommandHelp !== null) { showSubcommandHelp(opts.subcommandHelp); process.exit(0); @@ -1945,11 +1939,11 @@ async function main(): Promise { if (opts.input.length === 0) { console.error( - 'Error: --input is required (or place delivery-process.config.ts in cwd for auto-detection)' + 'Error: --input is required (or place architect.config.ts in cwd for auto-detection)' ); console.error(''); console.error('Example:'); - console.error(' process-api -i "src/**/*.ts" status'); + console.error(' architect -i "src/**/*.ts" status'); process.exit(1); } diff --git a/src/cli/repl.ts b/src/cli/repl.ts index 0962b445..c0af90b3 100644 --- a/src/cli/repl.ts +++ b/src/cli/repl.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-cli - * @libar-docs-pattern ReplMode - * @libar-docs-status active - * @libar-docs-implements DataAPICLIErgonomics - * @libar-docs-arch-role service - * @libar-docs-arch-context cli - * @libar-docs-arch-layer application - * @libar-docs-uses PipelineFactory, ProcessStateAPI + * @architect + * @architect-cli + * @architect-pattern ReplMode + * @architect-status active + * @architect-implements DataAPICLIErgonomics + * @architect-arch-role service + * @architect-arch-context cli + * @architect-arch-layer application + * @architect-uses PipelineFactory, ProcessStateAPI * * ## REPL Mode - Interactive Multi-Query Pipeline Session * @@ -217,7 +217,7 @@ async function runInteractiveRepl(state: ReplState, opts: ReplOptions): Promise< const rl = readline.createInterface({ input: process.stdin, output: process.stderr, - prompt: 'process-api> ', + prompt: 'architect> ', }); rl.prompt(); diff --git a/src/cli/validate-patterns.ts b/src/cli/validate-patterns.ts index cf2ef7a0..96022a8e 100644 --- a/src/cli/validate-patterns.ts +++ b/src/cli/validate-patterns.ts @@ -1,12 +1,12 @@ #!/usr/bin/env node /** - * @libar-docs - * @libar-docs-cli - * @libar-docs-pattern ValidatePatternsCLI - * @libar-docs-status completed - * @libar-docs-uses PatternScanner, GherkinScanner, DocExtractor, GherkinExtractor, MasterDataset, CodecUtils - * @libar-docs-extract-shapes ValidateCLIConfig, ValidationIssue, ValidationSummary + * @architect + * @architect-cli + * @architect-pattern ValidatePatternsCLI + * @architect-status completed + * @architect-uses PatternScanner, GherkinScanner, DocExtractor, GherkinExtractor, MasterDataset, CodecUtils + * @architect-extract-shapes ValidateCLIConfig, ValidationIssue, ValidationSummary * * ## ValidatePatternsCLI - Cross-Source Pattern Validator * @@ -253,10 +253,10 @@ export function parseArgs(argv: string[] = process.argv.slice(2)): ValidateCLICo */ export function printHelp(): void { console.log(` -validate-patterns - Cross-validate TypeScript patterns vs Gherkin features +architect-validate - Cross-validate TypeScript patterns vs Gherkin features Usage: - validate-patterns [options] + architect-validate [options] Options: -i, --input Glob pattern for TypeScript files (repeatable; falls back to config) @@ -306,22 +306,22 @@ Anti-Pattern Detection (--anti-patterns): Examples: # Cross-source validation - validate-patterns -i "src/**/*.ts" -F "tests/features/**/*.feature" + architect-validate -i "src/**/*.ts" -F "tests/features/**/*.feature" # DoD validation for all completed phases - validate-patterns -i "src/**/*.ts" -F "features/**/*.feature" --dod + architect-validate -i "src/**/*.ts" -F "features/**/*.feature" --dod # DoD validation for specific phase - validate-patterns -i "src/**/*.ts" -F "features/**/*.feature" --dod --phase 14 + architect-validate -i "src/**/*.ts" -F "features/**/*.feature" --dod --phase 14 # Anti-pattern detection - validate-patterns -i "src/**/*.ts" -F "features/**/*.feature" --anti-patterns + architect-validate -i "src/**/*.ts" -F "features/**/*.feature" --anti-patterns # Full validation (cross-source + DoD + anti-patterns) - validate-patterns -i "src/**/*.ts" -F "features/**/*.feature" --dod --anti-patterns --strict + architect-validate -i "src/**/*.ts" -F "features/**/*.feature" --dod --anti-patterns --strict # JSON output for tooling - validate-patterns -i "src/**/*.ts" -F "features/**/*.feature" --format json + architect-validate -i "src/**/*.ts" -F "features/**/*.feature" --format json `); } @@ -431,7 +431,7 @@ export function validatePatterns(dataset: RuntimeMasterDataset): ValidationSumma // If the Gherkin pattern explicitly implements a DIFFERENT pattern, it's not // a true name match — it's a naming collision. The Gherkin pattern belongs to - // whichever pattern it declares in @libar-docs-implements. + // whichever pattern it declares in @architect-implements. if (gherkinMatch !== undefined) { const gherkinImpl = gherkinMatch.implementsPatterns ?? []; if (gherkinImpl.length > 0 && !gherkinImpl.some((n) => n.toLowerCase() === tsName)) { @@ -672,7 +672,7 @@ async function main(): Promise { const config = parseArgs(); if (config.version) { - printVersionAndExit('validate-patterns'); + printVersionAndExit('architect-validate'); } if (config.help) { @@ -684,23 +684,23 @@ async function main(): Promise { const configApplied = await applyProjectSourceDefaults(config); if (!configApplied && config.input.length === 0) { - console.error(' (No delivery-process.config.ts found; provide -i/--input flags)'); + console.error(' (No architect.config.ts found; provide -i/--input flags)'); } // Validate that we have sources (from CLI or config) if (config.input.length === 0) { console.error('Error: No TypeScript sources specified.'); - console.error('Provide -i/--input flags or configure sources in delivery-process.config.ts'); + console.error('Provide -i/--input flags or configure sources in architect.config.ts'); process.exit(1); } if (config.features.length === 0) { console.error('Error: No feature files specified.'); - console.error('Provide -F/--features flags or configure sources in delivery-process.config.ts'); + console.error('Provide -F/--features flags or configure sources in architect.config.ts'); process.exit(1); } try { - // Load configuration (discovers delivery-process.config.ts) + // Load configuration (discovers architect.config.ts) const configResult = await loadConfig(config.baseDir); if (!configResult.ok) { console.error(formatConfigError(configResult.error)); diff --git a/src/cli/version.ts b/src/cli/version.ts index 4f7f49bf..8c9ef4e3 100644 --- a/src/cli/version.ts +++ b/src/cli/version.ts @@ -1,9 +1,9 @@ /** - * @libar-docs - * @libar-docs-cli - * @libar-docs-pattern CLIVersionHelper - * @libar-docs-status completed - * @libar-docs-used-by DocumentationGeneratorCLI, LintPatternsCLI, TagTaxonomyCLI, ValidatePatternsCLI + * @architect + * @architect-cli + * @architect-pattern CLIVersionHelper + * @architect-status completed + * @architect-used-by DocumentationGeneratorCLI, LintPatternsCLI, TagTaxonomyCLI, ValidatePatternsCLI * * ## CLIVersionHelper - Package Version Reader * @@ -44,7 +44,7 @@ export function getPackageVersion(): string { /** * Get the package name from package.json * - * @returns Package name (e.g., "@libar-dev/delivery-process") + * @returns Package name (e.g., "@libar-dev/architect") */ export function getPackageName(): string { try { @@ -55,9 +55,9 @@ export function getPackageName(): string { const packageJson = JSON.parse(readFileSync(packagePath, 'utf-8')) as { name?: string; }; - return packageJson.name ?? 'delivery-process'; + return packageJson.name ?? 'architect'; } catch { - return 'delivery-process'; + return 'architect'; } } diff --git a/src/config/config-loader.ts b/src/config/config-loader.ts index 2dcc61ff..0f1012f5 100644 --- a/src/config/config-loader.ts +++ b/src/config/config-loader.ts @@ -1,18 +1,18 @@ /** - * @libar-docs - * @libar-docs-core @libar-docs-config - * @libar-docs-pattern ConfigLoader - * @libar-docs-status completed - * @libar-docs-arch-role infrastructure - * @libar-docs-arch-context config - * @libar-docs-arch-layer infrastructure - * @libar-docs-uses DeliveryProcessFactory, ConfigurationTypes - * @libar-docs-used-by CLI - * @libar-docs-extract-shapes ConfigDiscoveryResult, ConfigLoadError, ConfigLoadResult, findConfigFile, loadConfig, formatConfigError + * @architect + * @architect-core @architect-config + * @architect-pattern ConfigLoader + * @architect-status completed + * @architect-arch-role infrastructure + * @architect-arch-context config + * @architect-arch-layer infrastructure + * @architect-uses ArchitectFactory, ConfigurationTypes + * @architect-used-by CLI + * @architect-extract-shapes ConfigDiscoveryResult, ConfigLoadError, ConfigLoadResult, findConfigFile, loadConfig, formatConfigError * * ## Config Loader - TypeScript Configuration File Discovery * - * Discovers and loads `delivery-process.config.ts` files for hierarchical configuration. + * Discovers and loads `architect.config.ts` files for hierarchical configuration. * Supports package-level and repo-level configuration inheritance. * * ### When to Use @@ -23,42 +23,48 @@ * * ### Discovery Strategy * - * 1. Look for `delivery-process.config.ts` in current directory + * 1. Look for `architect.config.ts` in current directory * 2. Walk up parent directories until repo root (contains .git) * 3. Stop at first config found or fall back to default * * ### Config File Format * - * Config files should export a `DeliveryProcessInstance`: + * Config files should export a `ArchitectInstance`: * * ```typescript - * import { createDeliveryProcess } from '@libar-dev/delivery-process'; + * import { createArchitect } from '@libar-dev/architect'; * - * export default createDeliveryProcess({ preset: "libar-generic" }); + * export default createArchitect({ preset: "libar-generic" }); * ``` */ import * as fs from 'fs/promises'; import * as path from 'path'; import { pathToFileURL } from 'url'; -import type { DeliveryProcessProjectConfig, ResolvedConfig } from './project-config.js'; +import type { ArchitectProjectConfig, ResolvedConfig } from './project-config.js'; import { isProjectConfig, isLegacyInstance, - DeliveryProcessProjectConfigSchema, + ArchitectProjectConfigSchema, } from './project-config-schema.js'; import { resolveProjectConfig, createDefaultResolvedConfig } from './resolve-config.js'; -import type { DeliveryProcessInstance } from './types.js'; +import type { ArchitectInstance } from './types.js'; /** * Config file name to search for */ -const CONFIG_FILE_NAME = 'delivery-process.config.ts'; +const CONFIG_FILE_NAME = 'architect.config.ts'; /** * Compiled JavaScript variant (for projects that pre-compile configs) */ -const CONFIG_FILE_NAME_JS = 'delivery-process.config.js'; +const CONFIG_FILE_NAME_JS = 'architect.config.js'; + +/** + * Legacy config file names (deprecated, emit warning if found) + */ +const LEGACY_CONFIG_FILE_NAME = 'delivery-process.config.ts'; +const LEGACY_CONFIG_FILE_NAME_JS = 'delivery-process.config.js'; /** * Result of config file discovery @@ -69,7 +75,7 @@ export interface ConfigDiscoveryResult { /** Absolute path to the config file (if found) */ path?: string; /** The loaded configuration instance */ - instance: DeliveryProcessInstance; + instance: ArchitectInstance; /** Whether the default configuration was used */ isDefault: boolean; } @@ -153,6 +159,22 @@ export async function findConfigFile(startDir: string): Promise { return jsConfigPath; } + // Check for legacy config file names (backward compat) + const legacyTsPath = path.join(currentDir, LEGACY_CONFIG_FILE_NAME); + if (await fileExists(legacyTsPath)) { + console.error( + `Warning: '${LEGACY_CONFIG_FILE_NAME}' is deprecated. Rename to '${CONFIG_FILE_NAME}'.` + ); + return legacyTsPath; + } + const legacyJsPath = path.join(currentDir, LEGACY_CONFIG_FILE_NAME_JS); + if (await fileExists(legacyJsPath)) { + console.error( + `Warning: '${LEGACY_CONFIG_FILE_NAME_JS}' is deprecated. Rename to '${CONFIG_FILE_NAME_JS}'.` + ); + return legacyJsPath; + } + // Stop at repo root to avoid walking too far if (await isRepoRoot(currentDir)) { break; @@ -252,11 +274,11 @@ export type ProjectConfigLoadResult = /** * Load unified project configuration from file or use defaults. * - * Supports both new-style `DeliveryProcessProjectConfig` (via `defineConfig()`) - * and legacy `DeliveryProcessInstance` (via `createDeliveryProcess()`) config files. + * Supports both new-style `ArchitectProjectConfig` (via `defineConfig()`) + * and legacy `ArchitectInstance` (via `createArchitect()`) config files. * * Discovery strategy: - * 1. Search for `delivery-process.config.ts` starting from baseDir + * 1. Search for `architect.config.ts` starting from baseDir * 2. Walk up parent directories until repo root * 3. If found, import and resolve the configuration * 4. If not found, return default resolved config @@ -342,7 +364,7 @@ export async function loadProjectConfig(baseDir: string): Promise `${issue.path.join('.')}: ${issue.message}`) @@ -375,7 +397,7 @@ export async function loadProjectConfig(baseDir: string): Promise = { +export const PRESETS: Record = { generic: GENERIC_PRESET, 'libar-generic': LIBAR_GENERIC_PRESET, 'ddd-es-cqrs': DDD_ES_CQRS_PRESET, diff --git a/src/config/project-config-schema.ts b/src/config/project-config-schema.ts index ee338d1b..4e457aa7 100644 --- a/src/config/project-config-schema.ts +++ b/src/config/project-config-schema.ts @@ -1,17 +1,17 @@ /** - * @libar-docs - * @libar-docs-core @libar-docs-config - * @libar-docs-pattern ProjectConfigSchema - * @libar-docs-status active - * @libar-docs-arch-layer infrastructure - * @libar-docs-arch-context config - * @libar-docs-arch-role infrastructure - * @libar-docs-uses ProjectConfigTypes - * @libar-docs-used-by ConfigLoader + * @architect + * @architect-core @architect-config + * @architect-pattern ProjectConfigSchema + * @architect-status active + * @architect-arch-layer infrastructure + * @architect-arch-context config + * @architect-arch-role infrastructure + * @architect-uses ProjectConfigTypes + * @architect-used-by ConfigLoader * * ## Project Configuration Schema * - * Zod validation schema for `DeliveryProcessProjectConfig`. + * Zod validation schema for `ArchitectProjectConfig`. * Validates at load time (not at `defineConfig()` call time) * following the Vite/Vitest identity-function convention. * @@ -22,12 +22,12 @@ * - Preset name must be one of the known presets * - `replaceFeatures` and `additionalFeatures` are mutually exclusive * - * **When to Use:** When loading and validating project configuration from `delivery-process.config.ts` at startup. + * **When to Use:** When loading and validating project configuration from `architect.config.ts` at startup. */ import { z } from 'zod'; -import type { DeliveryProcessProjectConfig } from './project-config.js'; -import type { DeliveryProcessInstance } from './types.js'; +import type { ArchitectProjectConfig } from './project-config.js'; +import type { ArchitectInstance } from './types.js'; // Cross-layer: config → renderable (see comment in project-config.ts) import { DIAGRAM_SOURCE_VALUES } from '../renderable/codecs/reference.js'; import { SectionBlockSchema } from '../renderable/schema.js'; @@ -188,7 +188,7 @@ const ReferenceDocConfigSchema = z * The `defineConfig()` identity function does NOT validate — * it only provides TypeScript type checking. */ -export const DeliveryProcessProjectConfigSchema = z +export const ArchitectProjectConfigSchema = z .object({ // Taxonomy preset: PresetNameSchema.optional(), @@ -235,10 +235,10 @@ export const DeliveryProcessProjectConfigSchema = z * Type guard for raw project config objects. * * Used by `loadProjectConfig()` to distinguish between: - * - New-style `DeliveryProcessProjectConfig` (has `sources`, `preset`, `output`, etc.) - * - Legacy `DeliveryProcessInstance` (has `registry` + `regexBuilders`) + * - New-style `ArchitectProjectConfig` (has `sources`, `preset`, `output`, etc.) + * - Legacy `ArchitectInstance` (has `registry` + `regexBuilders`) */ -export function isProjectConfig(value: unknown): value is DeliveryProcessProjectConfig { +export function isProjectConfig(value: unknown): value is ArchitectProjectConfig { if (value === null || typeof value !== 'object') { return false; } @@ -254,9 +254,9 @@ export function isProjectConfig(value: unknown): value is DeliveryProcessProject } /** - * Type guard for legacy DeliveryProcessInstance objects. + * Type guard for legacy ArchitectInstance objects. */ -export function isLegacyInstance(value: unknown): value is DeliveryProcessInstance { +export function isLegacyInstance(value: unknown): value is ArchitectInstance { if (value === null || typeof value !== 'object') { return false; } @@ -269,32 +269,32 @@ export function isLegacyInstance(value: unknown): value is DeliveryProcessInstan // If this line errors, the schema and interface have drifted out of sync. // --------------------------------------------------------------------------- -type _ZodOutput = z.output; +type _ZodOutput = z.output; // Bidirectional key-set check: both types must have the same top-level keys. // This catches added/removed fields without fighting readonly/refine variance. -type _AssertSameKeys = keyof _ZodOutput extends keyof DeliveryProcessProjectConfig - ? keyof DeliveryProcessProjectConfig extends keyof _ZodOutput +type _AssertSameKeys = keyof _ZodOutput extends keyof ArchitectProjectConfig + ? keyof ArchitectProjectConfig extends keyof _ZodOutput ? true : { error: 'Interface has keys not in Zod schema'; - extra: Exclude; + extra: Exclude; } : { error: 'Zod schema has keys not in interface'; - extra: Exclude; + extra: Exclude; }; const _schemaKeyCheck: _AssertSameKeys = true; // Field-level assignability for simple scalar fields (preset, tagPrefix, etc.). // Complex fields (sources, output, generatorOverrides) have known readonly/refine -// variance between Zod output and the interface — the `as DeliveryProcessProjectConfig` +// variance between Zod output and the interface — the `as ArchitectProjectConfig` // cast in loadProjectConfig() bridges this gap safely since Zod validates at runtime. -type _AssertScalarFields = _ZodOutput['preset'] extends DeliveryProcessProjectConfig['preset'] - ? _ZodOutput['tagPrefix'] extends DeliveryProcessProjectConfig['tagPrefix'] - ? _ZodOutput['fileOptInTag'] extends DeliveryProcessProjectConfig['fileOptInTag'] - ? _ZodOutput['workflowPath'] extends DeliveryProcessProjectConfig['workflowPath'] +type _AssertScalarFields = _ZodOutput['preset'] extends ArchitectProjectConfig['preset'] + ? _ZodOutput['tagPrefix'] extends ArchitectProjectConfig['tagPrefix'] + ? _ZodOutput['fileOptInTag'] extends ArchitectProjectConfig['fileOptInTag'] + ? _ZodOutput['workflowPath'] extends ArchitectProjectConfig['workflowPath'] ? true : { error: 'workflowPath drift' } : { error: 'fileOptInTag drift' } diff --git a/src/config/project-config.ts b/src/config/project-config.ts index b1c60714..c6edf388 100644 --- a/src/config/project-config.ts +++ b/src/config/project-config.ts @@ -1,24 +1,24 @@ /** - * @libar-docs - * @libar-docs-core @libar-docs-config - * @libar-docs-pattern ProjectConfigTypes - * @libar-docs-status active - * @libar-docs-arch-layer domain - * @libar-docs-arch-context config - * @libar-docs-uses ConfigurationTypes, ConfigurationPresets - * @libar-docs-used-by DefineConfig, ConfigLoader - * @libar-docs-extract-shapes DeliveryProcessProjectConfig, SourcesConfig, OutputConfig, GeneratorSourceOverride, ResolvedConfig, ResolvedProjectConfig, ResolvedSourcesConfig + * @architect + * @architect-core @architect-config + * @architect-pattern ProjectConfigTypes + * @architect-status active + * @architect-arch-layer domain + * @architect-arch-context config + * @architect-uses ConfigurationTypes, ConfigurationPresets + * @architect-used-by DefineConfig, ConfigLoader + * @architect-extract-shapes ArchitectProjectConfig, SourcesConfig, OutputConfig, GeneratorSourceOverride, ResolvedConfig, ResolvedProjectConfig, ResolvedSourcesConfig * * ## Project Configuration Types * - * Unified project configuration for the delivery-process package. + * Unified project configuration for the Architect package. * Replaces the fragmented system where taxonomy, source discovery, * and output config lived in three disconnected layers. * * ### Architecture * * ``` - * defineConfig() → raw DeliveryProcessProjectConfig + * defineConfig() → raw ArchitectProjectConfig * ↓ * loadProjectConfig() → validates (Zod) → resolveProjectConfig() * ↓ @@ -29,13 +29,13 @@ * * ### When to Use * - * - Define project config in `delivery-process.config.ts` + * - Define project config in `architect.config.ts` * - Internal resolution via `resolveProjectConfig()` * - CLI override merging */ import type { PresetName } from './presets.js'; -import type { DeliveryProcessConfig, DeliveryProcessInstance } from './types.js'; +import type { ArchitectConfig, ArchitectInstance } from './types.js'; import type { ContextInferenceRule } from '../generators/pipeline/context-inference.js'; // ═══ Cross-Layer Imports: config → renderable ═══════════════════════════════ // Project configuration declares which reference documents to generate, @@ -64,7 +64,7 @@ export interface SourcesConfig { /** * Glob patterns for design stub files. - * Stubs are TypeScript files that live outside `src/` (e.g., `delivery-process/stubs/`). + * Stubs are TypeScript files that live outside `src/` (e.g., `architect/stubs/`). * Merged into TypeScript sources at resolution time. */ readonly stubs?: readonly string[]; @@ -135,27 +135,27 @@ export interface GeneratorSourceOverride { } /** - * Unified project configuration for delivery-process. + * Unified project configuration for Architect. * - * This is the shape users provide in `delivery-process.config.ts`. + * This is the shape users provide in `architect.config.ts`. * `defineConfig()` is an identity function providing type safety. * * @example * ```typescript - * import { defineConfig } from '@libar-dev/delivery-process/config'; + * import { defineConfig } from '@libar-dev/architect/config'; * * export default defineConfig({ * preset: 'ddd-es-cqrs', * sources: { * typescript: ['packages/* /src/** /*.ts'], - * features: ['delivery-process/specs/** /*.feature'], - * stubs: ['delivery-process/stubs/** /*.ts'], + * features: ['architect/specs/** /*.feature'], + * stubs: ['architect/stubs/** /*.ts'], * }, * output: { directory: 'docs-living', overwrite: true }, * }); * ``` */ -export interface DeliveryProcessProjectConfig { +export interface ArchitectProjectConfig { // --- Taxonomy --- /** Use a preset taxonomy configuration */ @@ -168,7 +168,7 @@ export interface DeliveryProcessProjectConfig { readonly fileOptInTag?: string; /** Custom categories (replaces preset categories entirely) */ - readonly categories?: DeliveryProcessConfig['categories']; + readonly categories?: ArchitectConfig['categories']; // --- Sources --- @@ -254,7 +254,7 @@ export interface ResolvedProjectConfig { export type ResolvedConfig = | { /** The taxonomy instance (registry + regexBuilders) */ - readonly instance: DeliveryProcessInstance; + readonly instance: ArchitectInstance; /** The resolved project config with defaults applied */ readonly project: ResolvedProjectConfig; /** Config was generated from defaults (no config file found) */ @@ -264,7 +264,7 @@ export type ResolvedConfig = } | { /** The taxonomy instance (registry + regexBuilders) */ - readonly instance: DeliveryProcessInstance; + readonly instance: ArchitectInstance; /** The resolved project config with defaults applied */ readonly project: ResolvedProjectConfig; /** Config was loaded from a file */ diff --git a/src/config/regex-builders.ts b/src/config/regex-builders.ts index 6839897c..d6202015 100644 --- a/src/config/regex-builders.ts +++ b/src/config/regex-builders.ts @@ -1,14 +1,14 @@ /** - * @libar-docs - * @libar-docs-core @libar-docs-config - * @libar-docs-pattern RegexBuilders - * @libar-docs-status completed - * @libar-docs-arch-layer infrastructure - * @libar-docs-arch-context config - * @libar-docs-arch-role infrastructure - * @libar-docs-uses ConfigurationTypes - * @libar-docs-used-by DeliveryProcessFactory - * @libar-docs-extract-shapes createRegexBuilders + * @architect + * @architect-core @architect-config + * @architect-pattern RegexBuilders + * @architect-status completed + * @architect-arch-layer infrastructure + * @architect-arch-context config + * @architect-arch-role infrastructure + * @architect-uses ConfigurationTypes + * @architect-used-by ArchitectFactory + * @architect-extract-shapes createRegexBuilders * * ## Regex Builders * @@ -41,8 +41,8 @@ function escapeRegex(str: string): string { * Creates type-safe regex builders for a given tag prefix configuration. * These are used throughout the scanner and validation pipeline. * - * @param tagPrefix - The tag prefix (e.g., "@docs-" or "@libar-docs-") - * @param fileOptInTag - The file opt-in tag (e.g., "@docs" or "@libar-docs") + * @param tagPrefix - The tag prefix (e.g., "@docs-" or "@architect-") + * @param fileOptInTag - The file opt-in tag (e.g., "@docs" or "@architect") * @returns RegexBuilders instance with pattern matching methods * * @example diff --git a/src/config/resolve-config.ts b/src/config/resolve-config.ts index d4d46ca4..82b83219 100644 --- a/src/config/resolve-config.ts +++ b/src/config/resolve-config.ts @@ -1,24 +1,24 @@ /** - * @libar-docs - * @libar-docs-core @libar-docs-config - * @libar-docs-pattern ConfigResolver - * @libar-docs-status active - * @libar-docs-arch-layer application - * @libar-docs-arch-context config - * @libar-docs-arch-role service - * @libar-docs-uses ProjectConfigTypes, DeliveryProcessFactory, ConfigurationDefaults - * @libar-docs-used-by ConfigLoader + * @architect + * @architect-core @architect-config + * @architect-pattern ConfigResolver + * @architect-status active + * @architect-arch-layer application + * @architect-arch-context config + * @architect-arch-role service + * @architect-uses ProjectConfigTypes, ArchitectFactory, ConfigurationDefaults + * @architect-used-by ConfigLoader * * ## Config Resolution * - * Resolves a raw `DeliveryProcessProjectConfig` into a fully-resolved `ResolvedConfig` + * Resolves a raw `ArchitectProjectConfig` into a fully-resolved `ResolvedConfig` * with all defaults applied, stubs merged into TypeScript sources, and context inference * rules prepended to defaults. * * ### Architecture * * ``` - * DeliveryProcessProjectConfig (user-authored) + * ArchitectProjectConfig (user-authored) * | * v * resolveProjectConfig() -- creates instance, merges sources, applies defaults @@ -36,16 +36,16 @@ import type { ContextInferenceRule } from '../generators/pipeline/context-inference.js'; import type { - DeliveryProcessProjectConfig, + ArchitectProjectConfig, GeneratorSourceOverride, ResolvedConfig, ResolvedProjectConfig, ResolvedSourcesConfig, } from './project-config.js'; -import type { DeliveryProcessInstance } from './types.js'; +import type { ArchitectInstance } from './types.js'; import { DEFAULT_CONTEXT_INFERENCE_RULES } from './defaults.js'; -import { createDeliveryProcess, type CreateDeliveryProcessOptions } from './factory.js'; +import { createArchitect, type CreateArchitectOptions } from './factory.js'; /** * Resolves a raw project config into a fully-resolved config with all defaults applied. @@ -63,11 +63,11 @@ import { createDeliveryProcess, type CreateDeliveryProcessOptions } from './fact * @returns Fully resolved configuration ready for use by orchestrator and CLIs */ export function resolveProjectConfig( - raw: DeliveryProcessProjectConfig, + raw: ArchitectProjectConfig, options: { readonly configPath: string } ): ResolvedConfig { // 1. Create taxonomy instance from preset/override fields - const instanceOptions: CreateDeliveryProcessOptions = {}; + const instanceOptions: CreateArchitectOptions = {}; if (raw.preset !== undefined) { instanceOptions.preset = raw.preset; } @@ -80,7 +80,7 @@ export function resolveProjectConfig( if (raw.categories !== undefined) { instanceOptions.categories = raw.categories; } - const instance: DeliveryProcessInstance = createDeliveryProcess(instanceOptions); + const instance: ArchitectInstance = createArchitect(instanceOptions); // 2. Resolve sources — merge stubs into typescript const typescript: readonly string[] = [ @@ -148,7 +148,7 @@ export function resolveProjectConfig( * @returns A default ResolvedConfig with empty sources and standard defaults */ export function createDefaultResolvedConfig(): ResolvedConfig { - const instance: DeliveryProcessInstance = createDeliveryProcess(); + const instance: ArchitectInstance = createArchitect(); const sources: ResolvedSourcesConfig = { typescript: [], diff --git a/src/config/tag-taxonomy-generator.ts b/src/config/tag-taxonomy-generator.ts index cf194a67..1c189391 100644 --- a/src/config/tag-taxonomy-generator.ts +++ b/src/config/tag-taxonomy-generator.ts @@ -106,7 +106,7 @@ export function generateTagTaxonomy(registry: TagRegistry, config?: TagTaxonomyC // Format Options sections.push('## Format Options'); sections.push(''); - sections.push('Used in template placeholders: `{{@libar-docs-core format=X}}`'); + sections.push('Used in template placeholders: `{{@architect-core format=X}}`'); sections.push(''); for (const fmt of registry.formatOptions) { sections.push(`- \`${fmt}\``); diff --git a/src/config/types.ts b/src/config/types.ts index 1aa96dba..b76bbefb 100644 --- a/src/config/types.ts +++ b/src/config/types.ts @@ -1,15 +1,15 @@ /** - * @libar-docs - * @libar-docs-core @libar-docs-config - * @libar-docs-pattern ConfigurationTypes - * @libar-docs-status completed - * @libar-docs-arch-layer domain - * @libar-docs-arch-context config - * @libar-docs-extract-shapes DeliveryProcessConfig, DeliveryProcessInstance, RegexBuilders + * @architect + * @architect-core @architect-config + * @architect-pattern ConfigurationTypes + * @architect-status completed + * @architect-arch-layer domain + * @architect-arch-context config + * @architect-extract-shapes ArchitectConfig, ArchitectInstance, RegexBuilders * * ## Configuration Types * - * Type definitions for the delivery process configuration system. + * Type definitions for the Architect configuration system. * Provides fully type-safe configuration with generics to preserve literal types from presets. * * ### When to Use @@ -28,10 +28,10 @@ import type { ContextInferenceRule } from '../generators/pipeline/context-infere * Configuration for creating a delivery process instance. * Uses generics to preserve literal types from presets. */ -export interface DeliveryProcessConfig { - /** Tag prefix for directives (e.g., "@docs-" or "@libar-docs-") */ +export interface ArchitectConfig { + /** Tag prefix for directives (e.g., "@docs-" or "@architect-") */ readonly tagPrefix: string; - /** File-level opt-in tag (e.g., "@docs" or "@libar-docs") */ + /** File-level opt-in tag (e.g., "@docs" or "@architect") */ readonly fileOptInTag: string; /** Category definitions for pattern classification */ readonly categories: readonly CategoryDefinition[]; @@ -55,9 +55,9 @@ export interface DeliveryProcessConfig { } /** - * Instance returned by createDeliveryProcess with configured registry + * Instance returned by createArchitect with configured registry */ -export interface DeliveryProcessInstance { +export interface ArchitectInstance { /** The fully configured tag registry */ readonly registry: TagRegistry; /** Regex builders for tag detection */ diff --git a/src/config/workflow-loader.ts b/src/config/workflow-loader.ts index 4a03064f..9440821a 100644 --- a/src/config/workflow-loader.ts +++ b/src/config/workflow-loader.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-config - * @libar-docs-pattern WorkflowLoader - * @libar-docs-status completed - * @libar-docs-arch-layer infrastructure - * @libar-docs-arch-context config - * @libar-docs-arch-role infrastructure - * @libar-docs-uses WorkflowConfigSchema, CodecUtils - * @libar-docs-used-by GeneratorOrchestrator, SectionHelpers + * @architect + * @architect-config + * @architect-pattern WorkflowLoader + * @architect-status completed + * @architect-arch-layer infrastructure + * @architect-arch-context config + * @architect-arch-role infrastructure + * @architect-uses WorkflowConfigSchema, CodecUtils + * @architect-used-by GeneratorOrchestrator, SectionHelpers * * ## WorkflowLoader - Workflow Configuration Loading * diff --git a/src/extractor/doc-extractor.ts b/src/extractor/doc-extractor.ts index de710cc1..7860ee76 100644 --- a/src/extractor/doc-extractor.ts +++ b/src/extractor/doc-extractor.ts @@ -1,16 +1,16 @@ /** - * @libar-docs - * @libar-docs-core @libar-docs-extractor - * @libar-docs-pattern Document Extractor - * @libar-docs-status completed - * @libar-docs-arch-role service - * @libar-docs-arch-context extractor - * @libar-docs-arch-layer application - * @libar-docs-include pipeline-stages - * @libar-docs-uses Pattern Scanner, Tag Registry, Zod - * @libar-docs-used-by Orchestrator, Generators - * @libar-docs-usecase "When converting scanned files to ExtractedPattern objects" - * @libar-docs-usecase "When inferring pattern names and categories from exports" + * @architect + * @architect-core @architect-extractor + * @architect-pattern Document Extractor + * @architect-status completed + * @architect-arch-role service + * @architect-arch-context extractor + * @architect-arch-layer application + * @architect-include pipeline-stages + * @architect-uses Pattern Scanner, Tag Registry, Zod + * @architect-used-by Orchestrator, Generators + * @architect-usecase "When converting scanned files to ExtractedPattern objects" + * @architect-usecase "When inferring pattern names and categories from exports" * * ## Document Extractor - Pattern Extraction and Metadata Generation * @@ -164,8 +164,8 @@ export function buildPattern( const name = inferPatternName(directive, exports, registry); const category = asCategoryName(inferCategory(directive.tags as readonly string[], registry)); - // Shape extraction: both @libar-docs-extract-shapes (pattern-level) and - // @libar-docs-shape (declaration-level) contribute to extractedShapes. + // Shape extraction: both @architect-extract-shapes (pattern-level) and + // @architect-shape (declaration-level) contribute to extractedShapes. // Read file once for both paths. let extractedShapes; const extractionWarnings: string[] = []; @@ -182,7 +182,7 @@ export function buildPattern( ); } - // Path 1: Existing @libar-docs-extract-shapes tag processing + // Path 1: Existing @architect-extract-shapes tag processing if ( sourceContent !== undefined && directive.extractShapes !== undefined && @@ -197,11 +197,11 @@ export function buildPattern( extractionWarnings.push(...shapeResult.warnings); } - // Path 2: Declaration-level @libar-docs-shape discovery + // Path 2: Declaration-level @architect-shape discovery // Performance note: when both paths fire, sourceCode is parsed by typescript-estree // twice (once in processExtractShapesTag, once in discoverTaggedShapes). Acceptable // for v1 — future optimization could accept a pre-parsed AST. - if (sourceContent?.includes('libar-docs-shape') === true) { + if (sourceContent?.includes('architect-shape') === true) { const taggedResult = discoverTaggedShapes(sourceContent, { jsx }); if (taggedResult.ok && taggedResult.value.shapes.length > 0) { const existingByName = new Map((extractedShapes ?? []).map((s) => [s.name, s])); @@ -293,7 +293,7 @@ export function buildPattern( directive.include.length > 0 && { include: directive.include }), // PRD metadata fields ...(directive.productArea !== undefined && { productArea: directive.productArea }), - // Shape extraction fields (extracted from source file when @libar-docs-extract-shapes present) + // Shape extraction fields (extracted from source file when @architect-extract-shapes present) ...(extractedShapes && extractedShapes.length > 0 && { extractedShapes }), // Convention tags for reference document generation ...(directive.convention !== undefined && @@ -403,25 +403,25 @@ export function inferPatternName( } /** - * Infer category from @libar-docs-* tags using priority system + * Infer category from @architect-* tags using priority system * * Categories are selected based on priority order: * domain > arch > infra > validation > testing > performance > security > core * - * @param tags - Array of @libar-docs-* tags + * @param tags - Array of @architect-* tags * @returns Inferred category string * * @example * ```typescript * // Priority-based selection * const cat1 = inferCategory([ - * '@libar-docs-core', - * '@libar-docs-domain-auth' + * '@architect-core', + * '@architect-domain-auth' * ]); * console.log(cat1); // 'domain' (higher priority than 'core') * * // From first tag - * const cat2 = inferCategory(['@libar-docs-validation-zod']); + * const cat2 = inferCategory(['@architect-validation-zod']); * console.log(cat2); // 'validation' * * // No tags @@ -457,7 +457,7 @@ export function inferCategory(tags: readonly string[], registry: TagRegistry): s const withoutPrefix = tag.substring(prefix.length); // Find ALL matching categories in this tag - // This handles cases like "@libar-docs-utils-validation" which contains both "utils" and "validation" + // This handles cases like "@architect-utils-validation" which contains both "utils" and "validation" const matches: string[] = []; // Check for exact match first @@ -529,9 +529,9 @@ export function inferCategory(tags: readonly string[], registry: TagRegistry): s * * @example * ```typescript - * hasAggregationTag(['@libar-docs-core', '@libar-docs-overview'], "overview", registry); // true - * hasAggregationTag(['@libar-docs-core'], "overview", registry); // false - * hasAggregationTag(['@libar-docs-arch', '@libar-docs-decision'], "decision", registry); // true + * hasAggregationTag(['@architect-core', '@architect-overview'], "overview", registry); // true + * hasAggregationTag(['@architect-core'], "overview", registry); // false + * hasAggregationTag(['@architect-arch', '@architect-decision'], "decision", registry); // true * ``` */ export function hasAggregationTag( @@ -563,18 +563,18 @@ export interface AggregationTags { * Identifies which aggregated documents a pattern should appear in. * Patterns can appear in multiple documents if they have multiple aggregation tags. * - * @param tags - Array of @libar-docs-* tags + * @param tags - Array of @architect-* tags * @param registry - Tag registry for aggregation tag lookup * @returns Object indicating which aggregated docs to include pattern in * * @example * ```typescript * // Pattern with both overview and decision tags - * getAggregationTags(['@libar-docs-overview', '@libar-docs-decision'], registry); + * getAggregationTags(['@architect-overview', '@architect-decision'], registry); * // { overview: true, decision: true, intro: false } * * // Pattern with only core tag (no aggregation) - * getAggregationTags(['@libar-docs-core'], registry); + * getAggregationTags(['@architect-core'], registry); * // { overview: false, decision: false, intro: false } * ``` */ diff --git a/src/extractor/dual-source-extractor.ts b/src/extractor/dual-source-extractor.ts index e2e05341..4c781b2c 100644 --- a/src/extractor/dual-source-extractor.ts +++ b/src/extractor/dual-source-extractor.ts @@ -1,18 +1,18 @@ /** - * @libar-docs - * @libar-docs-extractor - * @libar-docs-pattern DualSourceExtractor - * @libar-docs-status completed - * @libar-docs-uses DocExtractor, GherkinExtractor, GherkinScanner - * @libar-docs-used-by Orchestrator - * @libar-docs-arch-role service - * @libar-docs-arch-context extractor - * @libar-docs-arch-layer application + * @architect + * @architect-extractor + * @architect-pattern DualSourceExtractor + * @architect-status completed + * @architect-uses DocExtractor, GherkinExtractor, GherkinScanner + * @architect-used-by Orchestrator + * @architect-arch-role service + * @architect-arch-context extractor + * @architect-arch-layer application * * ## DualSourceExtractor - Compose Pattern Data from Code + Features * - * Extracts pattern metadata from both TypeScript code stubs (@libar-docs-*) - * and Gherkin feature files (@libar-docs-*), validates consistency, + * Extracts pattern metadata from both TypeScript code stubs (@architect-*) + * and Gherkin feature files (@architect-*), validates consistency, * and composes unified pattern data for documentation generation. * * ### When to Use @@ -24,8 +24,8 @@ * * ### Key Concepts * - * - **Code Source**: @libar-docs-* tags define timeless pattern graph - * - **Feature Source**: @libar-docs-* tags add temporal process metadata + * - **Code Source**: @architect-* tags define timeless pattern graph + * - **Feature Source**: @architect-* tags add temporal process metadata * - **Cross-Validation**: Pattern name + phase must match across sources * - **Deliverables**: Parsed from Gherkin Background tables in features */ @@ -81,7 +81,7 @@ export interface DualSourcePattern extends ExtractedPattern { readonly deliverables?: readonly Deliverable[]; /** * Multiple source patterns when there's a name collision (optional) - * Present when multiple code files use the same @libar-docs-pattern name + * Present when multiple code files use the same @architect-pattern name */ readonly sources?: readonly ExtractedPattern[]; } @@ -98,7 +98,7 @@ export interface DualSourcePattern extends ExtractedPattern { export function extractProcessMetadata(feature: ScannedGherkinFile): ProcessMetadata | null { const tags = feature.feature.tags; - // Extract normalized tags (scanner strips @ and configured prefix like @libar-docs-) + // Extract normalized tags (scanner strips @ and configured prefix like @architect-) const patternTag = tags.find((t) => t.startsWith('pattern:')); const phaseTag = tags.find((t) => t.startsWith('phase:')); const statusTag = tags.find((t) => t.startsWith('status:')); @@ -318,7 +318,7 @@ export function extractDeliverables(feature: ScannedGherkinFile): readonly Deliv * Creates unified pattern objects with both code and process metadata. * * **Pattern Name Collisions:** - * When multiple code files use the same `@libar-docs-pattern` name (e.g., + * When multiple code files use the same `@architect-pattern` name (e.g., * ServiceIndependence with ECST and Reservation sub-patterns), they are * automatically merged: * - Categories, dependencies, and enables are unioned across all sources diff --git a/src/extractor/gherkin-extractor.ts b/src/extractor/gherkin-extractor.ts index 70a37a15..ef7f9030 100644 --- a/src/extractor/gherkin-extractor.ts +++ b/src/extractor/gherkin-extractor.ts @@ -1,14 +1,14 @@ /** - * @libar-docs - * @libar-docs-extractor - * @libar-docs-pattern GherkinExtractor - * @libar-docs-status completed - * @libar-docs-implements GherkinRulesSupport - * @libar-docs-uses GherkinTypes, GherkinASTParser - * @libar-docs-used-by DualSourceExtractor, Orchestrator - * @libar-docs-arch-role service - * @libar-docs-arch-context extractor - * @libar-docs-arch-layer application + * @architect + * @architect-extractor + * @architect-pattern GherkinExtractor + * @architect-status completed + * @architect-implements GherkinRulesSupport + * @architect-uses GherkinTypes, GherkinASTParser + * @architect-used-by DualSourceExtractor, Orchestrator + * @architect-arch-role service + * @architect-arch-context extractor + * @architect-arch-layer application * * ## GherkinExtractor - Convert Feature Files to Pattern Documentation * @@ -174,9 +174,9 @@ export function extractPatternsFromGherkin( // Extract pattern metadata from feature tags const metadata = extractPatternTags(feature.tags); - // Skip if no @libar-docs opt-in marker (consistent with TypeScript requirement) - // The marker normalizes to 'libar-docs' after stripping the @ prefix - const hasOptIn = feature.tags.some((tag) => tag === 'libar-docs' || tag === '@libar-docs'); + // Skip if no @architect opt-in marker (consistent with TypeScript requirement) + // The marker normalizes to 'architect' after stripping the @ prefix + const hasOptIn = feature.tags.some((tag) => tag === 'libar-docs' || tag === 'architect'); if (!hasOptIn) { continue; } @@ -239,9 +239,9 @@ export function extractPatternsFromGherkin( // This avoids ~50 intermediate objects created by conditional spreads const directive: Record = { // Preserve ALL tags (including value tags like claude-md-section:validation) - // Tags are stored as @libar-docs-{tag} to match TypeScript directive format + // Tags are stored as @architect-{tag} to match TypeScript directive format tags: feature.tags.map((tag) => - asDirectiveTag(`@libar-docs-${tag}`) + asDirectiveTag(`@architect-${tag}`) ) as readonly DirectiveTag[], description: feature.description, examples: [], @@ -319,7 +319,7 @@ export function extractPatternsFromGherkin( assignIfNonEmpty(rawPattern, 'discoveredRisks', metadata.discoveredRisks); assignIfNonEmpty(rawPattern, 'discoveredLearnings', metadata.discoveredLearnings); - // Technical constraints from @libar-docs-constraint tags + // Technical constraints from @architect-constraint tags assignIfNonEmpty(rawPattern, 'constraints', metadata.constraints); // ADR (Architecture Decision Record) fields @@ -526,8 +526,9 @@ export async function extractPatternsFromGherkinAsync( const relativePath = path.relative(baseDir, filePath); const metadata = extractPatternTags(feature.tags); - // Skip if no @libar-docs opt-in marker (consistent with TypeScript requirement) - const hasOptIn = feature.tags.some((tag) => tag === 'libar-docs' || tag === '@libar-docs'); + // Skip if no @architect opt-in marker (consistent with TypeScript requirement) + // The marker normalizes to 'architect' after stripping the @ prefix + const hasOptIn = feature.tags.some((tag) => tag === 'libar-docs' || tag === 'architect'); if (!hasOptIn) continue; // Skip if no pattern or status tag @@ -567,7 +568,7 @@ export async function extractPatternsFromGherkinAsync( const directive: Record = { // Preserve ALL tags (including value tags like claude-md-section:validation) tags: feature.tags.map((tag) => - asDirectiveTag(`@libar-docs-${tag}`) + asDirectiveTag(`@architect-${tag}`) ) as readonly DirectiveTag[], description: feature.description, examples: [], diff --git a/src/extractor/layer-inference.ts b/src/extractor/layer-inference.ts index c139b830..073fb39e 100644 --- a/src/extractor/layer-inference.ts +++ b/src/extractor/layer-inference.ts @@ -1,9 +1,9 @@ /** - * @libar-docs - * @libar-docs-extractor - * @libar-docs-pattern LayerInference - * @libar-docs-status completed - * @libar-docs-used-by GherkinExtractor + * @architect + * @architect-extractor + * @architect-pattern LayerInference + * @architect-status completed + * @architect-used-by GherkinExtractor * * ## LayerInference - Directory-Based Feature Classification * diff --git a/src/extractor/shape-extractor.ts b/src/extractor/shape-extractor.ts index 789365d6..3ea17e4b 100644 --- a/src/extractor/shape-extractor.ts +++ b/src/extractor/shape-extractor.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-pattern ShapeExtractor - * @libar-docs-status completed - * @libar-docs-phase 26 - * @libar-docs-implements ShapeExtraction - * @libar-docs-uses typescript-estree + * @architect + * @architect-pattern ShapeExtractor + * @architect-status completed + * @architect-phase 26 + * @architect-implements ShapeExtraction + * @architect-uses typescript-estree * * ## Shape Extractor - TypeScript Type Extraction * @@ -13,7 +13,7 @@ * * ### When to Use * - * - When processing @libar-docs-extract-shapes tags during extraction + * - When processing @architect-extract-shapes tags during extraction * - When generating documentation that needs actual type definitions * - When eliminating duplication between JSDoc examples and code * @@ -434,7 +434,7 @@ function extractShape( } } - // Get JSDoc if requested, stripping @libar-docs-* annotation lines + // Get JSDoc if requested, stripping @architect-* annotation lines let jsDoc: string | undefined; if (options.includeJsDoc) { const rawJsDoc = extractPrecedingJsDoc(sourceCode, node, comments); @@ -523,7 +523,7 @@ function extractShape( } /** - * Strip @libar-docs-* annotation lines from a JSDoc comment. + * Strip @architect-* annotation lines from a JSDoc comment. * * Preserves standard JSDoc tags (@param, @returns, @example, etc.) and * all non-annotation content. Returns undefined if all content lines were @@ -540,7 +540,7 @@ function extractJsDocLineContent(line: string): string { function stripLibarDocsTags(jsDoc: string): string | undefined { const lines = jsDoc.split('\n'); - const filtered = lines.filter((line) => !extractJsDocLineContent(line).startsWith('@libar-docs')); + const filtered = lines.filter((line) => !extractJsDocLineContent(line).startsWith('@architect')); // Check if anything meaningful remains (not just /** and */) const hasContent = filtered.some((line) => extractJsDocLineContent(line).length > 0); @@ -940,7 +940,7 @@ export interface ProcessExtractShapesResult { /** * DD-4: Extract all exported declarations from a file as shapes. * - * Auto-discovery mode: when `@libar-docs-extract-shapes *` is used, + * Auto-discovery mode: when `@architect-extract-shapes *` is used, * all exported types/interfaces/enums/functions/consts are extracted * without requiring explicit names. * @@ -996,7 +996,7 @@ function extractAllExportedShapes(sourceCode: string, jsx = false): Result 1) { issues.push( - `Duplicate @libar-docs-sequence-step:${String(stepNumber)} used by rules: ${ruleNames.join(', ')}` + `Duplicate @architect-sequence-step:${String(stepNumber)} used by rules: ${ruleNames.join(', ')}` ); } } diff --git a/src/generators/pipeline/transform-dataset.ts b/src/generators/pipeline/transform-dataset.ts index e116dcf2..cdbd4c5b 100644 --- a/src/generators/pipeline/transform-dataset.ts +++ b/src/generators/pipeline/transform-dataset.ts @@ -1,18 +1,18 @@ /** - * @libar-docs - * @libar-docs-generator @libar-docs-core - * @libar-docs-pattern TransformDataset - * @libar-docs-status completed - * @libar-docs-implements PatternRelationshipModel - * @libar-docs-arch-role service - * @libar-docs-arch-context generator - * @libar-docs-arch-layer application - * @libar-docs-include pipeline-stages - * @libar-docs-uses MasterDataset, ExtractedPattern, TagRegistry, NormalizeStatus - * @libar-docs-used-by Orchestrator - * @libar-docs-usecase "When computing all pattern views in a single pass" - * @libar-docs-usecase "When transforming raw extracted data for generators" - * @libar-docs-extract-shapes RuntimeMasterDataset, RawDataset, transformToMasterDataset + * @architect + * @architect-generator @architect-core + * @architect-pattern TransformDataset + * @architect-status completed + * @architect-implements PatternRelationshipModel + * @architect-arch-role service + * @architect-arch-context generator + * @architect-arch-layer application + * @architect-include pipeline-stages + * @architect-uses MasterDataset, ExtractedPattern, TagRegistry, NormalizeStatus + * @architect-used-by Orchestrator + * @architect-usecase "When computing all pattern views in a single pass" + * @architect-usecase "When transforming raw extracted data for generators" + * @architect-extract-shapes RuntimeMasterDataset, RawDataset, transformToMasterDataset * * ## TransformDataset - Single-Pass Pattern Transformation * @@ -289,7 +289,7 @@ export function transformToMasterDatasetWithValidation(raw: RawDataset): Transfo malformedPatterns.push({ patternId: patternKey, issues: [ - 'Has @libar-docs-sequence-orchestrator but no rules with @libar-docs-sequence-step tags', + 'Has @architect-sequence-orchestrator but no rules with @architect-sequence-step tags', ], }); } @@ -297,7 +297,7 @@ export function transformToMasterDatasetWithValidation(raw: RawDataset): Transfo malformedPatterns.push({ patternId: patternKey, issues: [ - 'Has @libar-docs-sequence-orchestrator but no Rule: blocks to extract sequence steps from', + 'Has @architect-sequence-orchestrator but no Rule: blocks to extract sequence steps from', ], }); } diff --git a/src/generators/pipeline/transform-types.ts b/src/generators/pipeline/transform-types.ts index 9faad129..d360b389 100644 --- a/src/generators/pipeline/transform-types.ts +++ b/src/generators/pipeline/transform-types.ts @@ -1,12 +1,12 @@ /** - * @libar-docs - * @libar-docs-pattern TransformTypes - * @libar-docs-status active - * @libar-docs-arch-role types - * @libar-docs-arch-context generator - * @libar-docs-arch-layer application - * @libar-docs-used-by TransformDataset, Orchestrator - * @libar-docs-uses MasterDataset, LoadedWorkflow, ExtractedPattern, TagRegistry, ContextInferenceRule + * @architect + * @architect-pattern TransformTypes + * @architect-status active + * @architect-arch-role types + * @architect-arch-context generator + * @architect-arch-layer application + * @architect-used-by TransformDataset, Orchestrator + * @architect-uses MasterDataset, LoadedWorkflow, ExtractedPattern, TagRegistry, ContextInferenceRule * * ## TransformTypes - MasterDataset Transformation Types * @@ -83,7 +83,7 @@ export interface TransformResult { * LoadedWorkflow contains Maps which aren't JSON-serializable, * so it's kept separate from the Zod schema. * - * @libar-docs-shape master-dataset + * @architect-shape master-dataset */ export interface RuntimeMasterDataset extends MasterDataset { /** Optional workflow configuration (not serializable) */ @@ -93,7 +93,7 @@ export interface RuntimeMasterDataset extends MasterDataset { /** * Raw input data for transformation * - * @libar-docs-shape master-dataset + * @architect-shape master-dataset */ export interface RawDataset { /** Extracted patterns from TypeScript and/or Gherkin sources */ diff --git a/src/generators/registry.ts b/src/generators/registry.ts index 57fa5e76..13cd632d 100644 --- a/src/generators/registry.ts +++ b/src/generators/registry.ts @@ -1,15 +1,15 @@ /** - * @libar-docs + * @architect */ import type { DocumentGenerator } from './types'; /** - * @libar-docs-generator - * @libar-docs-pattern GeneratorRegistry - * @libar-docs-status completed - * @libar-docs-uses GeneratorTypes - * @libar-docs-used-by GeneratorFactory, Orchestrator, GenerateDocsCLI + * @architect-generator + * @architect-pattern GeneratorRegistry + * @architect-status completed + * @architect-uses GeneratorTypes + * @architect-used-by GeneratorFactory, Orchestrator, GenerateDocsCLI * * ## GeneratorRegistry - Central Registry for Document Generators * diff --git a/src/generators/source-mapper.ts b/src/generators/source-mapper.ts index 2b5fb1d5..ff8cefc5 100644 --- a/src/generators/source-mapper.ts +++ b/src/generators/source-mapper.ts @@ -1,12 +1,12 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern SourceMapper - * @libar-docs-status completed - * @libar-docs-arch-role infrastructure - * @libar-docs-arch-context generator - * @libar-docs-arch-layer infrastructure - * @libar-docs-depends-on DecisionDocCodec,ShapeExtractor,GherkinASTParser + * @architect + * @architect-core + * @architect-pattern SourceMapper + * @architect-status completed + * @architect-arch-role infrastructure + * @architect-arch-context generator + * @architect-arch-layer infrastructure + * @architect-depends-on DecisionDocCodec,ShapeExtractor,GherkinASTParser * * ## Source Mapper - Multi-Source Content Aggregation * @@ -324,8 +324,8 @@ export async function extractFromTypeScript( let shapes: ExtractedShape[] | undefined; if (method === 'EXTRACT_SHAPES') { - // Look for @libar-docs-extract-shapes tag in the file - const extractShapesMatch = /@libar-docs-extract-shapes\s+(.+?)(?:\n|$)/i.exec(sourceCode); + // Look for @architect-extract-shapes tag in the file + const extractShapesMatch = /@architect-extract-shapes\s+(.+?)(?:\n|$)/i.exec(sourceCode); if (extractShapesMatch?.[1]) { const shapeNames = extractShapesMatch[1] @@ -370,7 +370,7 @@ export async function extractFromTypeScript( source: filePath, category: 'extraction', subcategory: 'shape-imported', - message: `Shape '${name}' is imported, not defined in this file. Add @libar-docs-extract-shapes to the source file instead.`, + message: `Shape '${name}' is imported, not defined in this file. Add @architect-extract-shapes to the source file instead.`, }); } @@ -381,14 +381,14 @@ export async function extractFromTypeScript( source: filePath, category: 'extraction', subcategory: 'shape-re-exported', - message: `Shape '${reExport.name}' is re-exported${typeOnlyNote} from '${reExport.sourceModule}'. Add @libar-docs-extract-shapes to ${reExport.sourceModule} instead.`, + message: `Shape '${reExport.name}' is re-exported${typeOnlyNote} from '${reExport.sourceModule}'. Add @architect-extract-shapes to ${reExport.sourceModule} instead.`, }); } } } else { // No @extract-shapes tag found - extract all exported types // This is a fallback for files without explicit shape tags - return R.err(new Error(`No @libar-docs-extract-shapes tag found in ${filePath}`)); + return R.err(new Error(`No @architect-extract-shapes tag found in ${filePath}`)); } } else if (method === 'JSDOC_SECTION') { // Extract JSDoc markdown from the file's main JSDoc block diff --git a/src/generators/source-mapping-validator.ts b/src/generators/source-mapping-validator.ts index 1b1351d2..ffd6d6fe 100644 --- a/src/generators/source-mapping-validator.ts +++ b/src/generators/source-mapping-validator.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern SourceMappingValidator - * @libar-docs-status completed + * @architect + * @architect-core + * @architect-pattern SourceMappingValidator + * @architect-status completed * * ## Source Mapping Validator - Pre-flight Validation * diff --git a/src/generators/types.ts b/src/generators/types.ts index bcb0f4d1..06237fe9 100644 --- a/src/generators/types.ts +++ b/src/generators/types.ts @@ -1,5 +1,5 @@ /** - * @libar-docs + * @architect */ import type { ExtractedPattern, TagRegistry } from '../validation-schemas'; @@ -8,11 +8,11 @@ import type { RuntimeMasterDataset } from './pipeline/index.js'; import type { CodecOptions } from '../renderable/generate.js'; /** - * @libar-docs-generator - * @libar-docs-pattern GeneratorTypes - * @libar-docs-status completed - * @libar-docs-used-by GeneratorRegistry, GeneratorFactory, Orchestrator, SectionRegistry - * @libar-docs-extract-shapes DocumentGenerator, GeneratorContext, GeneratorOutput + * @architect-generator + * @architect-pattern GeneratorTypes + * @architect-status completed + * @architect-used-by GeneratorRegistry, GeneratorFactory, Orchestrator, SectionRegistry + * @architect-extract-shapes DocumentGenerator, GeneratorContext, GeneratorOutput * * ## GeneratorTypes - Pluggable Document Generation Interface * diff --git a/src/generators/warning-collector.ts b/src/generators/warning-collector.ts index ccf3d9f9..43e6bfec 100644 --- a/src/generators/warning-collector.ts +++ b/src/generators/warning-collector.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern WarningCollector - * @libar-docs-status completed + * @architect + * @architect-core + * @architect-pattern WarningCollector + * @architect-status completed * * ## Warning Collector - Unified Warning Handling * diff --git a/src/git/branch-diff.ts b/src/git/branch-diff.ts index e69cb429..1074de84 100644 --- a/src/git/branch-diff.ts +++ b/src/git/branch-diff.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-pattern GitBranchDiff - * @libar-docs-status active - * @libar-docs-arch-role utility - * @libar-docs-arch-context generator - * @libar-docs-arch-layer infrastructure - * @libar-docs-used-by Orchestrator + * @architect + * @architect-pattern GitBranchDiff + * @architect-status active + * @architect-arch-role utility + * @architect-arch-context generator + * @architect-arch-layer infrastructure + * @architect-used-by Orchestrator * * ## GitBranchDiff - Pure Git Change Detection * diff --git a/src/git/helpers.ts b/src/git/helpers.ts index d58bd5d7..e738aba1 100644 --- a/src/git/helpers.ts +++ b/src/git/helpers.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-pattern GitHelpers - * @libar-docs-status active - * @libar-docs-arch-role utility - * @libar-docs-arch-context generator - * @libar-docs-arch-layer infrastructure - * @libar-docs-used-by GitBranchDiff, DetectChanges + * @architect + * @architect-pattern GitHelpers + * @architect-status active + * @architect-arch-role utility + * @architect-arch-context generator + * @architect-arch-layer infrastructure + * @architect-used-by GitBranchDiff, DetectChanges * * ## GitHelpers - Shared Git Command Utilities * diff --git a/src/git/index.ts b/src/git/index.ts index 1849bd9e..70fdfa2e 100644 --- a/src/git/index.ts +++ b/src/git/index.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-pattern GitModule - * @libar-docs-status active - * @libar-docs-arch-role barrel - * @libar-docs-arch-context generator - * @libar-docs-arch-layer infrastructure - * @libar-docs-uses GitBranchDiff, GitHelpers + * @architect + * @architect-pattern GitModule + * @architect-status active + * @architect-arch-role barrel + * @architect-arch-context generator + * @architect-arch-layer infrastructure + * @architect-uses GitBranchDiff, GitHelpers * * ## Git Module - Pure Git Operations * diff --git a/src/git/name-status.ts b/src/git/name-status.ts index 1acf4f49..6609f155 100644 --- a/src/git/name-status.ts +++ b/src/git/name-status.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-pattern GitNameStatusParser - * @libar-docs-status active - * @libar-docs-arch-role utility - * @libar-docs-arch-context generator - * @libar-docs-arch-layer infrastructure - * @libar-docs-used-by GitBranchDiff, DetectChanges + * @architect + * @architect-pattern GitNameStatusParser + * @architect-status active + * @architect-arch-role utility + * @architect-arch-context generator + * @architect-arch-layer infrastructure + * @architect-used-by GitBranchDiff, DetectChanges * * ## GitNameStatusParser - Shared Parsing for `git diff --name-status -z` * diff --git a/src/index.ts b/src/index.ts index 1cdee8d0..e30e5e50 100644 --- a/src/index.ts +++ b/src/index.ts @@ -1,15 +1,15 @@ /** - * @libar-docs + * @architect */ /** - * @libar-docs-core @libar-docs-intro - * @libar-docs-pattern PublicAPI - * @libar-docs-status completed + * @architect-core @architect-intro + * @architect-pattern PublicAPI + * @architect-status completed * * ## PublicAPI - Package Entry Point * - * Main entry point for the @libar-dev/delivery-process package. + * Main entry point for the @libar-dev/architect package. * Exports the three-stage pipeline (Scanner → Extractor → Generator) for * extracting documentation directly from TypeScript source code. * @@ -30,29 +30,25 @@ // ============================================================================ /** - * Configuration API for creating customized delivery-process instances. + * Configuration API for creating customized Architect instances. * * @example * ```typescript - * import { createDeliveryProcess, GENERIC_PRESET } from '@libar-dev/delivery-process'; + * import { createArchitect, GENERIC_PRESET } from '@libar-dev/architect'; * * // Use generic preset for non-DDD projects - * const dp = createDeliveryProcess({ preset: "generic" }); + * const dp = createArchitect({ preset: "generic" }); * * // Or customize the tag prefix - * const dp = createDeliveryProcess({ + * const dp = createArchitect({ * tagPrefix: "@my-project-", * fileOptInTag: "@my-project" * }); * ``` */ -export { createDeliveryProcess, type CreateDeliveryProcessOptions } from './config/factory.js'; +export { createArchitect, type CreateArchitectOptions } from './config/factory.js'; -export type { - DeliveryProcessConfig, - DeliveryProcessInstance, - RegexBuilders, -} from './config/types.js'; +export type { ArchitectConfig, ArchitectInstance, RegexBuilders } from './config/types.js'; export { createRegexBuilders } from './config/regex-builders.js'; @@ -88,8 +84,8 @@ export * from './validation-schemas/index.js'; * * @example * ```typescript - * import { generatorRegistry } from '@libar-dev/delivery-process/generators'; - * import '@libar-dev/delivery-process/generators/built-in'; + * import { generatorRegistry } from '@libar-dev/architect/generators'; + * import '@libar-dev/architect/generators/built-in'; * * const generator = generatorRegistry.get('patterns'); * const output = await generator.generate(patterns, context); @@ -109,7 +105,7 @@ export * as generators from './generators/index.js'; * * @example * ```typescript - * import { generateDocument, generateAllDocuments } from '@libar-dev/delivery-process/renderable'; + * import { generateDocument, generateAllDocuments } from '@libar-dev/architect/renderable'; * * // Generate a single document type * const files = generateDocument("patterns", masterDataset); @@ -133,7 +129,7 @@ export * as renderable from './renderable/index.js'; * * @example * ```typescript - * import { lintFiles, validateChanges } from '@libar-dev/delivery-process/lint'; + * import { lintFiles, validateChanges } from '@libar-dev/architect/lint'; * * // Lint pattern annotations * const result = await lintFiles(['src/**\/*.ts']); diff --git a/src/lint/engine.ts b/src/lint/engine.ts index 6afb38ab..053cf6a5 100644 --- a/src/lint/engine.ts +++ b/src/lint/engine.ts @@ -1,18 +1,18 @@ /** - * @libar-docs - * @libar-docs-lint - * @libar-docs-pattern LintEngine - * @libar-docs-status completed - * @libar-docs-uses LintRules, CodecUtils - * @libar-docs-used-by LintPatternsCLI - * @libar-docs-arch-role service - * @libar-docs-arch-context lint - * @libar-docs-arch-layer application + * @architect + * @architect-lint + * @architect-pattern LintEngine + * @architect-status completed + * @architect-uses LintRules, CodecUtils + * @architect-used-by LintPatternsCLI + * @architect-arch-role service + * @architect-arch-context lint + * @architect-arch-layer application * * ## LintEngine - Rule Execution Orchestrator * * Orchestrates lint rule execution against parsed directives. - * Takes scanned @libar-docs-* directives and runs quality rules against them, + * Takes scanned @architect-* directives and runs quality rules against them, * collecting violations and computing summary statistics for CI enforcement. * * ### When to Use diff --git a/src/lint/index.ts b/src/lint/index.ts index 6b66bce0..e61946b8 100644 --- a/src/lint/index.ts +++ b/src/lint/index.ts @@ -1,9 +1,9 @@ /** - * @libar-docs - * @libar-docs-lint - * @libar-docs-pattern LintModule - * @libar-docs-status completed - * @libar-docs-uses LintRules, LintEngine + * @architect + * @architect-lint + * @architect-pattern LintModule + * @architect-status completed + * @architect-uses LintRules, LintEngine * * ## LintModule - Annotation Quality Checking * diff --git a/src/lint/process-guard/decider.ts b/src/lint/process-guard/decider.ts index 25591b08..afd9f1dd 100644 --- a/src/lint/process-guard/decider.ts +++ b/src/lint/process-guard/decider.ts @@ -1,16 +1,16 @@ /** - * @libar-docs - * @libar-docs-lint - * @libar-docs-pattern ProcessGuardDecider - * @libar-docs-status active - * @libar-docs-arch-role decider - * @libar-docs-arch-context lint - * @libar-docs-arch-layer application - * @libar-docs-implements ProcessGuardLinter - * @libar-docs-uses FSMValidator, DeriveProcessState, DetectChanges - * @libar-docs-depends-on:FSMValidator,DeriveProcessState,DetectChanges - * @libar-docs-convention process-guard-errors - * @libar-docs-extract-shapes validateChanges + * @architect + * @architect-lint + * @architect-pattern ProcessGuardDecider + * @architect-status active + * @architect-arch-role decider + * @architect-arch-context lint + * @architect-arch-layer application + * @architect-implements ProcessGuardLinter + * @architect-uses FSMValidator, DeriveProcessState, DetectChanges + * @architect-depends-on:FSMValidator,DeriveProcessState,DetectChanges + * @architect-convention process-guard-errors + * @architect-extract-shapes validateChanges * * ## ProcessGuardDecider - Pure Validation Logic * @@ -52,7 +52,7 @@ * * | Situation | Solution | Example | * |-----------|----------|---------| - * | Fix typo in completed spec | Add unlock reason tag | `@libar-docs-unlock-reason:Fix-typo-in-FSM-diagram` | + * | Fix typo in completed spec | Add unlock reason tag | `@architect-unlock-reason:Fix-typo-in-FSM-diagram` | * | Spec needs rework | Create new spec instead | New feature file with `roadmap` status | * | Legacy import | Multiple transitions in one commit | Set `roadmap` then `completed` | * diff --git a/src/lint/process-guard/derive-state.ts b/src/lint/process-guard/derive-state.ts index 2ed7f2a9..1977db31 100644 --- a/src/lint/process-guard/derive-state.ts +++ b/src/lint/process-guard/derive-state.ts @@ -1,15 +1,15 @@ /** - * @libar-docs - * @libar-docs-lint - * @libar-docs-pattern DeriveProcessState - * @libar-docs-status active - * @libar-docs-implements ProcessGuardLinter - * @libar-docs-uses GherkinScanner, FSMValidator - * @libar-docs-depends-on:GherkinScanner,FSMValidator + * @architect + * @architect-lint + * @architect-pattern DeriveProcessState + * @architect-status active + * @architect-implements ProcessGuardLinter + * @architect-uses GherkinScanner, FSMValidator + * @architect-depends-on:GherkinScanner,FSMValidator * * ## DeriveProcessState - Extract Process State from File Annotations * - * Derives process state from @libar-docs-* annotations in files. + * Derives process state from @architect-* annotations in files. * State is computed on-demand, not stored separately. * * ### Design Principles @@ -59,7 +59,7 @@ export interface DeriveStateConfig { /** Default spec patterns - generic defaults that work for package-level usage */ const DEFAULT_SPEC_PATTERNS = [ - 'delivery-process/**/*.feature', + 'architect/**/*.feature', 'specs/**/*.feature', // For consumers ]; @@ -71,7 +71,7 @@ const DEFAULT_SPEC_PATTERNS = [ * Derive complete process state from file annotations. * * Scans spec files and extracts: - * - Status from @libar-docs-status tags + * - Status from @architect-status tags * - Deliverables from Background tables * - Session state from active session files * @@ -178,7 +178,7 @@ async function deriveFileStates( */ function extractStatusFromTags(tags: readonly string[]): ProcessStatusValue { for (const tag of tags) { - // Handle @libar-docs-status:value format + // Handle @architect-status:value format if (tag.includes('status:')) { const match = /status:(\w+)/.exec(tag); if (match?.[1]) { diff --git a/src/lint/process-guard/detect-changes.ts b/src/lint/process-guard/detect-changes.ts index 67d4e745..e07e3d49 100644 --- a/src/lint/process-guard/detect-changes.ts +++ b/src/lint/process-guard/detect-changes.ts @@ -1,22 +1,22 @@ /** - * @libar-docs - * @libar-docs-lint - * @libar-docs-pattern DetectChanges - * @libar-docs-status active - * @libar-docs-implements ProcessGuardLinter - * @libar-docs-uses DeriveProcessState + * @architect + * @architect-lint + * @architect-pattern DetectChanges + * @architect-status active + * @architect-implements ProcessGuardLinter + * @architect-uses DeriveProcessState * * ## DetectChanges - Git Diff Change Detection * * Detects changes from git diff including: * - Modified, added, deleted files - * - Status transitions (@libar-docs-status changes) + * - Status transitions (@architect-status changes) * - Deliverable changes in Background tables * * ### Design Principles * * - **Parse Git Output**: Uses `git diff --name-status` and `git diff` - * - **Status Detection**: Regex patterns for @libar-docs-status changes + * - **Status Detection**: Regex patterns for @architect-status changes * - **Deliverable Detection**: Parses DataTable changes * * Note: Taxonomy modification detection was removed when taxonomy @@ -258,7 +258,7 @@ interface DiffFileParseState { * * @param diff - Git diff content * @param files - List of files to analyze - * @param tagPrefix - Tag prefix to match (default: "@libar-docs-") + * @param tagPrefix - Tag prefix to match (default: "@architect-") */ function detectStatusTransitions( diff: string, diff --git a/src/lint/process-guard/index.ts b/src/lint/process-guard/index.ts index 1e63b170..83d7750c 100644 --- a/src/lint/process-guard/index.ts +++ b/src/lint/process-guard/index.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-lint - * @libar-docs-pattern ProcessGuardModule - * @libar-docs-status active - * @libar-docs-implements ProcessGuardLinter - * @libar-docs-depends-on:FSMValidator,DeriveProcessState,DetectChanges,ProcessGuardDecider + * @architect + * @architect-lint + * @architect-pattern ProcessGuardModule + * @architect-status active + * @architect-implements ProcessGuardLinter + * @architect-depends-on:FSMValidator,DeriveProcessState,DetectChanges,ProcessGuardDecider * * ## ProcessGuardModule - Process Guard Linter * diff --git a/src/lint/process-guard/types.ts b/src/lint/process-guard/types.ts index f0fc8424..38fdc905 100644 --- a/src/lint/process-guard/types.ts +++ b/src/lint/process-guard/types.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-lint - * @libar-docs-pattern ProcessGuardTypes - * @libar-docs-status active - * @libar-docs-implements ProcessGuardLinter - * @libar-docs-depends-on:FSMValidator - * @libar-docs-extract-shapes ProcessGuardRule, DeciderInput, ValidationResult, ProcessViolation, FileState + * @architect + * @architect-lint + * @architect-pattern ProcessGuardTypes + * @architect-status active + * @architect-implements ProcessGuardLinter + * @architect-depends-on:FSMValidator + * @architect-extract-shapes ProcessGuardRule, DeciderInput, ValidationResult, ProcessViolation, FileState * * ## ProcessGuardTypes - Type Definitions for Process Guard Linter * @@ -50,14 +50,14 @@ export interface ProcessState { } /** - * State for a single file derived from its @libar-docs-* annotations. + * State for a single file derived from its @architect-* annotations. */ export interface FileState { /** Absolute file path */ readonly path: string; /** Relative path from project root */ readonly relativePath: string; - /** Status from @libar-docs-status annotation */ + /** Status from @architect-status annotation */ readonly status: ProcessStatusValue; /** Normalized status for display */ readonly normalizedStatus: NormalizedStatus; @@ -65,7 +65,7 @@ export interface FileState { readonly protection: ProtectionLevel; /** Deliverable names from Background table */ readonly deliverables: readonly string[]; - /** Whether file has @libar-docs-unlock-reason */ + /** Whether file has @architect-unlock-reason */ readonly hasUnlockReason: boolean; /** The unlock reason text if present */ readonly unlockReason?: string; @@ -82,7 +82,7 @@ export type SessionStatus = 'draft' | 'active' | 'closed'; * State for a work session that scopes modifications. */ export interface SessionState { - /** Session identifier from @libar-docs-session-id */ + /** Session identifier from @architect-session-id */ readonly id: string; /** Session lifecycle status */ readonly status: SessionStatus; diff --git a/src/lint/rules.ts b/src/lint/rules.ts index 447919b3..500bbf56 100644 --- a/src/lint/rules.ts +++ b/src/lint/rules.ts @@ -1,18 +1,18 @@ /** - * @libar-docs - * @libar-docs-lint - * @libar-docs-pattern LintRules - * @libar-docs-status completed - * @libar-docs-arch-role service - * @libar-docs-arch-context lint - * @libar-docs-arch-layer application - * @libar-docs-implements PatternRelationshipModel - * @libar-docs-used-by LintEngine - * @libar-docs-extract-shapes LintRule, LintContext, defaultRules, severityOrder, filterRulesBySeverity, missingPatternName, missingStatus, invalidStatus, missingWhenToUse, tautologicalDescription, missingRelationships, patternConflictInImplements, missingRelationshipTarget + * @architect + * @architect-lint + * @architect-pattern LintRules + * @architect-status completed + * @architect-arch-role service + * @architect-arch-context lint + * @architect-arch-layer application + * @architect-implements PatternRelationshipModel + * @architect-used-by LintEngine + * @architect-extract-shapes LintRule, LintContext, defaultRules, severityOrder, filterRulesBySeverity, missingPatternName, missingStatus, invalidStatus, missingWhenToUse, tautologicalDescription, missingRelationships, patternConflictInImplements, missingRelationshipTarget * * ## LintRules - Annotation Quality Rules * - * Defines lint rules that check @libar-docs-* directives for completeness + * Defines lint rules that check @architect-* directives for completeness * and quality. Rules include: missing-pattern-name, missing-status, * missing-when-to-use, tautological-description, and missing-relationships. * @@ -297,12 +297,12 @@ export const missingRelationships: LintRule = { * Rule: pattern-conflict-in-implements * * Validates that a file doesn't create a circular reference by defining - * a pattern that it also implements. Having both @libar-docs-pattern X - * AND @libar-docs-implements X on the same file is a conflict. + * a pattern that it also implements. Having both @architect-pattern X + * AND @architect-implements X on the same file is a conflict. * * However, a file CAN have both tags when they reference DIFFERENT patterns: - * - @libar-docs-pattern SubPattern (defines its own identity) - * - @libar-docs-implements ParentSpec (links to parent spec) + * - @architect-pattern SubPattern (defines its own identity) + * - @architect-implements ParentSpec (links to parent spec) * * This supports the sub-pattern hierarchy where implementation files can be * named patterns that also implement a larger spec (e.g., MockPaymentActions diff --git a/src/lint/steps/runner.ts b/src/lint/steps/runner.ts index 5248437a..e5d167c6 100644 --- a/src/lint/steps/runner.ts +++ b/src/lint/steps/runner.ts @@ -19,8 +19,8 @@ import { resolveFeatureStepPairs } from './pair-resolver.js'; */ const DEFAULT_FEATURE_GLOBS = [ 'tests/features/**/*.feature', - 'delivery-process/specs/**/*.feature', - 'delivery-process/decisions/**/*.feature', + 'architect/specs/**/*.feature', + 'architect/decisions/**/*.feature', ]; const DEFAULT_STEP_GLOBS = ['tests/steps/**/*.steps.ts']; diff --git a/src/mcp/file-watcher.ts b/src/mcp/file-watcher.ts index 6cbe2b90..41ac026d 100644 --- a/src/mcp/file-watcher.ts +++ b/src/mcp/file-watcher.ts @@ -1,12 +1,15 @@ +// SPDX-License-Identifier: BUSL-1.1 +// Copyright (c) 2026 EBIZ d.o.o. All rights reserved. + /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern MCPFileWatcher - * @libar-docs-status active - * @libar-docs-arch-role infrastructure - * @libar-docs-arch-context api - * @libar-docs-arch-layer infrastructure - * @libar-docs-implements MCPServerIntegration + * @architect + * @architect-core + * @architect-pattern MCPFileWatcher + * @architect-status active + * @architect-arch-role infrastructure + * @architect-arch-context api + * @architect-arch-layer infrastructure + * @architect-implements MCPServerIntegration * * ## MCP File Watcher * diff --git a/src/mcp/index.ts b/src/mcp/index.ts index a692700b..cb117459 100644 --- a/src/mcp/index.ts +++ b/src/mcp/index.ts @@ -1,12 +1,15 @@ +// SPDX-License-Identifier: BUSL-1.1 +// Copyright (c) 2026 EBIZ d.o.o. All rights reserved. + /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern MCPModule - * @libar-docs-status active - * @libar-docs-arch-role infrastructure - * @libar-docs-arch-context api - * @libar-docs-arch-layer application - * @libar-docs-uses MCPServerImpl, MCPPipelineSession, MCPFileWatcher, MCPToolRegistry + * @architect + * @architect-core + * @architect-pattern MCPModule + * @architect-status active + * @architect-arch-role infrastructure + * @architect-arch-context api + * @architect-arch-layer application + * @architect-uses MCPServerImpl, MCPPipelineSession, MCPFileWatcher, MCPToolRegistry * * ## MCP Module Exports * diff --git a/src/mcp/pipeline-session.ts b/src/mcp/pipeline-session.ts index 023ab53c..d22061bf 100644 --- a/src/mcp/pipeline-session.ts +++ b/src/mcp/pipeline-session.ts @@ -1,13 +1,16 @@ +// SPDX-License-Identifier: BUSL-1.1 +// Copyright (c) 2026 EBIZ d.o.o. All rights reserved. + /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern MCPPipelineSession - * @libar-docs-status active - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer application - * @libar-docs-uses PipelineFactory, ProcessStateAPI, ConfigLoader - * @libar-docs-implements MCPServerIntegration + * @architect + * @architect-core + * @architect-pattern MCPPipelineSession + * @architect-status active + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer application + * @architect-uses PipelineFactory, ProcessStateAPI, ConfigLoader + * @architect-implements MCPServerIntegration * * ## MCP Pipeline Session Manager * @@ -78,7 +81,7 @@ export class PipelineSessionManager { if (input.length === 0) { throw new Error( - 'No TypeScript source globs found. Provide --input or create delivery-process.config.ts' + 'No TypeScript source globs found. Provide --input or create architect.config.ts' ); } @@ -186,25 +189,25 @@ export class PipelineSessionManager { features: string[]; }): void { if (config.input.length === 0) { - const tsConfigPath = path.join(config.baseDir, 'delivery-process.config.ts'); - const jsConfigPath = path.join(config.baseDir, 'delivery-process.config.js'); + const tsConfigPath = path.join(config.baseDir, 'architect.config.ts'); + const jsConfigPath = path.join(config.baseDir, 'architect.config.js'); if (fs.existsSync(tsConfigPath) || fs.existsSync(jsConfigPath)) { config.input.push('src/**/*.ts'); - const stubsDir = path.join(config.baseDir, 'delivery-process', 'stubs'); + const stubsDir = path.join(config.baseDir, 'architect', 'stubs'); if (fs.existsSync(stubsDir)) { - config.input.push('delivery-process/stubs/**/*.ts'); + config.input.push('architect/stubs/**/*.ts'); } } } if (config.features.length === 0) { - const specsDir = path.join(config.baseDir, 'delivery-process', 'specs'); + const specsDir = path.join(config.baseDir, 'architect', 'specs'); if (fs.existsSync(specsDir)) { - config.features.push('delivery-process/specs/*.feature'); + config.features.push('architect/specs/*.feature'); } - const releasesDir = path.join(config.baseDir, 'delivery-process', 'releases'); + const releasesDir = path.join(config.baseDir, 'architect', 'releases'); if (fs.existsSync(releasesDir)) { - config.features.push('delivery-process/releases/*.feature'); + config.features.push('architect/releases/*.feature'); } } } diff --git a/src/mcp/server.ts b/src/mcp/server.ts index e0249356..5fa92438 100644 --- a/src/mcp/server.ts +++ b/src/mcp/server.ts @@ -1,17 +1,20 @@ +// SPDX-License-Identifier: BUSL-1.1 +// Copyright (c) 2026 EBIZ d.o.o. All rights reserved. + /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern MCPServerImpl - * @libar-docs-status active - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer application - * @libar-docs-uses MCPPipelineSession, MCPToolRegistry, MCPFileWatcher - * @libar-docs-implements MCPServerIntegration + * @architect + * @architect-core + * @architect-pattern MCPServerImpl + * @architect-status active + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer application + * @architect-uses MCPPipelineSession, MCPToolRegistry, MCPFileWatcher + * @architect-implements MCPServerIntegration * * ## MCP Server Entry Point * - * Main entry point for the delivery-process MCP server. + * Main entry point for the Architect MCP server. * Initializes the pipeline, registers tools, and connects via stdio transport. * * Stdout isolation (console.log → stderr redirect) is handled by the CLI @@ -58,7 +61,7 @@ export type ParseCliResult = // ============================================================================= function log(message: string): void { - console.error(`[dp-mcp] ${message}`); + console.error(`[architect-mcp] ${message}`); } const DEFAULT_MCP_SERVER_VERSION = getPackageVersion(); @@ -77,10 +80,7 @@ export async function startMcpServer(options: McpServerOptions = {}): Promise TypeScript source globs (repeatable) @@ -222,14 +222,14 @@ Options: -h, --help Show this help -v, --version Show version -The server auto-detects delivery-process.config.ts if no explicit +The server auto-detects architect.config.ts if no explicit globs are provided. Configure in Claude Code via .mcp.json: { "mcpServers": { - "delivery-process": { + "architect": { "command": "npx", - "args": ["dp-mcp-server"], + "args": ["architect-mcp"], "cwd": "/path/to/project" } } diff --git a/src/mcp/tool-registry.ts b/src/mcp/tool-registry.ts index 8692f070..ec1ee65c 100644 --- a/src/mcp/tool-registry.ts +++ b/src/mcp/tool-registry.ts @@ -1,19 +1,22 @@ +// SPDX-License-Identifier: BUSL-1.1 +// Copyright (c) 2026 EBIZ d.o.o. All rights reserved. + /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern MCPToolRegistry - * @libar-docs-status active - * @libar-docs-arch-role service - * @libar-docs-arch-context api - * @libar-docs-arch-layer application - * @libar-docs-uses ProcessStateAPI, MCPPipelineSession - * @libar-docs-implements MCPServerIntegration + * @architect + * @architect-core + * @architect-pattern MCPToolRegistry + * @architect-status active + * @architect-arch-role service + * @architect-arch-context api + * @architect-arch-layer application + * @architect-uses ProcessStateAPI, MCPPipelineSession + * @architect-implements MCPServerIntegration * * ## MCP Tool Registry * * Defines all MCP tools with Zod input schemas and handler functions. * Each tool wraps a ProcessStateAPI method or CLI subcommand. - * Tool names use "dp_" prefix to avoid collisions with other MCP servers. + * Tool names use "architect_" prefix to avoid collisions with other MCP servers. * * ### When to Use * @@ -108,7 +111,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess // --------------------------------------------------------------------------- server.registerTool( - 'dp_overview', + 'architect_overview', { title: 'Project Overview', description: @@ -123,7 +126,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_context', + 'architect_context', { title: 'Pattern Context', description: @@ -150,7 +153,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_files', + 'architect_files', { title: 'File Reading List', description: @@ -167,7 +170,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_dep_tree', + 'architect_dep_tree', { title: 'Dependency Tree', description: @@ -189,7 +192,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_scope_validate', + 'architect_scope_validate', { title: 'Scope Validation', description: @@ -211,7 +214,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_handoff', + 'architect_handoff', { title: 'Session Handoff', description: @@ -239,7 +242,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess // --------------------------------------------------------------------------- server.registerTool( - 'dp_status', + 'architect_status', { title: 'Status Counts', description: @@ -256,7 +259,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_pattern', + 'architect_pattern', { title: 'Pattern Detail', description: @@ -282,7 +285,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_list', + 'architect_list', { title: 'List Patterns', description: @@ -323,7 +326,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_search', + 'architect_search', { title: 'Search Patterns', description: @@ -341,7 +344,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_rules', + 'architect_rules', { title: 'Business Rules', description: @@ -381,7 +384,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_tags', + 'architect_tags', { title: 'Tag Usage Report', description: 'Get tag inventory: counts per tag and value across all annotated sources.', @@ -394,7 +397,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_sources', + 'architect_sources', { title: 'Source Inventory', description: @@ -408,7 +411,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_stubs', + 'architect_stubs', { title: 'Design Stubs', description: @@ -434,7 +437,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_decisions', + 'architect_decisions', { title: 'Design Decisions', description: 'Extract design decisions (AD-N / DD-N) from pattern descriptions.', @@ -473,7 +476,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess // --------------------------------------------------------------------------- server.registerTool( - 'dp_arch_context', + 'architect_arch_context', { title: 'Architecture Contexts', description: @@ -502,7 +505,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_arch_layer', + 'architect_arch_layer', { title: 'Architecture Layers', description: @@ -531,7 +534,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_arch_neighborhood', + 'architect_arch_neighborhood', { title: 'Pattern Neighborhood', description: @@ -547,7 +550,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_arch_blocking', + 'architect_arch_blocking', { title: 'Blocked Patterns', description: @@ -562,7 +565,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_arch_dangling', + 'architect_arch_dangling', { title: 'Dangling References', description: 'Find broken references to nonexistent pattern names in relationship tags.', @@ -591,7 +594,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_arch_coverage', + 'architect_arch_coverage', { title: 'Annotation Coverage', description: @@ -621,11 +624,11 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_unannotated', + 'architect_unannotated', { title: 'Unannotated Files', description: - 'Find TypeScript files missing @libar-docs annotations. Optionally filter by directory.', + 'Find TypeScript files missing @architect annotations. Optionally filter by directory.', inputSchema: z.object({ path: z.string().optional().describe('Filter to a specific directory path'), }), @@ -647,7 +650,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess // --------------------------------------------------------------------------- server.registerTool( - 'dp_rebuild', + 'architect_rebuild', { title: 'Rebuild Dataset', description: @@ -663,7 +666,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_config', + 'architect_config', { title: 'Current Configuration', description: @@ -684,7 +687,7 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess ); server.registerTool( - 'dp_help', + 'architect_help', { title: 'MCP Tools Help', description: @@ -693,33 +696,33 @@ export function registerAllTools(server: McpServer, sessionManager: PipelineSess }, safeHandler(() => { const tools = [ - 'dp_overview - Project health summary (start here)', - 'dp_context - Session-aware context bundle for a pattern', - 'dp_pattern - Full pattern metadata', - 'dp_list - List patterns with filters', - 'dp_search - Fuzzy search patterns', - 'dp_status - Status counts and completion %', - 'dp_files - File reading list for a pattern', - 'dp_dep_tree - Dependency chain with status', - 'dp_scope_validate - Pre-flight check for implementation', - 'dp_handoff - Session-end state for continuity', - 'dp_rules - Business rules and invariants', - 'dp_tags - Tag usage report', - 'dp_sources - Source file inventory', - 'dp_stubs - Design stubs with resolution status', - 'dp_decisions - Design decisions from stubs', - 'dp_arch_context - Bounded contexts with members', - 'dp_arch_layer - Architecture layers with members', - 'dp_arch_neighborhood - Pattern uses/used-by/peers', - 'dp_arch_blocking - Patterns blocked by dependencies', - 'dp_arch_dangling - Broken pattern references', - 'dp_arch_coverage - Annotation coverage analysis', - 'dp_unannotated - Files missing @libar-docs', - 'dp_rebuild - Force dataset rebuild', - 'dp_config - Show current configuration', - 'dp_help - This help text', + 'architect_overview - Project health summary (start here)', + 'architect_context - Session-aware context bundle for a pattern', + 'architect_pattern - Full pattern metadata', + 'architect_list - List patterns with filters', + 'architect_search - Fuzzy search patterns', + 'architect_status - Status counts and completion %', + 'architect_files - File reading list for a pattern', + 'architect_dep_tree - Dependency chain with status', + 'architect_scope_validate - Pre-flight check for implementation', + 'architect_handoff - Session-end state for continuity', + 'architect_rules - Business rules and invariants', + 'architect_tags - Tag usage report', + 'architect_sources - Source file inventory', + 'architect_stubs - Design stubs with resolution status', + 'architect_decisions - Design decisions from stubs', + 'architect_arch_context - Bounded contexts with members', + 'architect_arch_layer - Architecture layers with members', + 'architect_arch_neighborhood - Pattern uses/used-by/peers', + 'architect_arch_blocking - Patterns blocked by dependencies', + 'architect_arch_dangling - Broken pattern references', + 'architect_arch_coverage - Annotation coverage analysis', + 'architect_unannotated - Files missing @architect', + 'architect_rebuild - Force dataset rebuild', + 'architect_config - Show current configuration', + 'architect_help - This help text', ]; - return textResult(`delivery-process MCP Server — Available Tools\n\n${tools.join('\n')}`); + return textResult(`Architect MCP Server — Available Tools\n\n${tools.join('\n')}`); }) ); } diff --git a/src/renderable/codecs/adr.ts b/src/renderable/codecs/adr.ts index 531322d4..5c775653 100644 --- a/src/renderable/codecs/adr.ts +++ b/src/renderable/codecs/adr.ts @@ -1,17 +1,17 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern AdrDocumentCodec - * @libar-docs-status completed - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern AdrDocumentCodec + * @architect-status completed + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## AdrDocumentCodec * * Transforms MasterDataset into RenderableDocument for Architecture Decision Records. - * Extracts ADRs from patterns with `@libar-docs-adr` tags. + * Extracts ADRs from patterns with `@architect-adr` tags. * - * **Purpose:** Architecture Decision Records extracted from patterns with @libar-docs-adr tags. + * **Purpose:** Architecture Decision Records extracted from patterns with @architect-adr tags. * * **Output Files:** `DECISIONS.md` (ADR index), `decisions/.md` (category details) * @@ -169,7 +169,7 @@ function buildAdrDocument( if (adrPatterns.length === 0) { sections.push( heading(2, 'No Architecture Decisions'), - paragraph('No patterns have @libar-docs-adr tags.') + paragraph('No patterns have @architect-adr tags.') ); return document('Architecture Decision Records', sections, { diff --git a/src/renderable/codecs/architecture.ts b/src/renderable/codecs/architecture.ts index 934e5496..ef82fdf8 100644 --- a/src/renderable/codecs/architecture.ts +++ b/src/renderable/codecs/architecture.ts @@ -1,15 +1,15 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern ArchitectureCodec - * @libar-docs-status completed - * @libar-docs-arch-role projection - * @libar-docs-arch-context renderer - * @libar-docs-arch-layer application - * @libar-docs-include codec-transformation - * @libar-docs-uses MasterDataset, ArchIndex - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern ArchitectureCodec + * @architect-status completed + * @architect-arch-role projection + * @architect-arch-context renderer + * @architect-arch-layer application + * @architect-include codec-transformation + * @architect-uses MasterDataset, ArchIndex + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## ArchitectureDocumentCodec * @@ -195,8 +195,8 @@ function buildArchitectureDocument( heading(2, 'No Architecture Data'), paragraph( 'No patterns with architecture annotations found. ' + - 'Add `@libar-docs-arch-role`, `@libar-docs-arch-context`, or ' + - '`@libar-docs-arch-layer` tags to source files to generate architecture diagrams.' + 'Add `@architect-arch-role`, `@architect-arch-context`, or ' + + '`@architect-arch-layer` tags to source files to generate architecture diagrams.' ), ]); } diff --git a/src/renderable/codecs/business-rules.ts b/src/renderable/codecs/business-rules.ts index e638ef27..cf2d7e6d 100644 --- a/src/renderable/codecs/business-rules.ts +++ b/src/renderable/codecs/business-rules.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern BusinessRulesCodec - * @libar-docs-status completed - * @libar-docs-unlock-reason:Progressive-disclosure-by-product-area - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern BusinessRulesCodec + * @architect-status completed + * @architect-unlock-reason:Progressive-disclosure-by-product-area + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## BusinessRulesCodec * diff --git a/src/renderable/codecs/claude-module.ts b/src/renderable/codecs/claude-module.ts index 25f0181d..1db758e1 100644 --- a/src/renderable/codecs/claude-module.ts +++ b/src/renderable/codecs/claude-module.ts @@ -1,9 +1,9 @@ /** - * @libar-docs - * @libar-docs-pattern ClaudeModuleCodec - * @libar-docs-status active - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-pattern ClaudeModuleCodec + * @architect-status active + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## ClaudeModuleCodec * @@ -145,7 +145,7 @@ function buildClaudeModuleDocument( 'Claude Modules', [ heading(2, 'No Claude Modules Found'), - paragraph('No patterns have `@libar-docs-claude-module` tags.'), + paragraph('No patterns have `@architect-claude-module` tags.'), ], { purpose: 'Claude module generation index', diff --git a/src/renderable/codecs/composite.ts b/src/renderable/codecs/composite.ts index 14236726..7fd12677 100644 --- a/src/renderable/codecs/composite.ts +++ b/src/renderable/codecs/composite.ts @@ -1,14 +1,14 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern CompositeCodec - * @libar-docs-status active - * @libar-docs-implements ReferenceDocShowcase - * @libar-docs-arch-role projection - * @libar-docs-arch-context renderer - * @libar-docs-arch-layer application - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern CompositeCodec + * @architect-status active + * @architect-implements ReferenceDocShowcase + * @architect-arch-role projection + * @architect-arch-context renderer + * @architect-arch-layer application + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## CompositeCodec * diff --git a/src/renderable/codecs/convention-extractor.ts b/src/renderable/codecs/convention-extractor.ts index f25a95d6..4b61e93b 100644 --- a/src/renderable/codecs/convention-extractor.ts +++ b/src/renderable/codecs/convention-extractor.ts @@ -1,7 +1,7 @@ /** * Convention Extractor * - * Filters MasterDataset for patterns tagged with `@libar-docs-convention` + * Filters MasterDataset for patterns tagged with `@architect-convention` * and extracts convention content as structured data for reference codec * composition. Supports two sources: * @@ -313,7 +313,7 @@ function extractConventionRulesFromDescription( /** * Extracts convention content from MasterDataset. * - * Filters patterns tagged with `@libar-docs-convention` matching the + * Filters patterns tagged with `@architect-convention` matching the * requested tag values. For Gherkin-sourced patterns, extracts from * Rule: blocks. For TypeScript-sourced patterns (no rules array), * decomposes the JSDoc description by ## headings. diff --git a/src/renderable/codecs/decision-doc.ts b/src/renderable/codecs/decision-doc.ts index 1a06dcf7..e76cbc65 100644 --- a/src/renderable/codecs/decision-doc.ts +++ b/src/renderable/codecs/decision-doc.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern DecisionDocCodec - * @libar-docs-status completed - * @libar-docs-arch-role projection - * @libar-docs-arch-context renderer - * @libar-docs-arch-layer application + * @architect + * @architect-core + * @architect-pattern DecisionDocCodec + * @architect-status completed + * @architect-arch-role projection + * @architect-arch-context renderer + * @architect-arch-layer application * * ## Decision Doc Codec * diff --git a/src/renderable/codecs/design-review.ts b/src/renderable/codecs/design-review.ts index ceaa5563..857f9576 100644 --- a/src/renderable/codecs/design-review.ts +++ b/src/renderable/codecs/design-review.ts @@ -1,16 +1,16 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern DesignReviewCodec - * @libar-docs-status active - * @libar-docs-implements DesignReviewGeneration - * @libar-docs-arch-role projection - * @libar-docs-arch-context renderer - * @libar-docs-arch-layer application - * @libar-docs-include codec-transformation - * @libar-docs-uses MasterDataset, SequenceIndex, MermaidDiagramUtils - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern DesignReviewCodec + * @architect-status active + * @architect-implements DesignReviewGeneration + * @architect-arch-role projection + * @architect-arch-context renderer + * @architect-arch-layer application + * @architect-include codec-transformation + * @architect-uses MasterDataset, SequenceIndex, MermaidDiagramUtils + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## DesignReviewCodec * @@ -21,7 +21,7 @@ * **Purpose:** Auto-generate design review documents from sequence annotations * on Gherkin specs. Diagrams stay synchronized with spec changes. * - * **Output Files:** `delivery-process/design-reviews/{pattern-name}.md` + * **Output Files:** `architect/design-reviews/{pattern-name}.md` * * ### Factory Pattern * @@ -136,7 +136,7 @@ function buildDesignReviewDocument( heading(2, 'No Sequence Data'), paragraph( `Pattern "${patternName}" has no sequence annotations. ` + - 'Add `@libar-docs-sequence-orchestrator` and `@libar-docs-sequence-step` ' + + 'Add `@architect-sequence-orchestrator` and `@architect-sequence-step` ' + 'tags to generate design review diagrams.' ), ]); @@ -237,9 +237,9 @@ function buildSequenceDiagramSection( return [ heading(2, 'Sequence Diagram — Runtime Interaction Flow'), paragraph( - 'Generated from: `@libar-docs-sequence-step`, `@libar-docs-sequence-module`, ' + - '`@libar-docs-sequence-error`, `**Input:**`/`**Output:**` markers, and ' + - '`@libar-docs-sequence-orchestrator` on the Feature.' + 'Generated from: `@architect-sequence-step`, `@architect-sequence-module`, ' + + '`@architect-sequence-error`, `**Input:**`/`**Output:**` markers, and ' + + '`@architect-sequence-orchestrator` on the Feature.' ), mermaid(lines.join('\n')), ]; @@ -314,7 +314,7 @@ function buildComponentDiagramSection( return [ heading(2, 'Component Diagram — Types and Data Flow'), paragraph( - 'Generated from: `@libar-docs-sequence-module` (nodes), `**Input:**`/`**Output:**` ' + + 'Generated from: `@architect-sequence-module` (nodes), `**Input:**`/`**Output:**` ' + '(edges and type shapes), deliverables table (locations), and `sequence-step` (grouping).' ), mermaid(lines.join('\n')), diff --git a/src/renderable/codecs/diagram-utils.ts b/src/renderable/codecs/diagram-utils.ts index b393d6d2..58ce33d5 100644 --- a/src/renderable/codecs/diagram-utils.ts +++ b/src/renderable/codecs/diagram-utils.ts @@ -1,9 +1,9 @@ /** - * @libar-docs - * @libar-docs-pattern MermaidDiagramUtils - * @libar-docs-status completed - * @libar-docs-used-by Architecture Codec, Reference Codec - * @libar-docs-arch-context renderer + * @architect + * @architect-pattern MermaidDiagramUtils + * @architect-status completed + * @architect-used-by Architecture Codec, Reference Codec + * @architect-arch-context renderer * * ## Shared Mermaid Diagram Utilities * diff --git a/src/renderable/codecs/helpers.ts b/src/renderable/codecs/helpers.ts index 013282f0..df00c8c1 100644 --- a/src/renderable/codecs/helpers.ts +++ b/src/renderable/codecs/helpers.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern RichContentHelpers - * @libar-docs-status completed + * @architect + * @architect-core + * @architect-pattern RichContentHelpers + * @architect-status completed * * ## Rich Content Rendering Helpers * diff --git a/src/renderable/codecs/index-codec.ts b/src/renderable/codecs/index-codec.ts index 95ea172b..4b6ddc40 100644 --- a/src/renderable/codecs/index-codec.ts +++ b/src/renderable/codecs/index-codec.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern IndexCodec - * @libar-docs-status completed - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation - * @libar-docs-implements EnhancedIndexGeneration + * @architect + * @architect-core + * @architect-pattern IndexCodec + * @architect-status completed + * @architect-convention codec-registry + * @architect-product-area:Generation + * @architect-implements EnhancedIndexGeneration * * ## IndexCodec * @@ -172,7 +172,7 @@ function buildIndexDocument( return document('Documentation Index', sections, { purpose: - 'Navigate the full documentation set for @libar-dev/delivery-process. ' + + 'Navigate the full documentation set for @libar-dev/architect. ' + 'Use section links for targeted reading.', }); } @@ -190,7 +190,7 @@ function buildPackageMetadata(dataset: MasterDataset): SectionBlock[] { table( ['Field', 'Value'], [ - ['**Package**', '@libar-dev/delivery-process'], + ['**Package**', '@libar-dev/architect'], ['**Purpose**', 'Code-first documentation and delivery process toolkit'], [ '**Patterns**', diff --git a/src/renderable/codecs/index.ts b/src/renderable/codecs/index.ts index 8032fee9..8ef149d0 100644 --- a/src/renderable/codecs/index.ts +++ b/src/renderable/codecs/index.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern DocumentCodecs - * @libar-docs-status completed + * @architect + * @architect-core + * @architect-pattern DocumentCodecs + * @architect-status completed * * ## Document Codecs * diff --git a/src/renderable/codecs/patterns.ts b/src/renderable/codecs/patterns.ts index fac8e643..189a0b32 100644 --- a/src/renderable/codecs/patterns.ts +++ b/src/renderable/codecs/patterns.ts @@ -1,15 +1,15 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern PatternsCodec - * @libar-docs-status completed - * @libar-docs-arch-role projection - * @libar-docs-arch-context renderer - * @libar-docs-arch-layer application - * @libar-docs-include codec-transformation,pipeline-stages - * @libar-docs-implements PatternRelationshipModel - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern PatternsCodec + * @architect-status completed + * @architect-arch-role projection + * @architect-arch-context renderer + * @architect-arch-layer application + * @architect-include codec-transformation,pipeline-stages + * @architect-implements PatternRelationshipModel + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## PatternsDocumentCodec * @@ -565,7 +565,7 @@ function buildSinglePatternDocument( } } - // Implementations (files that implement this pattern via @libar-docs-implements) + // Implementations (files that implement this pattern via @architect-implements) const patternKey = getPatternName(pattern); const rel = dataset.relationshipIndex?.[patternKey]; if (rel?.implementedBy && rel.implementedBy.length > 0) { @@ -587,7 +587,7 @@ function buildSinglePatternDocument( ); } - // Extensions (patterns that extend this pattern via @libar-docs-extends) + // Extensions (patterns that extend this pattern via @architect-extends) if (rel?.extendedBy && rel.extendedBy.length > 0) { sections.push(heading(2, 'Extensions')); sections.push( diff --git a/src/renderable/codecs/planning.ts b/src/renderable/codecs/planning.ts index c8f53aa4..5397117d 100644 --- a/src/renderable/codecs/planning.ts +++ b/src/renderable/codecs/planning.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern PlanningCodecs - * @libar-docs-status completed - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern PlanningCodecs + * @architect-status completed + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## PlanningChecklistCodec * diff --git a/src/renderable/codecs/pr-changes.ts b/src/renderable/codecs/pr-changes.ts index 900675b6..5c3dacfa 100644 --- a/src/renderable/codecs/pr-changes.ts +++ b/src/renderable/codecs/pr-changes.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern PrChangesCodec - * @libar-docs-status completed - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern PrChangesCodec + * @architect-status completed + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## PrChangesCodec * diff --git a/src/renderable/codecs/reference.ts b/src/renderable/codecs/reference.ts index 0724a491..0c3a63ed 100644 --- a/src/renderable/codecs/reference.ts +++ b/src/renderable/codecs/reference.ts @@ -1,16 +1,16 @@ /** - * @libar-docs - * @libar-docs-pattern ReferenceDocumentCodec - * @libar-docs-status active - * @libar-docs-implements CodecDrivenReferenceGeneration - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-pattern ReferenceDocumentCodec + * @architect-status active + * @architect-implements CodecDrivenReferenceGeneration + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## ReferenceDocumentCodec * * A single codec factory that creates reference document codecs from * configuration objects. Convention content is sourced from - * decision records tagged with @libar-docs-convention. + * decision records tagged with @architect-convention. * * **Purpose:** Scoped reference documentation assembling four content layers (conventions, diagrams, shapes, behaviors) into a single document. * @@ -18,7 +18,7 @@ * * ### 4-Layer Composition (in order) * - * 1. **Convention content** -- Extracted from `@libar-docs-convention`-tagged patterns (rules, invariants, tables) + * 1. **Convention content** -- Extracted from `@architect-convention`-tagged patterns (rules, invariants, tables) * 2. **Scoped diagrams** -- Mermaid diagrams filtered by `archContext`, `archLayer`, `patterns`, or `include` tags * 3. **TypeScript shapes** -- API surfaces from `shapeSources` globs or `shapeSelectors` (declaration-level filtering) * 4. **Behavior content** -- Gherkin-sourced patterns from `behaviorCategories` @@ -239,7 +239,7 @@ export interface ReferenceDocConfig { /** * Exclude patterns whose source.file starts with any of these prefixes. * Used to filter ephemeral planning specs from behavior sections. - * @example ['delivery-process/specs/'] + * @example ['architect/specs/'] */ readonly excludeSourcePaths?: readonly string[]; @@ -344,11 +344,11 @@ export const PRODUCT_AREA_META: Readonly> = { covers: 'Config loading, presets, resolution, source merging, schema validation', intro: 'Configuration is the entry boundary — it transforms a user-authored ' + - '`delivery-process.config.ts` file into a fully resolved `DeliveryProcessInstance` ' + + '`architect.config.ts` file into a fully resolved `ArchitectInstance` ' + 'that powers the entire pipeline. The flow is: `defineConfig()` provides type-safe ' + 'authoring (Vite convention, zero validation), `ConfigLoader` discovers and loads ' + 'the file, `ProjectConfigSchema` validates via Zod, `ConfigResolver` applies defaults ' + - 'and merges stubs into sources, and `DeliveryProcessFactory` builds the final instance ' + + 'and merges stubs into sources, and `ArchitectFactory` builds the final instance ' + 'with `TagRegistry` and `RegexBuilders`. Three presets define escalating taxonomy ' + 'complexity — from 3 categories (`generic`, `libar-generic`) to 21 (`ddd-es-cqrs`). ' + '`SourceMerger` computes per-generator source overrides, enabling generators like ' + @@ -366,13 +366,13 @@ export const PRODUCT_AREA_META: Readonly> = { }, ], keyInvariants: [ - 'Preset-based taxonomy: `generic` (3 categories, `@docs-`), `libar-generic` (3 categories, `@libar-docs-`), `ddd-es-cqrs` (21 categories, full DDD). Presets replace base categories entirely — they define prefix, categories, and metadata tags as a unit', - 'Resolution pipeline: defineConfig() → ConfigLoader → ProjectConfigSchema (Zod) → ConfigResolver → DeliveryProcessFactory → DeliveryProcessInstance. Each stage has a single responsibility', + 'Preset-based taxonomy: `generic` (3 categories, `@docs-`), `libar-generic` (3 categories, `@architect-`), `ddd-es-cqrs` (21 categories, full DDD). Presets replace base categories entirely — they define prefix, categories, and metadata tags as a unit', + 'Resolution pipeline: defineConfig() → ConfigLoader → ProjectConfigSchema (Zod) → ConfigResolver → ArchitectFactory → ArchitectInstance. Each stage has a single responsibility', 'Stubs merged at resolution time: Stub directory globs are appended to typescript sources, making stubs transparent to the downstream pipeline', 'Source override composition: SourceMerger applies per-generator overrides (`replaceFeatures`, `additionalFeatures`, `additionalInput`) to base sources. Exclude is always inherited from base', ], keyPatterns: [ - 'DeliveryProcessFactory', + 'ArchitectFactory', 'ConfigLoader', 'ConfigResolver', 'DefineConfig', @@ -397,7 +397,7 @@ export const PRODUCT_AREA_META: Readonly> = { table( ['Stage', 'Module', 'Responsibility'], [ - ['Scanner', '`src/scanner/`', 'File discovery, AST parsing, opt-in via `@libar-docs`'], + ['Scanner', '`src/scanner/`', 'File discovery, AST parsing, opt-in via `@architect`'], [ 'Extractor', '`src/extractor/`', @@ -441,7 +441,7 @@ export const PRODUCT_AREA_META: Readonly> = { 'Config-driven generation: A single `ReferenceDocConfig` produces a complete document. Content sources compose in fixed order: conventions, diagrams, shapes, behaviors', 'RenderableDocument IR: Codecs express intent ("this is a table"), the renderer handles syntax ("pipe-delimited markdown"). Switching output format requires only a new renderer', 'Composition order: Reference docs compose four content layers in fixed order. Product area docs compose five layers: intro, conventions, diagrams, shapes, business rules', - 'Shape extraction: TypeScript shapes (`interface`, `type`, `enum`, `function`, `const`) are extracted by declaration-level `@libar-docs-shape` tags. Shapes include source text, JSDoc, type parameters, and property documentation', + 'Shape extraction: TypeScript shapes (`interface`, `type`, `enum`, `function`, `const`) are extracted by declaration-level `@architect-shape` tags. Shapes include source text, JSDoc, type parameters, and property documentation', 'Generator registration: Generators self-register via `registerGenerator()`. The orchestrator runs them in registration order. Each generator owns its output files and codec configuration', ], keyPatterns: [ @@ -465,7 +465,7 @@ export const PRODUCT_AREA_META: Readonly> = { 'directed graph, the Process Guard orchestrates commit-time validation using a Decider pattern ' + '(state derived from annotations, not stored separately), and the lint engine provides pluggable ' + 'rule execution with pretty and JSON output. Anti-pattern detection enforces dual-source ownership ' + - 'boundaries — `@libar-docs-uses` belongs on TypeScript, `@libar-docs-depends-on` belongs on Gherkin — ' + + 'boundaries — `@architect-uses` belongs on TypeScript, `@architect-depends-on` belongs on Gherkin — ' + 'preventing cross-domain tag confusion that causes documentation drift. Definition of Done validation ' + 'ensures completed patterns have all deliverables marked done and at least one acceptance-criteria scenario.', diagramScopes: [ @@ -481,7 +481,7 @@ export const PRODUCT_AREA_META: Readonly> = { }, ], keyInvariants: [ - 'Protection levels: `roadmap`/`deferred` = none (fully editable), `active` = scope-locked (no new deliverables), `completed` = hard-locked (requires `@libar-docs-unlock-reason`)', + 'Protection levels: `roadmap`/`deferred` = none (fully editable), `active` = scope-locked (no new deliverables), `completed` = hard-locked (requires `@architect-unlock-reason`)', 'Valid FSM transitions: Only roadmap→active, roadmap→deferred, active→completed, active→roadmap, deferred→roadmap. Completed is terminal', 'Decider pattern: All validation is (state, changes, options) → result. State is derived from annotations, not maintained separately', 'Dual-source ownership: Anti-pattern detection enforces tag boundaries — `uses` on TypeScript (runtime deps), `depends-on`/`quarter`/`team` on Gherkin (planning metadata). Violations are flagged before they cause documentation drift', @@ -578,7 +578,7 @@ export const PRODUCT_AREA_META: Readonly> = { }, ], keyInvariants: [ - 'TypeScript source owns pattern identity: `@libar-docs-pattern` in TypeScript defines the pattern. Tier 1 specs are ephemeral working documents', + 'TypeScript source owns pattern identity: `@architect-pattern` in TypeScript defines the pattern. Tier 1 specs are ephemeral working documents', '7 canonical product-area values: Annotation, Configuration, Generation, Validation, DataAPI, CoreTypes, Process — reader-facing sections, not source modules', 'Two distinct status domains: Pattern FSM status (4 values) vs. deliverable status (6 values). Never cross domains', 'Session types define capabilities: planning creates specs, design creates stubs, implementation writes code. Each session type has a fixed input/output contract enforced by convention', diff --git a/src/renderable/codecs/reporting.ts b/src/renderable/codecs/reporting.ts index 739eedaf..02e15549 100644 --- a/src/renderable/codecs/reporting.ts +++ b/src/renderable/codecs/reporting.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern ReportingCodecs - * @libar-docs-status completed - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern ReportingCodecs + * @architect-status completed + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## ChangelogCodec * @@ -480,7 +480,7 @@ function buildOverviewDocument( ): RenderableDocument { const sections: SectionBlock[] = []; - // Architecture overview from @libar-docs-overview patterns + // Architecture overview from @architect-overview patterns if (options.includeArchitecture) { const overviewPatterns = dataset.patterns.filter((p) => p.directive.tags.some( diff --git a/src/renderable/codecs/requirements.ts b/src/renderable/codecs/requirements.ts index 67d97272..4c9839fe 100644 --- a/src/renderable/codecs/requirements.ts +++ b/src/renderable/codecs/requirements.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern RequirementsCodec - * @libar-docs-status completed - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern RequirementsCodec + * @architect-status completed + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## RequirementsDocumentCodec * @@ -591,7 +591,7 @@ function buildSingleRequirementDocument( sections.push(heading(2, 'Deliverables'), list(deliverableItems)); } - // Implementations (files that implement this pattern via @libar-docs-implements) + // Implementations (files that implement this pattern via @architect-implements) const patternKey = getPatternName(pattern); const rel = dataset.relationshipIndex?.[patternKey]; if (rel?.implementedBy && rel.implementedBy.length > 0) { diff --git a/src/renderable/codecs/session.ts b/src/renderable/codecs/session.ts index b78d09c3..8983019e 100644 --- a/src/renderable/codecs/session.ts +++ b/src/renderable/codecs/session.ts @@ -1,14 +1,14 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern SessionCodec - * @libar-docs-status completed - * @libar-docs-arch-role projection - * @libar-docs-arch-context renderer - * @libar-docs-arch-layer application - * @libar-docs-include codec-transformation - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern SessionCodec + * @architect-status completed + * @architect-arch-role projection + * @architect-arch-context renderer + * @architect-arch-layer application + * @architect-include codec-transformation + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## SessionContextCodec * diff --git a/src/renderable/codecs/shared-schema.ts b/src/renderable/codecs/shared-schema.ts index f1af5ba8..9348570d 100644 --- a/src/renderable/codecs/shared-schema.ts +++ b/src/renderable/codecs/shared-schema.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern SharedCodecSchema - * @libar-docs-status completed + * @architect + * @architect-core + * @architect-pattern SharedCodecSchema + * @architect-status completed * * ## Shared Codec Output Schema * diff --git a/src/renderable/codecs/taxonomy.ts b/src/renderable/codecs/taxonomy.ts index 2870caed..be08db51 100644 --- a/src/renderable/codecs/taxonomy.ts +++ b/src/renderable/codecs/taxonomy.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern TaxonomyCodec - * @libar-docs-status completed - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern TaxonomyCodec + * @architect-status completed + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## TaxonomyDocumentCodec * @@ -422,18 +422,18 @@ function buildAggregationTagsSection(tagRegistry: TagRegistry): SectionBlock[] { */ function buildFormatTypesSection(options: Required): SectionBlock[] { const formatDescriptions: Record = { - value: { description: 'Simple string value', example: '@libar-docs-pattern MyPattern' }, + value: { description: 'Simple string value', example: '@architect-pattern MyPattern' }, enum: { description: 'Constrained to predefined values', - example: '@libar-docs-status roadmap', + example: '@architect-status roadmap', }, 'quoted-value': { description: 'String in quotes (preserves spaces)', - example: '@libar-docs-usecase "When X happens"', + example: '@architect-usecase "When X happens"', }, - csv: { description: 'Comma-separated values', example: '@libar-docs-uses A, B, C' }, - number: { description: 'Numeric value', example: '@libar-docs-phase 14' }, - flag: { description: 'Boolean presence (no value)', example: '@libar-docs-core' }, + csv: { description: 'Comma-separated values', example: '@architect-uses A, B, C' }, + number: { description: 'Numeric value', example: '@architect-phase 14' }, + flag: { description: 'Boolean presence (no value)', example: '@architect-core' }, }; const rows = FORMAT_TYPES.map((format) => { @@ -471,7 +471,7 @@ function buildPresetsSection(): SectionBlock[] { useCase = 'Simple projects with @docs- prefix'; break; case 'libar-generic': - useCase = 'Default preset with @libar-docs- prefix'; + useCase = 'Default preset with @architect- prefix'; break; case 'ddd-es-cqrs': useCase = 'Full DDD/ES/CQRS taxonomy'; @@ -674,37 +674,37 @@ function buildFormatTypesDetailDocument(): RenderableDocument { value: { description: 'Simple string value', parsingBehavior: 'Captures everything after the tag name as the value', - example: '@libar-docs-pattern CommandOrchestrator', + example: '@architect-pattern CommandOrchestrator', notes: 'Most common format for single-value tags', }, enum: { description: 'Constrained to predefined values', parsingBehavior: 'Validates value against allowed list; rejects invalid values', - example: '@libar-docs-status roadmap', + example: '@architect-status roadmap', notes: 'Used for FSM states, priority levels, risk levels', }, 'quoted-value': { description: 'String in quotes (preserves spaces)', parsingBehavior: 'Extracts content between quotes; preserves internal whitespace', - example: '@libar-docs-usecase "When a user submits a form"', + example: '@architect-usecase "When a user submits a form"', notes: 'Use for human-readable text with spaces', }, csv: { description: 'Comma-separated values', parsingBehavior: 'Splits on commas; trims whitespace from each value', - example: '@libar-docs-uses CommandBus, EventStore, Projection', + example: '@architect-uses CommandBus, EventStore, Projection', notes: 'Used for relationship tags and multi-value references', }, number: { description: 'Numeric value', parsingBehavior: 'Parses as integer; NaN if invalid', - example: '@libar-docs-phase 14', + example: '@architect-phase 14', notes: 'Used for phase numbers and ordering', }, flag: { description: 'Boolean presence (no value needed)', parsingBehavior: 'Presence of tag indicates true; absence indicates false', - example: '@libar-docs-core', + example: '@architect-core', notes: 'Used for boolean markers like core, overview, decision', }, }; diff --git a/src/renderable/codecs/timeline.ts b/src/renderable/codecs/timeline.ts index 4ba2daa7..aa9bbb7a 100644 --- a/src/renderable/codecs/timeline.ts +++ b/src/renderable/codecs/timeline.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern TimelineCodec - * @libar-docs-status completed - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern TimelineCodec + * @architect-status completed + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## RoadmapDocumentCodec * diff --git a/src/renderable/codecs/types/base.ts b/src/renderable/codecs/types/base.ts index 2801e7af..784b9ea2 100644 --- a/src/renderable/codecs/types/base.ts +++ b/src/renderable/codecs/types/base.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern CodecBaseOptions - * @libar-docs-status completed + * @architect + * @architect-core + * @architect-pattern CodecBaseOptions + * @architect-status completed * * ## Base Codec Options * diff --git a/src/renderable/codecs/validation-rules.ts b/src/renderable/codecs/validation-rules.ts index 5910a6f0..21335712 100644 --- a/src/renderable/codecs/validation-rules.ts +++ b/src/renderable/codecs/validation-rules.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern ValidationRulesCodec - * @libar-docs-status completed - * @libar-docs-convention codec-registry - * @libar-docs-product-area:Generation + * @architect + * @architect-core + * @architect-pattern ValidationRulesCodec + * @architect-status completed + * @architect-convention codec-registry + * @architect-product-area:Generation * * ## ValidationRulesCodec * @@ -136,8 +136,8 @@ export const RULE_DEFINITIONS: readonly RuleDefinition[] = [ id: 'completed-protection', severity: 'error', description: 'Completed specs require unlock-reason tag to modify', - cause: 'File has `completed` status but no `@libar-docs-unlock-reason` tag', - fix: "Add `@libar-docs-unlock-reason:'your reason'` to proceed", + cause: 'File has `completed` status but no `@architect-unlock-reason` tag', + fix: "Add `@architect-unlock-reason:'your reason'` to proceed", }, { id: 'invalid-status-transition', @@ -179,7 +179,7 @@ export const RULE_DEFINITIONS: readonly RuleDefinition[] = [ /** * Compose rationale from convention-extracted content into rule definitions. * - * Convention bundles extracted from `@libar-docs-convention process-guard-errors` + * Convention bundles extracted from `@architect-convention process-guard-errors` * annotations contain per-rule sections with **Invariant:** and **Rationale:** * markers plus situation/solution tables. * @@ -493,7 +493,7 @@ function buildEscapeHatchesSection(): SectionBlock[] { [ 'Fix bug in completed spec', 'Add unlock reason tag', - "`@libar-docs-unlock-reason:'Fix-typo'`", + "`@architect-unlock-reason:'Fix-typo'`", ], [ 'Modify outside session scope', @@ -581,7 +581,7 @@ function buildFSMTransitionsDetailDocument(): RenderableDocument { if ((targets as readonly string[]).length === 0) { sections.push( paragraph( - `**Terminal state** - no valid transitions. Use \`@libar-docs-unlock-reason\` to modify.` + `**Terminal state** - no valid transitions. Use \`@architect-unlock-reason\` to modify.` ) ); } else { diff --git a/src/renderable/generate.ts b/src/renderable/generate.ts index c6a09cb0..35a20537 100644 --- a/src/renderable/generate.ts +++ b/src/renderable/generate.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern DocumentGenerator - * @libar-docs-status completed - * @libar-docs-arch-role service - * @libar-docs-arch-context renderer - * @libar-docs-arch-layer application + * @architect + * @architect-core + * @architect-pattern DocumentGenerator + * @architect-status completed + * @architect-arch-role service + * @architect-arch-context renderer + * @architect-arch-layer application * * ## Document Generation * diff --git a/src/renderable/index.ts b/src/renderable/index.ts index 29f6e86d..87da9b95 100644 --- a/src/renderable/index.ts +++ b/src/renderable/index.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern RenderableDocumentModel(RDM) - * @libar-docs-status completed + * @architect + * @architect-core + * @architect-pattern RenderableDocumentModel(RDM) + * @architect-status completed * * ## Renderable Document Model (RDM) * diff --git a/src/renderable/load-preamble.ts b/src/renderable/load-preamble.ts index 3066e278..e8ada621 100644 --- a/src/renderable/load-preamble.ts +++ b/src/renderable/load-preamble.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-implements ProceduralGuideCodec - * @libar-docs-arch-context renderer - * @libar-docs-arch-layer domain + * @architect + * @architect-implements ProceduralGuideCodec + * @architect-arch-context renderer + * @architect-arch-layer domain * * ## loadPreambleFromMarkdown — Shared Markdown-to-SectionBlock Parser * @@ -16,7 +16,7 @@ * * ### When to Use * - * - In `delivery-process.config.ts` to load preamble markdown files + * - In `architect.config.ts` to load preamble markdown files * - At config import time (before any codec `decode()` call) * - When any codec needs static SectionBlock[] from a `.md` file */ diff --git a/src/renderable/render.ts b/src/renderable/render.ts index d2cf1a67..46831d10 100644 --- a/src/renderable/render.ts +++ b/src/renderable/render.ts @@ -1,11 +1,11 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern UniversalRenderer - * @libar-docs-status completed - * @libar-docs-arch-role service - * @libar-docs-arch-context renderer - * @libar-docs-arch-layer application + * @architect + * @architect-core + * @architect-pattern UniversalRenderer + * @architect-status completed + * @architect-arch-role service + * @architect-arch-context renderer + * @architect-arch-layer application * * ## Universal Renderer * diff --git a/src/renderable/schema.ts b/src/renderable/schema.ts index 82b5be0c..a59832c9 100644 --- a/src/renderable/schema.ts +++ b/src/renderable/schema.ts @@ -1,12 +1,12 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern RenderableDocument - * @libar-docs-status completed - * @libar-docs-extract-shapes RenderableDocument, SectionBlock, HeadingBlock, TableBlock, ListBlock, CodeBlock, MermaidBlock, CollapsibleBlock - * @libar-docs-arch-role read-model - * @libar-docs-arch-context renderer - * @libar-docs-arch-layer domain + * @architect + * @architect-core + * @architect-pattern RenderableDocument + * @architect-status completed + * @architect-extract-shapes RenderableDocument, SectionBlock, HeadingBlock, TableBlock, ListBlock, CodeBlock, MermaidBlock, CollapsibleBlock + * @architect-arch-role read-model + * @architect-arch-context renderer + * @architect-arch-layer domain * * ## RenderableDocument Schema * @@ -182,8 +182,8 @@ export type CollapsibleBlock = { export type LinkOutBlock = z.infer; /** - * @libar-docs-implements RenderableDocument - * @libar-docs-shape reference-sample + * @architect-implements RenderableDocument + * @architect-shape reference-sample */ export type SectionBlock = | HeadingBlock diff --git a/src/renderable/utils.ts b/src/renderable/utils.ts index ed0491ff..397820f6 100644 --- a/src/renderable/utils.ts +++ b/src/renderable/utils.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern RenderableUtils - * @libar-docs-status completed + * @architect + * @architect-core + * @architect-pattern RenderableUtils + * @architect-status completed * * ## Renderable Utilities * diff --git a/src/scanner/ast-parser.ts b/src/scanner/ast-parser.ts index ca31b5bf..8ef3441f 100644 --- a/src/scanner/ast-parser.ts +++ b/src/scanner/ast-parser.ts @@ -1,20 +1,20 @@ /** - * @libar-docs - * @libar-docs-core @libar-docs-scanner - * @libar-docs-pattern TypeScript AST Parser - * @libar-docs-status completed - * @libar-docs-arch-role infrastructure - * @libar-docs-arch-context scanner - * @libar-docs-arch-layer infrastructure - * @libar-docs-uses TagRegistry, DocDirectiveSchema, typescript-estree - * @libar-docs-used-by Pattern Scanner, Doc Extractor - * @libar-docs-usecase "When parsing JSDoc comments for @libar-docs-* directives" - * @libar-docs-usecase "When extracting code blocks following documentation comments" + * @architect + * @architect-core @architect-scanner + * @architect-pattern TypeScript AST Parser + * @architect-status completed + * @architect-arch-role infrastructure + * @architect-arch-context scanner + * @architect-arch-layer infrastructure + * @architect-uses TagRegistry, DocDirectiveSchema, typescript-estree + * @architect-used-by Pattern Scanner, Doc Extractor + * @architect-usecase "When parsing JSDoc comments for @architect-* directives" + * @architect-usecase "When extracting code blocks following documentation comments" * * ## TypeScript AST Parser - JSDoc Directive Extraction * * Parses TypeScript source files using @typescript-eslint/typescript-estree - * to extract @libar-docs-* directives with their associated code blocks. + * to extract @architect-* directives with their associated code blocks. * First stage of the three-stage pipeline: Scanner → Extractor → Generator. * * ### When to Use @@ -105,7 +105,7 @@ export interface ParseDirectivesResult { * * @example * ``` - * @libar-docs-pattern MyPattern + * @architect-pattern MyPattern * ``` */ function extractSingleValue(commentText: string, fullTag: string): string | undefined { @@ -121,7 +121,7 @@ function extractSingleValue(commentText: string, fullTag: string): string | unde * * @example * ``` - * @libar-docs-status completed + * @architect-status completed * ``` */ function extractEnumValue( @@ -140,7 +140,7 @@ function extractEnumValue( * * @example * ``` - * @libar-docs-usecase "When implementing a new command" + * @architect-usecase "When implementing a new command" * ``` */ function extractQuotedValue(commentText: string, fullTag: string): string[] { @@ -164,7 +164,7 @@ function extractQuotedValue(commentText: string, fullTag: string): string[] { * * @example * ``` - * @libar-docs-uses PatternA, PatternB, PatternC + * @architect-uses PatternA, PatternB, PatternC * ``` */ function extractCsvValue(commentText: string, fullTag: string): string[] | undefined { @@ -183,7 +183,7 @@ function extractCsvValue(commentText: string, fullTag: string): string[] | undef * * @example * ``` - * @libar-docs-phase 14 + * @architect-phase 14 * ``` */ function extractNumberValue(commentText: string, fullTag: string): number | undefined { @@ -197,7 +197,7 @@ function extractNumberValue(commentText: string, fullTag: string): number | unde * * @example * ``` - * @libar-docs-core + * @architect-core * ``` */ function checkFlagPresent(commentText: string, fullTag: string): boolean { @@ -221,11 +221,11 @@ function escapeRegex(str: string): string { * @internal */ function buildDirectivePatterns(registry: TagRegistry): { - /** Matches directive tags (e.g., @libar-docs-pattern, @docs-core) */ + /** Matches directive tags (e.g., @architect-pattern, @docs-core) */ readonly tagRegex: RegExp; /** Matches start of line with opt-in or directive */ readonly startsWithOptInOrDirective: RegExp; - /** Matches opt-in tag for removal (e.g., @libar-docs without suffix) */ + /** Matches opt-in tag for removal (e.g., @architect without suffix) */ readonly optInTagPattern: RegExp; /** Matches any non-opt-in @ tag (negative lookahead for registry prefix) */ readonly nonOptInAtTagPattern: RegExp; @@ -247,15 +247,15 @@ function buildDirectivePatterns(registry: TagRegistry): { tagRegex: new RegExp(`@${escapedPrefixWithoutAt}[\\w-]+`, 'g'), // Check if line starts with opt-in or directive - // e.g., ^@libar-docs or ^@libar-docs-pattern + // e.g., ^@architect or ^@architect-pattern startsWithOptInOrDirective: new RegExp(`^@${escapedOptInWithoutAt}(?:-[\\w-]+)?`), // Match opt-in tag for removal (not followed by -) - // e.g., @libar-docs followed by whitespace or end + // e.g., @architect followed by whitespace or end optInTagPattern: new RegExp(`@${escapedOptInWithoutAt}(?!-)(\\s|$)?`, 'g'), // Match any @ tag that is NOT our prefix - // e.g., @param, @returns, @example (not @libar-docs) + // e.g., @param, @returns, @example (not @architect) nonOptInAtTagPattern: new RegExp(`^@(?!${escapedOptInWithoutAt})`), }; } @@ -288,8 +288,8 @@ function buildValueTakingTagsPattern(registry: TagRegistry): string { * 1. Avoid regex compilation on every parse call * 2. Eliminate hardcoded tag lists that fall out of sync with registry * - * Matches lines containing tags like @libar-docs-pattern, @libar-docs-status, etc. - * Does NOT match flag-only tags like @libar-docs-core. + * Matches lines containing tags like @architect-pattern, @architect-status, etc. + * Does NOT match flag-only tags like @architect-core. * * @internal */ @@ -306,7 +306,7 @@ const _VALUE_TAKING_TAGS_REGEX: RegExp = (() => { * * @param commentText - Full JSDoc comment text * @param tagDef - Metadata tag definition from registry - * @param prefix - Tag prefix (e.g., "@libar-docs-") + * @param prefix - Tag prefix (e.g., "@architect-") * @returns Extracted value in appropriate format, or undefined if not found */ function extractMetadataTag( @@ -348,7 +348,7 @@ function extractMetadataTag( } /** - * Parses TypeScript content and extracts all @libar-docs-* directives + * Parses TypeScript content and extracts all @architect-* directives * with their associated code blocks and exports. * * **Error Handling**: Returns Result type to surface parse errors: @@ -455,18 +455,18 @@ export function parseFileDirectives( * **Schema-First Enforcement**: Validates constructed directive against schema * to ensure data integrity at the boundary. * - * **Directive-Level Tag Extraction**: Only extracts `@libar-docs-*` tags from + * **Directive-Level Tag Extraction**: Only extracts `@architect-*` tags from * the directive section (first lines before description content). Tags mentioned * in descriptions, examples, or other sections are NOT extracted. * * JSDoc structure: * ``` * /** - * * @libar-docs-core @libar-docs-api <- Directive tags (extracted) + * * @architect-core @architect-api <- Directive tags (extracted) * * - * * Description mentioning @libar-docs-x <- NOT extracted + * * Description mentioning @architect-x <- NOT extracted * * @example - * * hasTag('@libar-docs-y'); <- NOT extracted + * * hasTag('@architect-y'); <- NOT extracted * *\/ * ``` */ @@ -484,8 +484,8 @@ function parseDirective( // Extract directive tags ONLY from directive section // Directive section = lines where tags appear at the START (not mentioned in text) - // A directive tag line: "@libar-docs-core @libar-docs-api Some brief description" - // A description line: "This works with @libar-docs-api patterns" (tag not at start) + // A directive tag line: "@architect-core @architect-api Some brief description" + // A description line: "This works with @architect-api patterns" (tag not at start) const tags: string[] = []; let inlineDescription = ''; // Capture description on same line as tags @@ -505,14 +505,14 @@ function parseDirective( } // Check if line STARTS with opt-in or directive tag - // e.g., @libar-docs (no suffix) = file opt-in tag - // e.g., @libar-docs-* (with suffix) = section tag to extract + // e.g., @architect (no suffix) = file opt-in tag + // e.g., @architect-* (with suffix) = section tag to extract const startsWithDocTag = patterns.startsWithOptInOrDirective.exec(trimmedLine); if (startsWithDocTag) { // This is a directive line - extract only directive tags (with suffix) // Skip opt-in tag (no suffix) which is just the opt-in marker - // e.g., "@libar-docs @libar-docs-core Brief description" extracts only @libar-docs-core + // e.g., "@architect @architect-core Brief description" extracts only @architect-core let match; let lastTagEnd = 0; patterns.tagRegex.lastIndex = 0; @@ -531,10 +531,10 @@ function parseDirective( } // Capture any description text after the tags on the same line - // e.g., "@libar-docs-core Brief description on same line" -> "Brief description on same line" + // e.g., "@architect-core Brief description on same line" -> "Brief description on same line" // But skip lines with metadata directives that take values (all non-flag tags) // to prevent their values from leaking into the description - // (e.g., "@libar-docs-phase 01" would incorrectly capture "01") + // (e.g., "@architect-phase 01" would incorrectly capture "01") const hasMetadataDirective = valueTakingTagsRegex.test(trimmedLine); if (!hasMetadataDirective) { const textAfterTags = trimmedLine @@ -934,7 +934,7 @@ function getExportType(declaration: TSESTree.Node): ExportInfo['type'] { * Recommendation: Keep all bullet points as single lines. * * @param commentText - Raw JSDoc comment content - * @param fileOptInTag - The file opt-in tag (e.g., "@docs" or "@libar-docs") + * @param fileOptInTag - The file opt-in tag (e.g., "@docs" or "@architect") * @returns Array of bullet point strings, or undefined if no "When to Use" section */ function extractWhenToUse( diff --git a/src/scanner/gherkin-ast-parser.ts b/src/scanner/gherkin-ast-parser.ts index 36c1b4e3..dc301d00 100644 --- a/src/scanner/gherkin-ast-parser.ts +++ b/src/scanner/gherkin-ast-parser.ts @@ -1,14 +1,14 @@ /** - * @libar-docs - * @libar-docs-scanner - * @libar-docs-pattern GherkinASTParser - * @libar-docs-status completed - * @libar-docs-implements GherkinRulesSupport - * @libar-docs-uses GherkinTypes - * @libar-docs-used-by GherkinScanner - * @libar-docs-arch-role infrastructure - * @libar-docs-arch-context scanner - * @libar-docs-arch-layer infrastructure + * @architect + * @architect-scanner + * @architect-pattern GherkinASTParser + * @architect-status completed + * @architect-implements GherkinRulesSupport + * @architect-uses GherkinTypes + * @architect-used-by GherkinScanner + * @architect-arch-role infrastructure + * @architect-arch-context scanner + * @architect-arch-layer infrastructure * * ## GherkinASTParser - Parse Feature Files Using Cucumber Gherkin * @@ -100,12 +100,12 @@ function kebabToCamel(s: string): string { * Removes `@` prefix and then the configured tag prefix (from registry) * to produce a canonical tag name. * - * @param tag - Tag string to normalize (e.g., "@libar-docs-pattern:MyPattern") + * @param tag - Tag string to normalize (e.g., "@architect-pattern:MyPattern") * @param registry - Optional TagRegistry for custom prefix configuration * @returns Normalized tag name (e.g., "pattern:MyPattern") * * @example - * normalizeTag("@libar-docs-pattern:MyPattern") // "pattern:MyPattern" + * normalizeTag("@architect-pattern:MyPattern") // "pattern:MyPattern" * normalizeTag("@acceptance-criteria") // "acceptance-criteria" * * // With custom registry diff --git a/src/scanner/gherkin-scanner.ts b/src/scanner/gherkin-scanner.ts index 566167ff..f743b4be 100644 --- a/src/scanner/gherkin-scanner.ts +++ b/src/scanner/gherkin-scanner.ts @@ -1,14 +1,14 @@ /** - * @libar-docs - * @libar-docs-scanner - * @libar-docs-pattern GherkinScanner - * @libar-docs-status completed - * @libar-docs-implements GherkinRulesSupport - * @libar-docs-uses GherkinASTParser, GherkinTypes - * @libar-docs-used-by DualSourceExtractor, Orchestrator - * @libar-docs-arch-role infrastructure - * @libar-docs-arch-context scanner - * @libar-docs-arch-layer infrastructure + * @architect + * @architect-scanner + * @architect-pattern GherkinScanner + * @architect-status completed + * @architect-implements GherkinRulesSupport + * @architect-uses GherkinASTParser, GherkinTypes + * @architect-used-by DualSourceExtractor, Orchestrator + * @architect-arch-role infrastructure + * @architect-arch-context scanner + * @architect-arch-layer infrastructure * * ## GherkinScanner - Multi-Source Pattern Extraction from Feature Files * diff --git a/src/scanner/index.ts b/src/scanner/index.ts index db38fba3..675a437e 100644 --- a/src/scanner/index.ts +++ b/src/scanner/index.ts @@ -56,7 +56,7 @@ export interface ScanResults { } /** - * Scans source files for @libar-docs-* directives and extracts them + * Scans source files for @architect-* directives and extracts them * with their associated code blocks and export information. * * **Result Pattern**: Returns Result where: diff --git a/src/scanner/pattern-scanner.ts b/src/scanner/pattern-scanner.ts index c3ba9d36..c5dc98b6 100644 --- a/src/scanner/pattern-scanner.ts +++ b/src/scanner/pattern-scanner.ts @@ -1,21 +1,21 @@ /** - * @libar-docs - * @libar-docs-core @libar-docs-scanner - * @libar-docs-pattern Pattern Scanner - * @libar-docs-status completed - * @libar-docs-arch-role infrastructure - * @libar-docs-arch-context scanner - * @libar-docs-arch-layer infrastructure - * @libar-docs-include pipeline-stages - * @libar-docs-uses glob, AST Parser - * @libar-docs-used-by Doc Extractor, Orchestrator - * @libar-docs-usecase "When discovering TypeScript files for documentation extraction" - * @libar-docs-usecase "When filtering files by @libar-docs opt-in marker" + * @architect + * @architect-core @architect-scanner + * @architect-pattern Pattern Scanner + * @architect-status completed + * @architect-arch-role infrastructure + * @architect-arch-context scanner + * @architect-arch-layer infrastructure + * @architect-include pipeline-stages + * @architect-uses glob, AST Parser + * @architect-used-by Doc Extractor, Orchestrator + * @architect-usecase "When discovering TypeScript files for documentation extraction" + * @architect-usecase "When filtering files by @architect opt-in marker" * * ## Pattern Scanner - File Discovery and Directive Detection * * Discovers TypeScript files matching glob patterns and filters to only - * those with `@libar-docs` opt-in. Entry point for the scanning phase. + * those with `@architect` opt-in. Entry point for the scanning phase. * * ### When to Use * @@ -25,7 +25,7 @@ * * ### Key Concepts * - * - **Opt-in Model**: Files must explicitly declare `@libar-docs` to be processed + * - **Opt-in Model**: Files must explicitly declare `@architect` to be processed * - **Glob Patterns**: Uses glob for flexible file matching * - **Exclusion Support**: Configurable exclude patterns for node_modules, tests, etc. */ @@ -66,9 +66,9 @@ export async function findFilesToScan(config: ScannerConfig): Promise * * Per PDR-005: deferred items are treated as planned (not actively worked on) * - * @libar-docs-shape reference-sample + * @architect-shape reference-sample * @param status - Raw status from pattern (case-insensitive) * @returns "completed" | "active" | "planned" * diff --git a/src/taxonomy/registry-builder.ts b/src/taxonomy/registry-builder.ts index 77a698e2..540e0ca8 100644 --- a/src/taxonomy/registry-builder.ts +++ b/src/taxonomy/registry-builder.ts @@ -1,18 +1,18 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern TagRegistryBuilder - * @libar-docs-status completed - * @libar-docs-arch-role service - * @libar-docs-arch-context taxonomy - * @libar-docs-arch-layer domain - * @libar-docs-implements TypeScriptTaxonomyImplementation - * @libar-docs-extract-shapes TagRegistry, MetadataTagDefinitionForRegistry, TagDefinition, buildRegistry, METADATA_TAGS_BY_GROUP + * @architect + * @architect-core + * @architect-pattern TagRegistryBuilder + * @architect-status completed + * @architect-arch-role service + * @architect-arch-context taxonomy + * @architect-arch-layer domain + * @architect-implements TypeScriptTaxonomyImplementation + * @architect-extract-shapes TagRegistry, MetadataTagDefinitionForRegistry, TagDefinition, buildRegistry, METADATA_TAGS_BY_GROUP * * ## Tag Registry Builder * * Constructs a complete TagRegistry from TypeScript constants. - * Provides the default tag definitions for the delivery-process annotation system. + * Provides the default tag definitions for the Architect annotation system. * * ### When to Use * @@ -51,9 +51,9 @@ export interface TagRegistry { aggregationTags: readonly AggregationTagDefinitionForRegistry[]; /** Available format options for documentation output */ formatOptions: readonly string[]; - /** Prefix for all tags (e.g., "@libar-docs-") */ + /** Prefix for all tags (e.g., "@architect-") */ tagPrefix: string; - /** File-level opt-in marker tag (e.g., "@libar-docs") */ + /** File-level opt-in marker tag (e.g., "@architect") */ fileOptInTag: string; } @@ -85,7 +85,7 @@ export interface MetadataTagDefinitionForRegistry { values?: readonly string[]; /** Default value applied when tag is not specified */ default?: string; - /** Example usage showing tag syntax (e.g., "@libar-docs-pattern MyPattern") */ + /** Example usage showing tag syntax (e.g., "@architect-pattern MyPattern") */ example?: string; /** Maps tag name to metadata object property name (defaults to kebab-to-camelCase) */ metadataKey?: string; @@ -200,7 +200,7 @@ export function buildRegistry(): TagRegistry { format: 'value', purpose: 'Explicit pattern name', required: true, - example: '@libar-docs-pattern CommandOrchestrator', + example: '@architect-pattern CommandOrchestrator', }, { tag: 'status', @@ -208,62 +208,62 @@ export function buildRegistry(): TagRegistry { purpose: 'Work item lifecycle status (per PDR-005 FSM)', values: [...ACCEPTED_STATUS_VALUES], // Includes legacy values for extraction default: DEFAULT_STATUS, - example: '@libar-docs-status roadmap', + example: '@architect-status roadmap', }, { tag: 'core', format: 'flag', purpose: 'Marks as essential/must-know pattern', - example: '@libar-docs-core', + example: '@architect-core', }, { tag: 'usecase', format: 'quoted-value', purpose: 'Use case association', repeatable: true, - example: '@libar-docs-usecase "When handling command failures"', + example: '@architect-usecase "When handling command failures"', }, { tag: 'uses', format: 'csv', purpose: 'Patterns this depends on', - example: '@libar-docs-uses CommandBus, EventStore', + example: '@architect-uses CommandBus, EventStore', }, { tag: 'used-by', format: 'csv', purpose: 'Patterns that depend on this', - example: '@libar-docs-used-by SagaOrchestrator', + example: '@architect-used-by SagaOrchestrator', }, { tag: 'phase', format: 'number', purpose: 'Roadmap phase number (unified across monorepo)', - example: '@libar-docs-phase 14', + example: '@architect-phase 14', }, { tag: 'release', format: 'value', purpose: 'Target release version (semver or vNEXT for unreleased work)', - example: '@libar-docs-release v0.1.0', + example: '@architect-release v0.1.0', }, { tag: 'brief', format: 'value', purpose: 'Path to pattern brief markdown', - example: '@libar-docs-brief docs/briefs/decider-pattern.md', + example: '@architect-brief docs/briefs/decider-pattern.md', }, { tag: 'depends-on', format: 'csv', purpose: 'Roadmap dependencies (pattern or phase names)', - example: '@libar-docs-depends-on EventStore, CommandBus', + example: '@architect-depends-on EventStore, CommandBus', }, { tag: 'enables', format: 'csv', purpose: 'Patterns this enables', - example: '@libar-docs-enables SagaOrchestrator, ProjectionBuilder', + example: '@architect-enables SagaOrchestrator, ProjectionBuilder', }, // Relationship tags for UML-inspired pattern modeling (PatternRelationshipModel) { @@ -271,84 +271,84 @@ export function buildRegistry(): TagRegistry { format: 'csv', purpose: 'Patterns this code file realizes (realization relationship)', metadataKey: 'implementsPatterns', - example: '@libar-docs-implements EventStoreDurability, IdempotentAppend', + example: '@architect-implements EventStoreDurability, IdempotentAppend', }, { tag: 'extends', format: 'value', purpose: 'Base pattern this pattern extends (generalization relationship)', metadataKey: 'extendsPattern', - example: '@libar-docs-extends ProjectionCategories', + example: '@architect-extends ProjectionCategories', }, { tag: 'quarter', format: 'value', purpose: 'Delivery quarter for timeline tracking', - example: '@libar-docs-quarter Q1-2026', + example: '@architect-quarter Q1-2026', }, { tag: 'completed', format: 'value', purpose: 'Completion date (YYYY-MM-DD format)', - example: '@libar-docs-completed 2026-01-08', + example: '@architect-completed 2026-01-08', }, { tag: 'effort', format: 'value', purpose: 'Estimated effort (4h, 2d, 1w format)', - example: '@libar-docs-effort 2d', + example: '@architect-effort 2d', }, { tag: 'effort-actual', format: 'value', purpose: 'Actual effort spent (4h, 2d, 1w format)', - example: '@libar-docs-effort-actual 3d', + example: '@architect-effort-actual 3d', }, { tag: 'team', format: 'value', purpose: 'Responsible team assignment', - example: '@libar-docs-team platform', + example: '@architect-team platform', }, { tag: 'workflow', format: 'enum', purpose: 'Workflow discipline for process tracking', values: [...WORKFLOW_VALUES], - example: '@libar-docs-workflow implementation', + example: '@architect-workflow implementation', }, { tag: 'risk', format: 'enum', purpose: 'Risk level for planning', values: [...RISK_LEVELS], - example: '@libar-docs-risk medium', + example: '@architect-risk medium', }, { tag: 'priority', format: 'enum', purpose: 'Priority level for roadmap ordering', values: [...PRIORITY_VALUES], - example: '@libar-docs-priority high', + example: '@architect-priority high', }, { tag: 'product-area', format: 'value', purpose: 'Product area for PRD grouping', - example: '@libar-docs-product-area PlatformCore', + example: '@architect-product-area PlatformCore', }, { tag: 'user-role', format: 'value', purpose: 'Target user persona for this feature', - example: '@libar-docs-user-role Developer', + example: '@architect-user-role Developer', }, { tag: 'business-value', format: 'value', purpose: 'Business value statement (hyphenated for tag format)', transform: hyphenToSpace, - example: '@libar-docs-business-value eliminates-event-replay-complexity', + example: '@architect-business-value eliminates-event-replay-complexity', }, { tag: 'constraint', @@ -357,14 +357,14 @@ export function buildRegistry(): TagRegistry { repeatable: true, metadataKey: 'constraints', transform: hyphenToSpace, - example: '@libar-docs-constraint requires-convex-backend', + example: '@architect-constraint requires-convex-backend', }, { tag: 'adr', format: 'value', purpose: 'ADR/PDR number for decision tracking', transform: padAdr, - example: '@libar-docs-adr 015', + example: '@architect-adr 015', }, { tag: 'adr-status', @@ -372,41 +372,41 @@ export function buildRegistry(): TagRegistry { purpose: 'ADR/PDR decision status', values: [...ADR_STATUS_VALUES], default: 'proposed', - example: '@libar-docs-adr-status accepted', + example: '@architect-adr-status accepted', }, { tag: 'adr-category', format: 'value', purpose: 'ADR/PDR category (architecture, process, tooling)', - example: '@libar-docs-adr-category architecture', + example: '@architect-adr-category architecture', }, { tag: 'adr-supersedes', format: 'value', purpose: 'ADR/PDR number this decision supersedes', transform: padAdr, - example: '@libar-docs-adr-supersedes 012', + example: '@architect-adr-supersedes 012', }, { tag: 'adr-superseded-by', format: 'value', purpose: 'ADR/PDR number that supersedes this decision', transform: padAdr, - example: '@libar-docs-adr-superseded-by 020', + example: '@architect-adr-superseded-by 020', }, { tag: 'adr-theme', format: 'enum', purpose: 'Theme grouping for related decisions (from synthesis)', values: [...ADR_THEME_VALUES], - example: '@libar-docs-adr-theme persistence', + example: '@architect-adr-theme persistence', }, { tag: 'adr-layer', format: 'enum', purpose: 'Evolutionary layer of the decision', values: [...ADR_LAYER_VALUES], - example: '@libar-docs-adr-layer foundation', + example: '@architect-adr-layer foundation', }, { tag: 'level', @@ -414,39 +414,39 @@ export function buildRegistry(): TagRegistry { purpose: 'Hierarchy level for epic->phase->task breakdown', values: [...HIERARCHY_LEVELS], default: DEFAULT_HIERARCHY_LEVEL, - example: '@libar-docs-level epic', + example: '@architect-level epic', }, { tag: 'parent', format: 'value', purpose: 'Parent pattern name in hierarchy (links tasks to phases, phases to epics)', - example: '@libar-docs-parent AggregateArchitecture', + example: '@architect-parent AggregateArchitecture', }, { tag: 'title', format: 'quoted-value', purpose: 'Human-readable display title (supports quoted values with spaces)', transform: stripQuotes, - example: '@libar-docs-title:"Process Guard Linter"', + example: '@architect-title:"Process Guard Linter"', }, // PDR-007: Two-Tier Spec Architecture traceability { tag: 'executable-specs', format: 'csv', purpose: 'Links roadmap spec to package executable spec locations (PDR-007)', - example: '@libar-docs-executable-specs platform-decider/tests/features/behavior', + example: '@architect-executable-specs platform-decider/tests/features/behavior', }, { tag: 'roadmap-spec', format: 'value', purpose: 'Links package spec back to roadmap pattern for traceability (PDR-007)', - example: '@libar-docs-roadmap-spec DeciderPattern', + example: '@architect-roadmap-spec DeciderPattern', }, { tag: 'behavior-file', format: 'value', purpose: 'Path to behavior test feature file for traceability', - example: '@libar-docs-behavior-file behavior/my-pattern.feature', + example: '@architect-behavior-file behavior/my-pattern.feature', }, // Session discovery findings (retrospective tags) { @@ -456,7 +456,7 @@ export function buildRegistry(): TagRegistry { repeatable: true, metadataKey: 'discoveredGaps', transform: hyphenToSpace, - example: '@libar-docs-discovered-gap missing-error-handling', + example: '@architect-discovered-gap missing-error-handling', }, { tag: 'discovered-improvement', @@ -465,7 +465,7 @@ export function buildRegistry(): TagRegistry { repeatable: true, metadataKey: 'discoveredImprovements', transform: hyphenToSpace, - example: '@libar-docs-discovered-improvement cache-invalidation', + example: '@architect-discovered-improvement cache-invalidation', }, { tag: 'discovered-risk', @@ -474,7 +474,7 @@ export function buildRegistry(): TagRegistry { repeatable: true, metadataKey: 'discoveredRisks', transform: hyphenToSpace, - example: '@libar-docs-discovered-risk data-loss-on-migration', + example: '@architect-discovered-risk data-loss-on-migration', }, { tag: 'discovered-learning', @@ -483,34 +483,34 @@ export function buildRegistry(): TagRegistry { repeatable: true, metadataKey: 'discoveredLearnings', transform: hyphenToSpace, - example: '@libar-docs-discovered-learning convex-mutation-limits', + example: '@architect-discovered-learning convex-mutation-limits', }, // Cross-reference and API navigation tags (PatternRelationshipModel enhancement) { tag: 'see-also', format: 'csv', purpose: 'Related patterns for cross-reference without dependency implication', - example: '@libar-docs-see-also AgentAsBoundedContext, CrossContextIntegration', + example: '@architect-see-also AgentAsBoundedContext, CrossContextIntegration', }, { tag: 'api-ref', format: 'csv', purpose: "File paths to implementation APIs (replaces 'See:' Markdown text in Rules)", - example: '@libar-docs-api-ref @libar-dev/platform-core/src/durability/outbox.ts', + example: '@architect-api-ref @libar-dev/platform-core/src/durability/outbox.ts', }, // Shape extraction for documentation generation (ADR-021) { tag: 'extract-shapes', format: 'csv', purpose: 'TypeScript type names to extract from this file for documentation', - example: '@libar-docs-extract-shapes DeciderInput, ValidationResult, ProcessViolation', + example: '@architect-extract-shapes DeciderInput, ValidationResult, ProcessViolation', }, // DD-1: Declaration-level shape tagging { tag: 'shape', format: 'value', purpose: 'Marks declaration as documentable shape, optionally with group name', - example: '@libar-docs-shape api-types', + example: '@architect-shape api-types', }, // Architecture diagram generation tags { @@ -529,39 +529,39 @@ export function buildRegistry(): TagRegistry { 'read-model', 'service', ] as const, - example: '@libar-docs-arch-role projection', + example: '@architect-arch-role projection', }, { tag: 'arch-context', format: 'value', purpose: 'Bounded context this component belongs to (for subgraph grouping)', - example: '@libar-docs-arch-context orders', + example: '@architect-arch-context orders', }, { tag: 'arch-layer', format: 'enum', purpose: 'Architectural layer for layered diagrams', values: ['domain', 'application', 'infrastructure'] as const, - example: '@libar-docs-arch-layer application', + example: '@architect-arch-layer application', }, { tag: 'include', format: 'csv', purpose: 'Cross-cutting document inclusion for content routing and diagram scoping', - example: '@libar-docs-include reference-sample,codec-system', + example: '@architect-include reference-sample,codec-system', }, // Design session stub metadata tags (DataAPIStubIntegration Phase B) { tag: 'target', format: 'value', purpose: 'Target implementation path for stub files', - example: '@libar-docs-target src/api/stub-resolver.ts', + example: '@architect-target src/api/stub-resolver.ts', }, { tag: 'since', format: 'value', purpose: 'Design session that created this pattern', - example: '@libar-docs-since DS-A', + example: '@architect-since DS-A', }, // Convention tags for reference document generation (CodecDrivenReferenceGeneration) { @@ -569,27 +569,27 @@ export function buildRegistry(): TagRegistry { format: 'csv', purpose: 'Convention domains for reference document generation from decision records', values: [...CONVENTION_VALUES], - example: '@libar-docs-convention fsm-rules, testing-policy', + example: '@architect-convention fsm-rules, testing-policy', }, // Claude module generation tags (ClaudeModuleGeneration Phase 25) { tag: 'claude-module', format: 'value', purpose: 'Module identifier for CLAUDE.md module generation (becomes filename)', - example: '@libar-docs-claude-module process-guard', + example: '@architect-claude-module process-guard', }, { tag: 'claude-section', format: 'enum', purpose: 'Target section directory in _claude-md/ for module output', values: [...CLAUDE_SECTION_VALUES], - example: '@libar-docs-claude-section delivery-process', + example: '@architect-claude-section delivery-process', }, { tag: 'claude-tags', format: 'csv', purpose: 'Variation filtering tags for modular-claude-md inclusion', - example: '@libar-docs-claude-tags core-mandatory, delivery-process', + example: '@architect-claude-tags core-mandatory, delivery-process', }, // ── Sequence diagram annotation tags (DesignReviewCodec) ────────── @@ -597,25 +597,25 @@ export function buildRegistry(): TagRegistry { tag: 'sequence-orchestrator', format: 'value', purpose: 'Identifies the coordinator module for sequence diagram generation', - example: '@libar-docs-sequence-orchestrator:init-cli', + example: '@architect-sequence-orchestrator:init-cli', }, { tag: 'sequence-step', format: 'number', purpose: 'Explicit execution ordering number for sequence diagram steps', - example: '@libar-docs-sequence-step:1', + example: '@architect-sequence-step:1', }, { tag: 'sequence-module', format: 'csv', purpose: 'Maps Rule to deliverable module(s) for sequence diagram participants', - example: '@libar-docs-sequence-module:detect-context', + example: '@architect-sequence-module:detect-context', }, { tag: 'sequence-error', format: 'flag', purpose: 'Marks scenario as error/alternative path in sequence diagram', - example: '@libar-docs-sequence-error', + example: '@architect-sequence-error', }, ], diff --git a/src/taxonomy/risk-levels.ts b/src/taxonomy/risk-levels.ts index 781c0d74..f1304252 100644 --- a/src/taxonomy/risk-levels.ts +++ b/src/taxonomy/risk-levels.ts @@ -1,9 +1,9 @@ /** - * @libar-docs - * @libar-docs-pattern RiskLevels - * @libar-docs-status completed - * @libar-docs-core - * @libar-docs-extract-shapes RISK_LEVELS, RiskLevel + * @architect + * @architect-pattern RiskLevels + * @architect-status completed + * @architect-core + * @architect-extract-shapes RISK_LEVELS, RiskLevel * * ## Risk Levels for Planning and Assessment * diff --git a/src/taxonomy/status-values.ts b/src/taxonomy/status-values.ts index 863de1ac..d632aa60 100644 --- a/src/taxonomy/status-values.ts +++ b/src/taxonomy/status-values.ts @@ -1,9 +1,9 @@ /** - * @libar-docs - * @libar-docs-pattern StatusValues - * @libar-docs-status completed - * @libar-docs-core - * @libar-docs-extract-shapes PROCESS_STATUS_VALUES, ProcessStatusValue, ACCEPTED_STATUS_VALUES, AcceptedStatusValue, DEFAULT_STATUS, VALID_PROCESS_STATUS_SET + * @architect + * @architect-pattern StatusValues + * @architect-status completed + * @architect-core + * @architect-extract-shapes PROCESS_STATUS_VALUES, ProcessStatusValue, ACCEPTED_STATUS_VALUES, AcceptedStatusValue, DEFAULT_STATUS, VALID_PROCESS_STATUS_SET * * ## Process Workflow Status Values * diff --git a/src/types/branded.ts b/src/types/branded.ts index 642b727a..8cf2716b 100644 --- a/src/types/branded.ts +++ b/src/types/branded.ts @@ -2,8 +2,8 @@ * Branded type helper * Creates nominal types for better compile-time safety * - * @libar-docs-shape - * @libar-docs-include core-types + * @architect-shape + * @architect-include core-types */ type Branded = T & { readonly __brand: Brand }; @@ -99,7 +99,7 @@ export function asRegistryFilePath(path: string): RegistryFilePath { /** * Directive tag name - * Format: @libar-docs-{category} or @libar-docs-{category}-{subcategory} + * Format: @architect-{category} or @architect-{category}-{subcategory} */ export type DirectiveTag = Branded; diff --git a/src/types/errors.ts b/src/types/errors.ts index b93ef5c6..4b8783f8 100644 --- a/src/types/errors.ts +++ b/src/types/errors.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern ErrorFactoryTypes - * @libar-docs-status completed - * @libar-docs-implements ErrorFactories - * @libar-docs-product-area CoreTypes + * @architect + * @architect-core + * @architect-pattern ErrorFactoryTypes + * @architect-status completed + * @architect-implements ErrorFactories + * @architect-product-area CoreTypes * * ## Error Factories - Type Definitions * @@ -19,8 +19,8 @@ import type { SourceFilePath } from './branded.js'; /** * Base error interface for all documentation errors * - * @libar-docs-shape - * @libar-docs-include core-types + * @architect-shape + * @architect-include core-types */ export interface BaseDocError { /** Error type discriminator for pattern matching */ @@ -52,7 +52,7 @@ export interface FileParseError extends BaseDocError { } /** - * Directive validation error - invalid @libar-docs-* format + * Directive validation error - invalid @architect-* format */ export interface DirectiveValidationError extends BaseDocError { readonly type: 'DIRECTIVE_VALIDATION_ERROR'; @@ -124,7 +124,7 @@ export interface ConfigError extends BaseDocError { } /** - * Process metadata validation error - invalid @libar-docs-* tag values + * Process metadata validation error - invalid @architect-* tag values * * Raised when extracting process metadata from Gherkin feature tags * and the values don't conform to ProcessMetadataSchema. @@ -172,8 +172,8 @@ export interface GherkinPatternValidationError extends BaseDocError { * - Type narrowing based on `type` field * - Compile-time verification of error handling * - * @libar-docs-shape - * @libar-docs-include core-types + * @architect-shape + * @architect-include core-types */ export type DocError = | FileSystemError @@ -312,7 +312,7 @@ export function createFileParseError( * 'src/utils.ts', * 42, * 'Missing required tags', - * '@libar-docs-' + * '@architect-' * ); * ``` */ diff --git a/src/types/index.ts b/src/types/index.ts index 0bbc83df..4ae70c8c 100644 --- a/src/types/index.ts +++ b/src/types/index.ts @@ -58,7 +58,7 @@ export { export type { Position } from '../validation-schemas/doc-directive.js'; /** - * Parsed @libar-docs-* directive from JSDoc comment + * Parsed @architect-* directive from JSDoc comment * Schema: validation-schemas/doc-directive.ts */ export type { DocDirective } from '../validation-schemas/doc-directive.js'; diff --git a/src/types/result.ts b/src/types/result.ts index 29990ee2..9fe5df80 100644 --- a/src/types/result.ts +++ b/src/types/result.ts @@ -1,10 +1,10 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern ResultMonadTypes - * @libar-docs-status completed - * @libar-docs-implements ResultMonad - * @libar-docs-product-area CoreTypes + * @architect + * @architect-core + * @architect-pattern ResultMonadTypes + * @architect-status completed + * @architect-implements ResultMonad + * @architect-product-area CoreTypes * * ## Result Monad - Type Definitions * @@ -27,8 +27,8 @@ export type Err = { ok: false; error: E }; /** * Result type representing either success (Ok) or failure (Err) * - * @libar-docs-shape - * @libar-docs-include core-types + * @architect-shape + * @architect-include core-types * @typeParam T - The success value type * @typeParam E - The error type (defaults to Error) */ diff --git a/src/utils/collection-utils.ts b/src/utils/collection-utils.ts index 5599de6c..172d44e9 100644 --- a/src/utils/collection-utils.ts +++ b/src/utils/collection-utils.ts @@ -1,9 +1,9 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern CollectionUtilities - * @libar-docs-status completed - * @libar-docs-used-by SectionRenderer, DocExtractor + * @architect + * @architect-core + * @architect-pattern CollectionUtilities + * @architect-status completed + * @architect-used-by SectionRenderer, DocExtractor * * ## CollectionUtilities - Array and Map Operations * diff --git a/src/utils/id-utils.ts b/src/utils/id-utils.ts index 10c021ea..655f1aea 100644 --- a/src/utils/id-utils.ts +++ b/src/utils/id-utils.ts @@ -1,9 +1,9 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern PatternIdGenerator - * @libar-docs-status completed - * @libar-docs-used-by DocExtractor, GherkinExtractor + * @architect + * @architect-core + * @architect-pattern PatternIdGenerator + * @architect-status completed + * @architect-used-by DocExtractor, GherkinExtractor * * ## Pattern ID Generator - Deterministic ID Generation * diff --git a/src/utils/index.ts b/src/utils/index.ts index 25d8c61c..28050fe2 100644 --- a/src/utils/index.ts +++ b/src/utils/index.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern UtilsModule - * @libar-docs-status completed - * @libar-docs-uses StringUtilities, CollectionUtilities + * @architect + * @architect-core + * @architect-pattern UtilsModule + * @architect-status completed + * @architect-uses StringUtilities, CollectionUtilities * * ## UtilsModule - Shared Utilities Barrel Export * - * Common helper functions used across the delivery-process package. + * Common helper functions used across the Architect package. * Provides text transformation and collection manipulation utilities. * * ### When to Use diff --git a/src/utils/string-utils.ts b/src/utils/string-utils.ts index 12176e15..8f1ce6d2 100644 --- a/src/utils/string-utils.ts +++ b/src/utils/string-utils.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-core - * @libar-docs-pattern StringUtilities - * @libar-docs-status completed - * @libar-docs-used-by DocExtractor, SectionRenderer + * @architect + * @architect-core + * @architect-pattern StringUtilities + * @architect-status completed + * @architect-used-by DocExtractor, SectionRenderer * * ## StringUtilities - Text Transformation Functions * - * Provides shared utilities for string manipulation used across the delivery-process package, + * Provides shared utilities for string manipulation used across the Architect package, * including slugification for URLs/filenames and Markdown formatting cleanup. * * ### When to Use diff --git a/src/validation-schemas/codec-utils.ts b/src/validation-schemas/codec-utils.ts index 491572a6..8fd782fc 100644 --- a/src/validation-schemas/codec-utils.ts +++ b/src/validation-schemas/codec-utils.ts @@ -1,12 +1,12 @@ /** - * @libar-docs - * @libar-docs-validation @libar-docs-core - * @libar-docs-pattern CodecUtils - * @libar-docs-status completed - * @libar-docs-uses Zod - * @libar-docs-used-by WorkflowLoader, Orchestrator - * @libar-docs-usecase "When loading JSON config files with type-safe validation" - * @libar-docs-usecase "When serializing typed objects to formatted JSON" + * @architect + * @architect-validation @architect-core + * @architect-pattern CodecUtils + * @architect-status completed + * @architect-uses Zod + * @architect-used-by WorkflowLoader, Orchestrator + * @architect-usecase "When loading JSON config files with type-safe validation" + * @architect-usecase "When serializing typed objects to formatted JSON" * * ## CodecUtils - Type-Safe JSON Codec Factories * diff --git a/src/validation-schemas/doc-directive.ts b/src/validation-schemas/doc-directive.ts index 572b6101..31eb33ba 100644 --- a/src/validation-schemas/doc-directive.ts +++ b/src/validation-schemas/doc-directive.ts @@ -1,19 +1,19 @@ /** - * @libar-docs - * @libar-docs-validation - * @libar-docs-pattern DocDirectiveSchema - * @libar-docs-status completed - * @libar-docs-implements MvpWorkflowImplementation - * @libar-docs-used-by DocExtractor, ExtractedPatternSchema + * @architect + * @architect-validation + * @architect-pattern DocDirectiveSchema + * @architect-status completed + * @architect-implements MvpWorkflowImplementation + * @architect-used-by DocExtractor, ExtractedPatternSchema * * ## DocDirectiveSchema - Parsed JSDoc Directive Validation * - * Zod schemas for validating parsed @libar-docs-* directives from JSDoc comments. + * Zod schemas for validating parsed @architect-* directives from JSDoc comments. * Enforces tag format, position validity, and metadata extraction. * * ### When to Use * - * - Use when parsing JSDoc comments for @libar-docs-* tags + * - Use when parsing JSDoc comments for @architect-* tags * - Use when validating directive structure at boundaries */ @@ -47,9 +47,9 @@ export type Position = z.infer; /** * Creates a DirectiveTag schema for a given tag prefix. - * This factory enables projects to use custom prefixes (e.g., "@docs-" instead of "@libar-docs-"). + * This factory enables projects to use custom prefixes (e.g., "@docs-" instead of "@architect-"). * - * @param tagPrefix - The tag prefix to validate against (e.g., "@docs-" or "@libar-docs-") + * @param tagPrefix - The tag prefix to validate against (e.g., "@docs-" or "@architect-") * @returns Zod schema that validates and transforms tags with the given prefix * * @example @@ -59,8 +59,8 @@ export type Position = z.infer; * customSchema.parse("@docs-pattern"); // Valid * * // Default prefix - * const defaultSchema = createDirectiveTagSchema("@libar-docs-"); - * defaultSchema.parse("@libar-docs-status"); // Valid + * const defaultSchema = createDirectiveTagSchema("@architect-"); + * defaultSchema.parse("@architect-status"); // Valid * ``` */ // eslint-disable-next-line @typescript-eslint/explicit-function-return-type @@ -76,11 +76,11 @@ export function createDirectiveTagSchema(tagPrefix: string) { /** * Directive tag validation (default prefix) - * Must start with @libar-docs- + * Must start with @architect- * * For custom prefixes, use createDirectiveTagSchema(). */ -const DirectiveTagSchema = createDirectiveTagSchema('@libar-docs-'); +const DirectiveTagSchema = createDirectiveTagSchema('@architect-'); /** * Default status values for pattern implementation state @@ -144,7 +144,7 @@ export function createPatternStatusSchema(registry: TagRegistry): z.ZodType; * A single extracted shape from TypeScript source. * * Represents an interface, type alias, enum, function signature, or const - * that was extracted via @libar-docs-extract-shapes for documentation. + * that was extracted via @architect-extract-shapes for documentation. */ export const ExtractedShapeSchema = z.object({ /** Shape name (interface/type/enum/function name) */ @@ -133,10 +133,10 @@ export const ExtractedShapeSchema = z.object({ /** Whether this is an exported shape */ exported: z.boolean().default(true), - /** DD-5: Optional group name from @libar-docs-shape tag value */ + /** DD-5: Optional group name from @architect-shape tag value */ group: z.string().optional(), - /** DD-3: Cross-cutting document inclusion tags from @libar-docs-include CSV */ + /** DD-3: Cross-cutting document inclusion tags from @architect-include CSV */ includes: z.array(z.string().min(1)).readonly().optional(), /** For interfaces: JSDoc documentation for each property */ diff --git a/src/validation-schemas/master-dataset.ts b/src/validation-schemas/master-dataset.ts index fc7f10e7..16350807 100644 --- a/src/validation-schemas/master-dataset.ts +++ b/src/validation-schemas/master-dataset.ts @@ -1,17 +1,17 @@ /** - * @libar-docs - * @libar-docs-validation @libar-docs-core - * @libar-docs-pattern MasterDataset - * @libar-docs-status completed - * @libar-docs-uses Zod, ExtractedPattern, TagRegistry - * @libar-docs-used-by Orchestrator, SectionRenderer, ReportCodecs - * @libar-docs-usecase "When providing pre-computed views to section renderers" - * @libar-docs-usecase "When eliminating redundant filtering across generators" - * @libar-docs-extract-shapes MasterDatasetSchema, StatusGroupsSchema, StatusCountsSchema, PhaseGroupSchema, SourceViewsSchema, RelationshipEntrySchema, ArchIndexSchema - * @libar-docs-arch-role read-model - * @libar-docs-arch-context api - * @libar-docs-arch-layer domain - * @libar-docs-include codec-transformation + * @architect + * @architect-validation @architect-core + * @architect-pattern MasterDataset + * @architect-status completed + * @architect-uses Zod, ExtractedPattern, TagRegistry + * @architect-used-by Orchestrator, SectionRenderer, ReportCodecs + * @architect-usecase "When providing pre-computed views to section renderers" + * @architect-usecase "When eliminating redundant filtering across generators" + * @architect-extract-shapes MasterDatasetSchema, StatusGroupsSchema, StatusCountsSchema, PhaseGroupSchema, SourceViewsSchema, RelationshipEntrySchema, ArchIndexSchema + * @architect-arch-role read-model + * @architect-arch-context api + * @architect-arch-layer domain + * @architect-include codec-transformation * * ## MasterDataset - Unified Pattern Views Schema * @@ -51,7 +51,7 @@ import { TagRegistrySchema } from './tag-registry.js'; * - active: active, partial, in-progress * - planned: roadmap, planned, undefined * - * @libar-docs-shape master-dataset + * @architect-shape master-dataset */ export const StatusGroupsSchema = z.object({ /** Patterns with status 'completed' or 'implemented' */ @@ -67,7 +67,7 @@ export const StatusGroupsSchema = z.object({ /** * Status counts for aggregate statistics * - * @libar-docs-shape master-dataset + * @architect-shape master-dataset */ export const StatusCountsSchema = z.object({ /** Number of completed patterns */ @@ -89,7 +89,7 @@ export const StatusCountsSchema = z.object({ * Groups patterns by their phase number, with pre-computed * status counts for each phase. * - * @libar-docs-shape master-dataset + * @architect-shape master-dataset */ export const PhaseGroupSchema = z.object({ /** Phase number (e.g., 1, 2, 3, 14, 39) */ @@ -108,7 +108,7 @@ export const PhaseGroupSchema = z.object({ /** * Source-based views for different data origins * - * @libar-docs-shape master-dataset + * @architect-shape master-dataset */ export const SourceViewsSchema = z.object({ /** Patterns from TypeScript files (.ts) */ @@ -146,19 +146,19 @@ export const ImplementationRefSchema = z.object({ * * Maps pattern names to their relationship metadata. * - * @libar-docs-shape master-dataset + * @architect-shape master-dataset */ export const RelationshipEntrySchema = z.object({ - /** Patterns this pattern uses (from @libar-docs-uses) */ + /** Patterns this pattern uses (from @architect-uses) */ uses: z.array(z.string()), - /** Patterns that use this pattern (from @libar-docs-used-by) */ + /** Patterns that use this pattern (from @architect-used-by) */ usedBy: z.array(z.string()), - /** Patterns this pattern depends on (from @libar-docs-depends-on) */ + /** Patterns this pattern depends on (from @architect-depends-on) */ dependsOn: z.array(z.string()), - /** Patterns this pattern enables (from @libar-docs-enables) */ + /** Patterns this pattern enables (from @architect-enables) */ enables: z.array(z.string()), // UML-inspired relationship fields (PatternRelationshipModel) @@ -174,10 +174,10 @@ export const RelationshipEntrySchema = z.object({ /** Patterns that extend this pattern (computed inverse) */ extendedBy: z.array(z.string()), - /** Related patterns for cross-reference without dependency (from @libar-docs-see-also tag) */ + /** Related patterns for cross-reference without dependency (from @architect-see-also tag) */ seeAlso: z.array(z.string()), - /** File paths to implementation APIs (from @libar-docs-api-ref tag) */ + /** File paths to implementation APIs (from @architect-api-ref tag) */ apiRef: z.array(z.string()), }); @@ -211,11 +211,11 @@ export const ArchIndexSchema = z.object({ * A single step in a sequence diagram, derived from a Rule with sequence annotations */ export const SequenceStepSchema = z.object({ - /** Step execution order (from @libar-docs-sequence-step tag) */ + /** Step execution order (from @architect-sequence-step tag) */ stepNumber: z.number().int().positive(), /** Business rule name (the Rule: keyword text) */ ruleName: z.string().trim().min(1), - /** Module identifiers for this step (from @libar-docs-sequence-module CSV tag) */ + /** Module identifiers for this step (from @architect-sequence-module CSV tag) */ modules: z.array(z.string().trim().min(1)).min(1).readonly(), /** Input type annotation (from **Input:** marker in rule description) */ input: z.string().optional(), @@ -223,7 +223,7 @@ export const SequenceStepSchema = z.object({ output: z.string().optional(), /** Invariant text (for Note blocks in sequence diagram) */ invariant: z.string().optional(), - /** Scenario names tagged with @libar-docs-sequence-error */ + /** Scenario names tagged with @architect-sequence-error */ errorScenarios: z.array(z.string().trim().min(1)).readonly(), }); @@ -231,7 +231,7 @@ export const SequenceStepSchema = z.object({ * Pre-computed sequence data for a single pattern, keyed by pattern name */ export const SequenceIndexEntrySchema = z.object({ - /** Orchestrator module identifier (from @libar-docs-sequence-orchestrator tag) */ + /** Orchestrator module identifier (from @architect-sequence-orchestrator tag) */ orchestrator: z.string().trim().min(1), /** Ordered sequence steps (sorted by stepNumber) */ steps: z.array(SequenceStepSchema).min(1).readonly(), @@ -260,7 +260,7 @@ export const SequenceIndexSchema = z.record(z.string().trim().min(1), SequenceIn * Contains raw patterns plus pre-computed views and statistics. * This is the primary data structure passed to generators and sections. * - * @libar-docs-shape master-dataset + * @architect-shape master-dataset */ export const MasterDatasetSchema = z.object({ // ───────────────────────────────────────────────────────────────────────── diff --git a/src/validation-schemas/output-schemas.ts b/src/validation-schemas/output-schemas.ts index 3632410d..b3ea3740 100644 --- a/src/validation-schemas/output-schemas.ts +++ b/src/validation-schemas/output-schemas.ts @@ -1,13 +1,13 @@ /** - * @libar-docs - * @libar-docs-validation @libar-docs-core - * @libar-docs-pattern OutputSchemas - * @libar-docs-status completed - * @libar-docs-uses Zod, LintSeveritySchema - * @libar-docs-used-by LintEngine, ValidatePatternsCLI, Orchestrator - * @libar-docs-usecase "When serializing lint results to JSON" - * @libar-docs-usecase "When serializing validation results to JSON" - * @libar-docs-usecase "When writing registry metadata to JSON" + * @architect + * @architect-validation @architect-core + * @architect-pattern OutputSchemas + * @architect-status completed + * @architect-uses Zod, LintSeveritySchema + * @architect-used-by LintEngine, ValidatePatternsCLI, Orchestrator + * @architect-usecase "When serializing lint results to JSON" + * @architect-usecase "When serializing validation results to JSON" + * @architect-usecase "When writing registry metadata to JSON" * * ## OutputSchemas - JSON Output Format Schemas * diff --git a/src/validation-schemas/tag-registry.ts b/src/validation-schemas/tag-registry.ts index ca989a00..413d4821 100644 --- a/src/validation-schemas/tag-registry.ts +++ b/src/validation-schemas/tag-registry.ts @@ -1,8 +1,8 @@ /** - * @libar-docs - * @libar-docs-core @libar-docs-infra - * @libar-docs-pattern Tag Registry Configuration - * @libar-docs-status completed + * @architect + * @architect-core @architect-infra + * @architect-pattern Tag Registry Configuration + * @architect-status completed * * ## Tag Registry Configuration Schema * @@ -69,7 +69,7 @@ export type CategoryDefinition = z.infer; * required: false, * values: ["roadmap", "active", "completed"], * default: "roadmap", - * example: "@libar-docs-status completed" + * example: "@architect-status completed" * } * ``` */ @@ -148,8 +148,8 @@ export type AggregationTagDefinition = z.infer prefix > substring > Levenshtein. diff --git a/tests/features/api/output-shaping/output-pipeline.feature b/tests/features/api/output-shaping/output-pipeline.feature index 21e5019d..3efc1c9c 100644 --- a/tests/features/api/output-shaping/output-pipeline.feature +++ b/tests/features/api/output-shaping/output-pipeline.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:OutputPipelineTests -@libar-docs-status:active -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:OutputPipelineTests +@architect-status:active +@architect-product-area:DataAPI Feature: Output Modifier Pipeline Validates the output pipeline transforms: summarization, modifiers, diff --git a/tests/features/api/output-shaping/pattern-helpers.feature b/tests/features/api/output-shaping/pattern-helpers.feature index 8ba253ec..f74c690a 100644 --- a/tests/features/api/output-shaping/pattern-helpers.feature +++ b/tests/features/api/output-shaping/pattern-helpers.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:PatternHelpersTests -@libar-docs-status:active -@libar-docs-phase:25a -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:PatternHelpersTests +@architect-status:active +@architect-phase:25a +@architect-product-area:DataAPI Feature: Pattern Helpers — Shared Lookup Utilities Rule: getPatternName uses patternName tag when available diff --git a/tests/features/api/output-shaping/summarize.feature b/tests/features/api/output-shaping/summarize.feature index 81de3211..c7872a94 100644 --- a/tests/features/api/output-shaping/summarize.feature +++ b/tests/features/api/output-shaping/summarize.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:PatternSummarizeTests -@libar-docs-status:active -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:PatternSummarizeTests +@architect-status:active +@architect-product-area:DataAPI Feature: Pattern Summarization Validates that summarizePattern() projects ExtractedPattern (~3.5KB) to diff --git a/tests/features/api/process-state-api.feature b/tests/features/api/process-state-api.feature index 92e7fd92..1b6f1271 100644 --- a/tests/features/api/process-state-api.feature +++ b/tests/features/api/process-state-api.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-implements:ProcessStateAPICLI -@libar-docs-status:completed +@architect +@architect-implements:ProcessStateAPICLI +@architect-status:completed @behavior @process-state-api -@libar-docs-pattern:ProcessStateAPITesting -@libar-docs-product-area:DataAPI +@architect-pattern:ProcessStateAPITesting +@architect-product-area:DataAPI Feature: Process State API Programmatic interface for querying delivery process state. Designed for Claude Code integration and tool automation. diff --git a/tests/features/api/session-support/handoff-generator.feature b/tests/features/api/session-support/handoff-generator.feature index 9a809639..29d20f63 100644 --- a/tests/features/api/session-support/handoff-generator.feature +++ b/tests/features/api/session-support/handoff-generator.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:HandoffGeneratorTests -@libar-docs-status:completed -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:HandoffGeneratorTests +@architect-status:completed +@architect-product-area:DataAPI Feature: Handoff Generator - Session-End State Summary **Problem:** diff --git a/tests/features/api/session-support/scope-validator.feature b/tests/features/api/session-support/scope-validator.feature index eddb8aee..d40bc374 100644 --- a/tests/features/api/session-support/scope-validator.feature +++ b/tests/features/api/session-support/scope-validator.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:ScopeValidatorTests -@libar-docs-status:completed -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:ScopeValidatorTests +@architect-status:completed +@architect-product-area:DataAPI Feature: Scope Validator - Pre-flight Session Readiness Checks **Problem:** diff --git a/tests/features/api/stub-integration/stub-resolver.feature b/tests/features/api/stub-integration/stub-resolver.feature index 8464c090..52bd0b05 100644 --- a/tests/features/api/stub-integration/stub-resolver.feature +++ b/tests/features/api/stub-integration/stub-resolver.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:StubResolverTests -@libar-docs-status:active -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:StubResolverTests +@architect-status:active +@architect-product-area:DataAPI Feature: Stub Resolver - Design Stub Discovery and Resolution **Problem:** diff --git a/tests/features/api/stub-integration/taxonomy-tags.feature b/tests/features/api/stub-integration/taxonomy-tags.feature index 975a9e3e..d5516565 100644 --- a/tests/features/api/stub-integration/taxonomy-tags.feature +++ b/tests/features/api/stub-integration/taxonomy-tags.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:StubTaxonomyTagTests -@libar-docs-status:active -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:StubTaxonomyTagTests +@architect-status:active +@architect-product-area:DataAPI Feature: Stub Integration Taxonomy Tags **Problem:** diff --git a/tests/features/behavior/architecture-diagrams/arch-index.feature b/tests/features/behavior/architecture-diagrams/arch-index.feature index c63d8e1d..6d26f133 100644 --- a/tests/features/behavior/architecture-diagrams/arch-index.feature +++ b/tests/features/behavior/architecture-diagrams/arch-index.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ArchIndexDataset -@libar-docs-status:completed -@libar-docs-implements:ArchitectureDiagramGeneration -@libar-docs-product-area:Generation +@architect +@architect-pattern:ArchIndexDataset +@architect-status:completed +@architect-implements:ArchitectureDiagramGeneration +@architect-product-area:Generation @architecture Feature: Architecture Index in MasterDataset diff --git a/tests/features/behavior/architecture-diagrams/arch-tag-extraction.feature b/tests/features/behavior/architecture-diagrams/arch-tag-extraction.feature index db5ff20d..e8d172dd 100644 --- a/tests/features/behavior/architecture-diagrams/arch-tag-extraction.feature +++ b/tests/features/behavior/architecture-diagrams/arch-tag-extraction.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ArchTagExtraction -@libar-docs-status:completed -@libar-docs-implements:ArchitectureDiagramGeneration -@libar-docs-product-area:Generation +@architect +@architect-pattern:ArchTagExtraction +@architect-status:completed +@architect-implements:ArchitectureDiagramGeneration +@architect-product-area:Generation @architecture Feature: Architecture Tag Extraction @@ -98,10 +98,10 @@ Feature: Architecture Tag Extraction Given TypeScript source: """typescript /** - * @libar-docs - * @libar-docs-pattern MyProjection - * @libar-docs-status completed - * @libar-docs-arch-role projection + * @architect + * @architect-pattern MyProjection + * @architect-status completed + * @architect-arch-role projection */ export const myProjection = {}; """ @@ -113,10 +113,10 @@ Feature: Architecture Tag Extraction Given TypeScript source: """typescript /** - * @libar-docs - * @libar-docs-pattern MyHandler - * @libar-docs-status completed - * @libar-docs-arch-role command-handler + * @architect + * @architect-pattern MyHandler + * @architect-status completed + * @architect-arch-role command-handler */ export const myHandler = {}; """ @@ -136,10 +136,10 @@ Feature: Architecture Tag Extraction Given TypeScript source: """typescript /** - * @libar-docs - * @libar-docs-pattern OrderHandler - * @libar-docs-status completed - * @libar-docs-arch-context orders + * @architect + * @architect-pattern OrderHandler + * @architect-status completed + * @architect-arch-context orders */ export const orderHandler = {}; """ @@ -151,10 +151,10 @@ Feature: Architecture Tag Extraction Given TypeScript source: """typescript /** - * @libar-docs - * @libar-docs-pattern InventoryHandler - * @libar-docs-status completed - * @libar-docs-arch-context inventory + * @architect + * @architect-pattern InventoryHandler + * @architect-status completed + * @architect-arch-context inventory */ export const inventoryHandler = {}; """ @@ -174,10 +174,10 @@ Feature: Architecture Tag Extraction Given TypeScript source: """typescript /** - * @libar-docs - * @libar-docs-pattern MyService - * @libar-docs-status completed - * @libar-docs-arch-layer application + * @architect + * @architect-pattern MyService + * @architect-status completed + * @architect-arch-layer application */ export const myService = {}; """ @@ -189,10 +189,10 @@ Feature: Architecture Tag Extraction Given TypeScript source: """typescript /** - * @libar-docs - * @libar-docs-pattern MyInfra - * @libar-docs-status completed - * @libar-docs-arch-layer infrastructure + * @architect + * @architect-pattern MyInfra + * @architect-status completed + * @architect-arch-layer infrastructure */ export const myInfra = {}; """ @@ -212,12 +212,12 @@ Feature: Architecture Tag Extraction Given TypeScript source: """typescript /** - * @libar-docs - * @libar-docs-pattern OrderCommandHandlers - * @libar-docs-status completed - * @libar-docs-arch-role command-handler - * @libar-docs-arch-context orders - * @libar-docs-arch-layer application + * @architect + * @architect-pattern OrderCommandHandlers + * @architect-status completed + * @architect-arch-role command-handler + * @architect-arch-context orders + * @architect-arch-layer application */ export const orderCommandHandlers = {}; """ @@ -239,9 +239,9 @@ Feature: Architecture Tag Extraction Given TypeScript source: """typescript /** - * @libar-docs - * @libar-docs-pattern NoArchTags - * @libar-docs-status completed + * @architect + * @architect-pattern NoArchTags + * @architect-status completed */ export const noArchTags = {}; """ diff --git a/tests/features/behavior/architecture-diagrams/component-diagram.feature b/tests/features/behavior/architecture-diagrams/component-diagram.feature index 1f2487c2..2e37284e 100644 --- a/tests/features/behavior/architecture-diagrams/component-diagram.feature +++ b/tests/features/behavior/architecture-diagrams/component-diagram.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ComponentDiagramGeneration -@libar-docs-status:completed -@libar-docs-implements:ArchitectureDiagramGeneration -@libar-docs-product-area:Generation +@architect +@architect-pattern:ComponentDiagramGeneration +@architect-status:completed +@architect-implements:ArchitectureDiagramGeneration +@architect-product-area:Generation @architecture Feature: Component Diagram Generation @@ -199,5 +199,5 @@ Feature: Component Diagram Generation Then the document contains elements: | text | | No Architecture Data | - | @libar-docs-arch-role | + | @architect-arch-role | diff --git a/tests/features/behavior/architecture-diagrams/generator-registration.feature b/tests/features/behavior/architecture-diagrams/generator-registration.feature index 37b08edc..031c6936 100644 --- a/tests/features/behavior/architecture-diagrams/generator-registration.feature +++ b/tests/features/behavior/architecture-diagrams/generator-registration.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ArchGeneratorRegistration -@libar-docs-status:completed -@libar-docs-implements:ArchitectureDiagramGeneration -@libar-docs-product-area:Generation +@architect +@architect-pattern:ArchGeneratorRegistration +@architect-status:completed +@architect-implements:ArchitectureDiagramGeneration +@architect-product-area:Generation @architecture Feature: Architecture Generator Registration diff --git a/tests/features/behavior/architecture-diagrams/layered-diagram.feature b/tests/features/behavior/architecture-diagrams/layered-diagram.feature index cadc8ffa..527d565a 100644 --- a/tests/features/behavior/architecture-diagrams/layered-diagram.feature +++ b/tests/features/behavior/architecture-diagrams/layered-diagram.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:LayeredDiagramGeneration -@libar-docs-status:completed -@libar-docs-implements:ArchitectureDiagramGeneration -@libar-docs-product-area:Generation +@architect +@architect-pattern:LayeredDiagramGeneration +@architect-status:completed +@architect-implements:ArchitectureDiagramGeneration +@architect-product-area:Generation @architecture Feature: Layered Architecture Diagram Generation diff --git a/tests/features/behavior/cli/process-api-reference.feature b/tests/features/behavior/cli/process-api-reference.feature index 352cf968..78d1f2d0 100644 --- a/tests/features/behavior/cli/process-api-reference.feature +++ b/tests/features/behavior/cli/process-api-reference.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ProcessApiReferenceTests -@libar-docs-implements:ProcessApiHybridGeneration -@libar-docs-status:completed -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:ProcessApiReferenceTests +@architect-implements:ProcessApiHybridGeneration +@architect-status:completed +@architect-product-area:DataAPI @behavior @cli @process-api-reference Feature: Process API CLI Reference Generation diff --git a/tests/features/behavior/codec-migration.feature b/tests/features/behavior/codec-migration.feature index 84206dac..ee6a9ab8 100644 --- a/tests/features/behavior/codec-migration.feature +++ b/tests/features/behavior/codec-migration.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:ZodCodecMigration -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:ZodCodecMigration +@architect-status:completed +@architect-product-area:Generation @behavior @codec Feature: Zod Codec Migration All JSON parsing and serialization uses type-safe Zod codec pattern, diff --git a/tests/features/behavior/codecs/composite-codec.feature b/tests/features/behavior/codecs/composite-codec.feature index d7275595..ffbacf95 100644 --- a/tests/features/behavior/codecs/composite-codec.feature +++ b/tests/features/behavior/codecs/composite-codec.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:CompositeCodecTesting -@libar-docs-status:completed -@libar-docs-implements:ReferenceDocShowcase -@libar-docs-product-area:Generation +@architect +@architect-pattern:CompositeCodecTesting +@architect-status:completed +@architect-implements:ReferenceDocShowcase +@architect-product-area:Generation Feature: Composite Codec Assembles reference documents from multiple codec outputs by diff --git a/tests/features/behavior/codecs/convention-extractor.feature b/tests/features/behavior/codecs/convention-extractor.feature index a17d5efe..5d5987fe 100644 --- a/tests/features/behavior/codecs/convention-extractor.feature +++ b/tests/features/behavior/codecs/convention-extractor.feature @@ -1,14 +1,14 @@ -@libar-docs +@architect @behavior @convention-extractor -@libar-docs-pattern:ConventionExtractorTesting -@libar-docs-status:completed -@libar-docs-unlock-reason:Fix-escaped-pipe-parsing-in-convention-tables -@libar-docs-implements:ReferenceDocShowcase -@libar-docs-product-area:Generation +@architect-pattern:ConventionExtractorTesting +@architect-status:completed +@architect-unlock-reason:Fix-escaped-pipe-parsing-in-convention-tables +@architect-implements:ReferenceDocShowcase +@architect-product-area:Generation Feature: Convention Extractor Extracts convention content from MasterDataset decision records - tagged with @libar-docs-convention. Produces structured ConventionBundles + tagged with @architect-convention. Produces structured ConventionBundles with rule content, tables, and invariant/rationale metadata. Background: diff --git a/tests/features/behavior/codecs/dedent.feature b/tests/features/behavior/codecs/dedent.feature index 3ad42b3e..81109868 100644 --- a/tests/features/behavior/codecs/dedent.feature +++ b/tests/features/behavior/codecs/dedent.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:DedentHelper -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:DedentHelper +@architect-status:completed +@architect-product-area:Generation @behavior @dedent Feature: Dedent Helper Function Edge Cases diff --git a/tests/features/behavior/codecs/generated-doc-quality.feature b/tests/features/behavior/codecs/generated-doc-quality.feature index 7c24ad1d..a168bace 100644 --- a/tests/features/behavior/codecs/generated-doc-quality.feature +++ b/tests/features/behavior/codecs/generated-doc-quality.feature @@ -1,9 +1,9 @@ -@libar-docs +@architect @behavior @reference-codec -@libar-docs-pattern:GeneratedDocQualityTests -@libar-docs-status:completed -@libar-docs-implements:GeneratedDocQuality -@libar-docs-product-area:Generation +@architect-pattern:GeneratedDocQualityTests +@architect-status:completed +@architect-implements:GeneratedDocQuality +@architect-product-area:Generation Feature: Generated Documentation Quality Improvements Tests for the four quality fixes in GeneratedDocQuality (Phase 38): diff --git a/tests/features/behavior/codecs/planning-codecs.feature b/tests/features/behavior/codecs/planning-codecs.feature index 0a2c292b..8c575a79 100644 --- a/tests/features/behavior/codecs/planning-codecs.feature +++ b/tests/features/behavior/codecs/planning-codecs.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:PlanningCodecTesting -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-implements:CodecBehaviorTesting +@architect +@architect-pattern:PlanningCodecTesting +@architect-status:completed +@architect-product-area:Generation +@architect-implements:CodecBehaviorTesting @behavior @planning-codecs Feature: Planning Document Codecs The planning codecs (PlanningChecklistCodec, SessionPlanCodec, SessionFindingsCodec) diff --git a/tests/features/behavior/codecs/pr-changes-codec-options.feature b/tests/features/behavior/codecs/pr-changes-codec-options.feature index e8b0fb95..f678ca82 100644 --- a/tests/features/behavior/codecs/pr-changes-codec-options.feature +++ b/tests/features/behavior/codecs/pr-changes-codec-options.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:PrChangesCodecOptionsTesting -@libar-docs-implements:PrChangesCodec -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-product-area:Generation +@architect +@architect-pattern:PrChangesCodecOptionsTesting +@architect-implements:PrChangesCodec +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-product-area:Generation @behavior @pr-changes-codec Feature: PR Changes Codec - Options and Filters The PrChangesCodec transforms MasterDataset into RenderableDocument for diff --git a/tests/features/behavior/codecs/pr-changes-codec-rendering.feature b/tests/features/behavior/codecs/pr-changes-codec-rendering.feature index 3ea99bfb..5baa4942 100644 --- a/tests/features/behavior/codecs/pr-changes-codec-rendering.feature +++ b/tests/features/behavior/codecs/pr-changes-codec-rendering.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:PrChangesCodecRenderingTesting -@libar-docs-implements:PrChangesCodec -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:PrChangesCodecRenderingTesting +@architect-implements:PrChangesCodec +@architect-status:completed +@architect-product-area:Generation @behavior @pr-changes-codec Feature: PR Changes Codec - Core Rendering The PrChangesCodec transforms MasterDataset into RenderableDocument for diff --git a/tests/features/behavior/codecs/reference-codec-core.feature b/tests/features/behavior/codecs/reference-codec-core.feature index 3551178c..9b87b169 100644 --- a/tests/features/behavior/codecs/reference-codec-core.feature +++ b/tests/features/behavior/codecs/reference-codec-core.feature @@ -1,10 +1,10 @@ -@libar-docs +@architect @behavior @reference-codec -@libar-docs-pattern:ReferenceCodecCoreTesting -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-implements:ReferenceDocShowcase -@libar-docs-product-area:Generation +@architect-pattern:ReferenceCodecCoreTesting +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-implements:ReferenceDocShowcase +@architect-product-area:Generation Feature: Reference Codec - Core Behavior Parameterized codec factory that creates reference document codecs diff --git a/tests/features/behavior/codecs/reference-codec-detail-rendering.feature b/tests/features/behavior/codecs/reference-codec-detail-rendering.feature index 08c456f2..cd542c64 100644 --- a/tests/features/behavior/codecs/reference-codec-detail-rendering.feature +++ b/tests/features/behavior/codecs/reference-codec-detail-rendering.feature @@ -1,10 +1,10 @@ -@libar-docs +@architect @behavior @reference-codec -@libar-docs-pattern:ReferenceCodecDetailRendering -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-implements:ReferenceDocShowcase -@libar-docs-product-area:Generation +@architect-pattern:ReferenceCodecDetailRendering +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-implements:ReferenceDocShowcase +@architect-product-area:Generation Feature: Reference Codec - Detail Level Rendering Standard detail level behavior, deep behavior rendering with structured diff --git a/tests/features/behavior/codecs/reference-codec-diagram-types.feature b/tests/features/behavior/codecs/reference-codec-diagram-types.feature index cb8a96ab..7340f282 100644 --- a/tests/features/behavior/codecs/reference-codec-diagram-types.feature +++ b/tests/features/behavior/codecs/reference-codec-diagram-types.feature @@ -1,10 +1,10 @@ -@libar-docs +@architect @behavior @reference-codec -@libar-docs-pattern:ReferenceCodecDiagramTypeTesting -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-implements:ReferenceDocShowcase -@libar-docs-product-area:Generation +@architect-pattern:ReferenceCodecDiagramTypeTesting +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-implements:ReferenceDocShowcase +@architect-product-area:Generation Feature: Reference Codec - Diagram Type Rendering Diagram type controls Mermaid output format including flowchart, diff --git a/tests/features/behavior/codecs/reference-codec-diagrams.feature b/tests/features/behavior/codecs/reference-codec-diagrams.feature index 1337a9fa..a096f0bc 100644 --- a/tests/features/behavior/codecs/reference-codec-diagrams.feature +++ b/tests/features/behavior/codecs/reference-codec-diagrams.feature @@ -1,10 +1,10 @@ -@libar-docs +@architect @behavior @reference-codec -@libar-docs-pattern:ReferenceCodecDiagramTesting -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-implements:ReferenceDocShowcase -@libar-docs-product-area:Generation +@architect-pattern:ReferenceCodecDiagramTesting +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-implements:ReferenceDocShowcase +@architect-product-area:Generation Feature: Reference Codec - Diagram Scoping Scoped diagram generation from diagramScope and diagramScopes config, diff --git a/tests/features/behavior/codecs/reference-generators.feature b/tests/features/behavior/codecs/reference-generators.feature index f1e6960f..ca1e23ca 100644 --- a/tests/features/behavior/codecs/reference-generators.feature +++ b/tests/features/behavior/codecs/reference-generators.feature @@ -1,9 +1,9 @@ -@libar-docs +@architect @behavior @reference-generators -@libar-docs-pattern:ReferenceGeneratorTesting -@libar-docs-status:completed -@libar-docs-implements:ReferenceDocShowcase -@libar-docs-product-area:Generation +@architect-pattern:ReferenceGeneratorTesting +@architect-status:completed +@architect-implements:ReferenceDocShowcase +@architect-product-area:Generation Feature: Reference Document Generator Registration Registers reference document generators from project config. Configs with diff --git a/tests/features/behavior/codecs/reporting-codecs.feature b/tests/features/behavior/codecs/reporting-codecs.feature index 5b0dfca0..690481b2 100644 --- a/tests/features/behavior/codecs/reporting-codecs.feature +++ b/tests/features/behavior/codecs/reporting-codecs.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ReportingCodecTesting -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-implements:CodecBehaviorTesting +@architect +@architect-pattern:ReportingCodecTesting +@architect-status:completed +@architect-product-area:Generation +@architect-implements:CodecBehaviorTesting @behavior @reporting-codecs Feature: Reporting Document Codecs The reporting codecs (ChangelogCodec, TraceabilityCodec, OverviewCodec) diff --git a/tests/features/behavior/codecs/requirements-adr-codecs.feature b/tests/features/behavior/codecs/requirements-adr-codecs.feature index 5bec34d6..126254a3 100644 --- a/tests/features/behavior/codecs/requirements-adr-codecs.feature +++ b/tests/features/behavior/codecs/requirements-adr-codecs.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:RequirementsAdrCodecTesting -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-implements:CodecBehaviorTesting +@architect +@architect-pattern:RequirementsAdrCodecTesting +@architect-status:completed +@architect-product-area:Generation +@architect-implements:CodecBehaviorTesting @behavior @requirements-adr-codecs Feature: Requirements and ADR Document Codecs The RequirementsDocumentCodec and AdrDocumentCodec transform MasterDataset diff --git a/tests/features/behavior/codecs/session-codecs.feature b/tests/features/behavior/codecs/session-codecs.feature index 49196cdb..db38c1c6 100644 --- a/tests/features/behavior/codecs/session-codecs.feature +++ b/tests/features/behavior/codecs/session-codecs.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:SessionCodecTesting -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-implements:CodecBehaviorTesting +@architect +@architect-pattern:SessionCodecTesting +@architect-status:completed +@architect-product-area:Generation +@architect-implements:CodecBehaviorTesting @behavior @session-codecs Feature: Session Document Codecs The session codecs (SessionContextCodec, RemainingWorkCodec) diff --git a/tests/features/behavior/codecs/shape-matcher.feature b/tests/features/behavior/codecs/shape-matcher.feature index e3ff34cc..c79ea6fc 100644 --- a/tests/features/behavior/codecs/shape-matcher.feature +++ b/tests/features/behavior/codecs/shape-matcher.feature @@ -1,9 +1,9 @@ -@libar-docs +@architect @behavior @shape-matcher -@libar-docs-pattern:ShapeMatcherTesting -@libar-docs-status:completed -@libar-docs-implements:ReferenceDocShowcase,DeclarationLevelShapeTagging -@libar-docs-product-area:Generation +@architect-pattern:ShapeMatcherTesting +@architect-status:completed +@architect-implements:ReferenceDocShowcase,DeclarationLevelShapeTagging +@architect-product-area:Generation Feature: Shape Source Pattern Matching Matches file paths against glob patterns for TypeScript shape extraction. diff --git a/tests/features/behavior/codecs/shape-selector.feature b/tests/features/behavior/codecs/shape-selector.feature index f9efdc16..111a91af 100644 --- a/tests/features/behavior/codecs/shape-selector.feature +++ b/tests/features/behavior/codecs/shape-selector.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ShapeSelectorTesting -@libar-docs-status:completed -@libar-docs-implements:ReferenceDocShowcase,DeclarationLevelShapeTagging -@libar-docs-product-area:Generation +@architect +@architect-pattern:ShapeSelectorTesting +@architect-status:completed +@architect-implements:ReferenceDocShowcase,DeclarationLevelShapeTagging +@architect-product-area:Generation Feature: Shape Selector Filtering Tests the filterShapesBySelectors function that provides fine-grained diff --git a/tests/features/behavior/codecs/timeline-codecs.feature b/tests/features/behavior/codecs/timeline-codecs.feature index 406759ed..ce0f2e30 100644 --- a/tests/features/behavior/codecs/timeline-codecs.feature +++ b/tests/features/behavior/codecs/timeline-codecs.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:TimelineCodecTesting -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-implements:CodecBehaviorTesting +@architect +@architect-pattern:TimelineCodecTesting +@architect-status:completed +@architect-product-area:Generation +@architect-implements:CodecBehaviorTesting @behavior @timeline-codecs Feature: Timeline Document Codecs The timeline codecs (RoadmapDocumentCodec, CompletedMilestonesCodec, CurrentWorkCodec) diff --git a/tests/features/behavior/context-inference.feature b/tests/features/behavior/context-inference.feature index 395f5662..3deb42c8 100644 --- a/tests/features/behavior/context-inference.feature +++ b/tests/features/behavior/context-inference.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:ContextInference -@libar-docs-status:completed -@libar-docs-product-area:Annotation +@architect +@architect-pattern:ContextInference +@architect-status:completed +@architect-product-area:Annotation @behavior @context-inference Feature: Context Auto-Inference from File Paths diff --git a/tests/features/behavior/description-headers.feature b/tests/features/behavior/description-headers.feature index 6e896664..a9446934 100644 --- a/tests/features/behavior/description-headers.feature +++ b/tests/features/behavior/description-headers.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:DescriptionHeaderNormalization -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:DescriptionHeaderNormalization +@architect-status:completed +@architect-product-area:Generation Feature: Description Header Normalization Pattern descriptions should not create duplicate headers when rendered. diff --git a/tests/features/behavior/description-quality-foundation.feature b/tests/features/behavior/description-quality-foundation.feature index 21ebf18a..78478113 100644 --- a/tests/features/behavior/description-quality-foundation.feature +++ b/tests/features/behavior/description-quality-foundation.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:DescriptionQualityFoundation -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:DescriptionQualityFoundation +@architect-status:completed +@architect-product-area:Generation @behavior @description-quality Feature: Description Quality Foundation Enhanced documentation generation with human-readable names, diff --git a/tests/features/behavior/directive-detection.feature b/tests/features/behavior/directive-detection.feature index 2cf37961..33bbb797 100644 --- a/tests/features/behavior/directive-detection.feature +++ b/tests/features/behavior/directive-detection.feature @@ -1,50 +1,50 @@ -@libar-docs -@libar-docs-pattern:DirectiveDetection -@libar-docs-status:completed -@libar-docs-product-area:Annotation +@architect +@architect-pattern:DirectiveDetection +@architect-status:completed +@architect-product-area:Annotation @behavior @directive-detection Feature: Directive Detection - Pure functions that detect @libar-docs directives in TypeScript source code. + Pure functions that detect @architect directives in TypeScript source code. These functions enable quick file filtering before full AST parsing. **Problem:** - Full AST parsing of every TypeScript file is expensive and slow - Files without documentation directives waste processing time - - Need to distinguish file-level opt-in (@libar-docs) from section tags (@libar-docs-*) + - Need to distinguish file-level opt-in (@architect) from section tags (@architect-*) - Similar patterns like @libar-doc-core could cause false positives **Solution:** - - hasDocDirectives: Fast regex check for any @libar-docs-* directive - - hasFileOptIn: Validates explicit @libar-docs opt-in (not @libar-docs-*) + - hasDocDirectives: Fast regex check for any @architect-* directive + - hasFileOptIn: Validates explicit @architect opt-in (not @architect-*) - Both use regex patterns optimized for quick filtering before AST parsing - - Negative lookahead ensures @libar-docs doesn't match @libar-docs-* + - Negative lookahead ensures @architect doesn't match @architect-* - Rule: hasDocDirectives detects @libar-docs-* section directives + Rule: hasDocDirectives detects @architect-* section directives - **Invariant:** hasDocDirectives must return true if and only if the source contains at least one @libar-docs-{suffix} directive (case-sensitive, @ required, suffix required). + **Invariant:** hasDocDirectives must return true if and only if the source contains at least one @architect-{suffix} directive (case-sensitive, @ required, suffix required). **Rationale:** This is the first-pass filter in the scanner pipeline; false negatives cause patterns to be silently missed, while false positives only waste AST parsing time. - **Verified by:** Detect @libar-docs-core directive in JSDoc block, Detect various @libar-docs-* directives, Detect directive anywhere in file content, Detect multiple directives on same line, Detect directive in inline comment, Return false for content without directives, Return false for empty content in hasDocDirectives, Reject similar but non-matching patterns + **Verified by:** Detect @architect-core directive in JSDoc block, Detect various @architect-* directives, Detect directive anywhere in file content, Detect multiple directives on same line, Detect directive in inline comment, Return false for content without directives, Return false for empty content in hasDocDirectives, Reject similar but non-matching patterns @happy-path @has-doc-directives - Scenario: Detect @libar-docs-core directive in JSDoc block - Given source code with JSDoc containing "@libar-docs-core" + Scenario: Detect @architect-core directive in JSDoc block + Given source code with JSDoc containing "@architect-core" When checking for documentation directives Then hasDocDirectives should return true @happy-path @has-doc-directives - Scenario Outline: Detect various @libar-docs-* directives + Scenario Outline: Detect various @architect-* directives Given source code containing directive "" When checking for documentation directives Then hasDocDirectives should return true Examples: Standard category directives | directive | - | @libar-docs-core | - | @libar-docs-domain | - | @libar-docs-validation | - | @libar-docs-testing | - | @libar-docs-arch | - | @libar-docs-infra | + | @architect-core | + | @architect-domain | + | @architect-validation | + | @architect-testing | + | @architect-arch | + | @architect-infra | @happy-path @has-doc-directives Scenario: Detect directive anywhere in file content @@ -54,13 +54,13 @@ Feature: Directive Detection @happy-path @has-doc-directives Scenario: Detect multiple directives on same line - Given source code "/** @libar-docs-core @libar-docs-validation */" + Given source code "/** @architect-core @architect-validation */" When checking for documentation directives Then hasDocDirectives should return true @happy-path @has-doc-directives Scenario: Detect directive in inline comment - Given source code "// @libar-docs-core Quick directive" + Given source code "// @architect-core Quick directive" When checking for documentation directives Then hasDocDirectives should return true @@ -84,56 +84,56 @@ Feature: Directive Detection Examples: Invalid patterns | pattern | reason | - | @libar-docs | Missing category suffix | + | @architect | Missing category suffix | | @libar-doc-core | Wrong prefix (doc) | | libar-docs-core | Missing @ symbol | | @LIBAR-DOCS-CORE | Wrong case | - Rule: hasFileOptIn detects file-level @libar-docs marker + Rule: hasFileOptIn detects file-level @architect marker - **Invariant:** hasFileOptIn must return true if and only if the source contains a bare @libar-docs tag (not followed by a hyphen) inside a JSDoc block comment; line comments and @libar-docs-* suffixed tags must not match. - **Rationale:** File-level opt-in is the gate for including a file in the scanner pipeline; confusing @libar-docs-core (a section tag) with @libar-docs (file opt-in) would either miss files or over-include them. - **Verified by:** Detect @libar-docs in JSDoc block comment, Detect @libar-docs with description on same line, Detect @libar-docs in multi-line JSDoc, Detect @libar-docs anywhere in file, Detect @libar-docs combined with section tags, Return false when only section tags present, Return false for multiple section tags without opt-in, Return false for empty content in hasFileOptIn, Return false for @libar-docs in line comment, Not confuse @libar-docs-* with @libar-docs opt-in + **Invariant:** hasFileOptIn must return true if and only if the source contains a bare @architect tag (not followed by a hyphen) inside a JSDoc block comment; line comments and @architect-* suffixed tags must not match. + **Rationale:** File-level opt-in is the gate for including a file in the scanner pipeline; confusing @architect-core (a section tag) with @architect (file opt-in) would either miss files or over-include them. + **Verified by:** Detect @architect in JSDoc block comment, Detect @architect with description on same line, Detect @architect in multi-line JSDoc, Detect @architect anywhere in file, Detect @architect combined with section tags, Return false when only section tags present, Return false for multiple section tags without opt-in, Return false for empty content in hasFileOptIn, Return false for @architect in line comment, Not confuse @architect-* with @architect opt-in @happy-path @has-file-opt-in - Scenario: Detect @libar-docs in JSDoc block comment - Given source code with file-level "@libar-docs" opt-in + Scenario: Detect @architect in JSDoc block comment + Given source code with file-level "@architect" opt-in When checking for file opt-in Then hasFileOptIn should return true @happy-path @has-file-opt-in - Scenario: Detect @libar-docs with description on same line - Given source code "/** @libar-docs This file is documented */" + Scenario: Detect @architect with description on same line + Given source code "/** @architect This file is documented */" When checking for file opt-in Then hasFileOptIn should return true @happy-path @has-file-opt-in - Scenario: Detect @libar-docs in multi-line JSDoc - Given source code with @libar-docs in middle of multi-line JSDoc + Scenario: Detect @architect in multi-line JSDoc + Given source code with @architect in middle of multi-line JSDoc When checking for file opt-in Then hasFileOptIn should return true @happy-path @has-file-opt-in - Scenario: Detect @libar-docs anywhere in file - Given source code with @libar-docs after other content + Scenario: Detect @architect anywhere in file + Given source code with @architect after other content When checking for file opt-in Then hasFileOptIn should return true @happy-path @has-file-opt-in - Scenario: Detect @libar-docs combined with section tags - Given source code "/** @libar-docs @libar-docs-core */" + Scenario: Detect @architect combined with section tags + Given source code "/** @architect @architect-core */" When checking for file opt-in Then hasFileOptIn should return true @edge-case @has-file-opt-in Scenario: Return false when only section tags present - Given source code with only "@libar-docs-core" section tag + Given source code with only "@architect-core" section tag When checking for file opt-in Then hasFileOptIn should return false @edge-case @has-file-opt-in Scenario: Return false for multiple section tags without opt-in - Given source code "/** @libar-docs-core @libar-docs-validation */" + Given source code "/** @architect-core @architect-validation */" When checking for file opt-in Then hasFileOptIn should return false @@ -144,13 +144,13 @@ Feature: Directive Detection Then hasFileOptIn should return false @edge-case @has-file-opt-in - Scenario: Return false for @libar-docs in line comment - Given source code "// @libar-docs This is a line comment, not JSDoc" + Scenario: Return false for @architect in line comment + Given source code "// @architect This is a line comment, not JSDoc" When checking for file opt-in Then hasFileOptIn should return false @edge-case @has-file-opt-in - Scenario: Not confuse @libar-docs-* with @libar-docs opt-in - Given source code "/** @libar-docs-event-sourcing */" + Scenario: Not confuse @architect-* with @architect opt-in + Given source code "/** @architect-event-sourcing */" When checking for file opt-in Then hasFileOptIn should return false diff --git a/tests/features/behavior/error-handling.feature b/tests/features/behavior/error-handling.feature index c37286e7..6e75b215 100644 --- a/tests/features/behavior/error-handling.feature +++ b/tests/features/behavior/error-handling.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:ErrorHandlingUnification -@libar-docs-status:completed -@libar-docs-product-area:CoreTypes -@libar-docs-include:core-types -@libar-docs-depends-on:ResultMonad,ErrorFactories +@architect +@architect-pattern:ErrorHandlingUnification +@architect-status:completed +@architect-product-area:CoreTypes +@architect-include:core-types +@architect-depends-on:ResultMonad,ErrorFactories @behavior @error-handling Feature: Error Handling Unification All CLI commands and extractors should use the DocError discriminated @@ -87,7 +87,7 @@ Feature: Error Handling Unification **Rationale:** console.warn bypasses error collection, making warnings invisible to callers and untestable. Structured error objects enable programmatic handling across all consumers. - **Verified by:** Errors include structured context, No console.warn bypasses error collection, Skip feature files without @libar-docs opt-in + **Verified by:** Errors include structured context, No console.warn bypasses error collection, Skip feature files without @architect opt-in @acceptance-criteria @extractor Scenario: Errors include structured context @@ -106,8 +106,8 @@ Feature: Error Handling Unification And console.warn should not have been called @edge-case @extractor @opt-in-required - Scenario: Skip feature files without @libar-docs opt-in - Given a Gherkin feature file without @libar-docs opt-in marker + Scenario: Skip feature files without @architect opt-in + Given a Gherkin feature file without @architect opt-in marker When patterns are extracted from Gherkin files Then no patterns should be extracted diff --git a/tests/features/behavior/extract-summary.feature b/tests/features/behavior/extract-summary.feature index d6cc3aea..304ef391 100644 --- a/tests/features/behavior/extract-summary.feature +++ b/tests/features/behavior/extract-summary.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:ExtractSummary -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:ExtractSummary +@architect-status:completed +@architect-product-area:Generation @renderable @utils Feature: Extract Summary from Pattern Descriptions The extractSummary function transforms multi-line pattern descriptions into diff --git a/tests/features/behavior/implementation-links.feature b/tests/features/behavior/implementation-links.feature index a77a4a3a..970e0f2c 100644 --- a/tests/features/behavior/implementation-links.feature +++ b/tests/features/behavior/implementation-links.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:ImplementationLinkPathNormalization -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:ImplementationLinkPathNormalization +@architect-status:completed +@architect-product-area:Generation Feature: Implementation Link Path Normalization Links to implementation files in generated pattern documents should have diff --git a/tests/features/behavior/kebab-case-slugs.feature b/tests/features/behavior/kebab-case-slugs.feature index ebd0295a..e42ee31e 100644 --- a/tests/features/behavior/kebab-case-slugs.feature +++ b/tests/features/behavior/kebab-case-slugs.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:KebabCaseSlugs -@libar-docs-status:completed -@libar-docs-unlock-reason:Retroactive-completion -@libar-docs-phase:44 -@libar-docs-product-area:CoreTypes -@libar-docs-include:core-types -@libar-docs-depends-on:StringUtils +@architect +@architect-pattern:KebabCaseSlugs +@architect-status:completed +@architect-unlock-reason:Retroactive-completion +@architect-phase:44 +@architect-product-area:CoreTypes +@architect-include:core-types +@architect-depends-on:StringUtils Feature: Slug Generation for Progressive Disclosure As a documentation generator diff --git a/tests/features/behavior/layer-inference.feature b/tests/features/behavior/layer-inference.feature index 2f16f3be..f5c6d30d 100644 --- a/tests/features/behavior/layer-inference.feature +++ b/tests/features/behavior/layer-inference.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:LayerInferenceTesting -@libar-docs-implements:LayerInference -@libar-docs-status:completed -@libar-docs-product-area:Annotation +@architect +@architect-pattern:LayerInferenceTesting +@architect-implements:LayerInference +@architect-status:completed +@architect-product-area:Annotation @behavior Feature: Layer Inference from Feature File Paths The layer inference module classifies feature files into testing layers @@ -26,7 +26,7 @@ Feature: Layer Inference from Feature File Paths **Invariant:** Any feature file path containing a /timeline/ directory segment is classified as timeline layer. **Rationale:** Timeline features track phased delivery progress and must be grouped separately for roadmap generation and phase filtering. - **Verified by:** Detect timeline features from /timeline/ path, Detect timeline features regardless of parent directories, Detect timeline features in delivery-process package + **Verified by:** Detect timeline features from /timeline/ path, Detect timeline features regardless of parent directories, Detect timeline features in Architect package @happy-path @timeline Scenario: Detect timeline features from /timeline/ path @@ -41,8 +41,8 @@ Feature: Layer Inference from Feature File Paths Then the inferred layer should be "timeline" @happy-path @timeline - Scenario: Detect timeline features in delivery-process package - Given the feature file path "packages/@libar-dev/delivery-process/tests/features/timeline/session-01.feature" + Scenario: Detect timeline features in Architect package + Given the feature file path "packages/@libar-dev/architect/tests/features/timeline/session-01.feature" When I infer the feature layer Then the inferred layer should be "timeline" diff --git a/tests/features/behavior/pattern-relationships/depends-on-tag.feature b/tests/features/behavior/pattern-relationships/depends-on-tag.feature index 324e952c..0d0f0982 100644 --- a/tests/features/behavior/pattern-relationships/depends-on-tag.feature +++ b/tests/features/behavior/pattern-relationships/depends-on-tag.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:DependsOnTagTesting -@libar-docs-status:active -@libar-docs-implements:PatternRelationshipModel -@libar-docs-product-area:Annotation +@architect +@architect-pattern:DependsOnTagTesting +@architect-status:active +@architect-implements:PatternRelationshipModel +@architect-product-area:Annotation @pattern-relationships Feature: Planning Dependency Tags - Tests extraction of @libar-docs-depends-on and @libar-docs-enables + Tests extraction of @architect-depends-on and @architect-enables relationship tags from Gherkin files. # =========================================================================== @@ -49,10 +49,10 @@ Feature: Planning Dependency Tags Scenario: Depends-on extracted from feature file Given a Gherkin file with tags: """gherkin - @libar-docs - @libar-docs-pattern:FeatureB - @libar-docs-status:roadmap - @libar-docs-depends-on:FeatureA + @architect + @architect-pattern:FeatureB + @architect-status:roadmap + @architect-depends-on:FeatureA Feature: Feature B """ When the Gherkin parser extracts metadata @@ -62,10 +62,10 @@ Feature: Planning Dependency Tags Scenario: Multiple depends-on values extracted as CSV Given a Gherkin file with tags: """gherkin - @libar-docs - @libar-docs-pattern:FeatureC - @libar-docs-status:roadmap - @libar-docs-depends-on:FeatureA,FeatureB + @architect + @architect-pattern:FeatureC + @architect-status:roadmap + @architect-depends-on:FeatureA,FeatureB Feature: Feature C """ When the Gherkin parser extracts metadata @@ -105,10 +105,10 @@ Feature: Planning Dependency Tags Scenario: Enables extracted from feature file Given a Gherkin file with tags: """gherkin - @libar-docs - @libar-docs-pattern:FeatureA - @libar-docs-status:active - @libar-docs-enables:FeatureB + @architect + @architect-pattern:FeatureA + @architect-status:active + @architect-enables:FeatureB Feature: Feature A """ When the Gherkin parser extracts metadata @@ -118,10 +118,10 @@ Feature: Planning Dependency Tags Scenario: Multiple enables values extracted as CSV Given a Gherkin file with tags: """gherkin - @libar-docs - @libar-docs-pattern:Foundation - @libar-docs-status:active - @libar-docs-enables:ServiceA,ServiceB + @architect + @architect-pattern:Foundation + @architect-status:active + @architect-enables:ServiceA,ServiceB Feature: Foundation """ When the Gherkin parser extracts metadata diff --git a/tests/features/behavior/pattern-relationships/extends-tag.feature b/tests/features/behavior/pattern-relationships/extends-tag.feature index 01c083d9..7c77c563 100644 --- a/tests/features/behavior/pattern-relationships/extends-tag.feature +++ b/tests/features/behavior/pattern-relationships/extends-tag.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:ExtendsTagTesting -@libar-docs-status:completed -@libar-docs-implements:PatternRelationshipModel -@libar-docs-product-area:Annotation +@architect +@architect-pattern:ExtendsTagTesting +@architect-status:completed +@architect-implements:PatternRelationshipModel +@architect-product-area:Annotation Feature: Extends Tag Extraction and Processing - Tests for the @libar-docs-extends tag which establishes generalization + Tests for the @architect-extends tag which establishes generalization relationships between patterns (pattern inheritance). # =========================================================================== @@ -43,9 +43,9 @@ Feature: Extends Tag Extraction and Processing Scenario: Parse extends from feature file Given a Gherkin file with tags: """gherkin - @libar-docs - @libar-docs-pattern:ReactiveProjections - @libar-docs-extends:ProjectionCategories + @architect + @architect-pattern:ReactiveProjections + @architect-extends:ProjectionCategories Feature: Reactive Projections """ When the Gherkin parser extracts metadata diff --git a/tests/features/behavior/pattern-relationships/implements-tag.feature b/tests/features/behavior/pattern-relationships/implements-tag.feature index 62c33ce8..5618dd87 100644 --- a/tests/features/behavior/pattern-relationships/implements-tag.feature +++ b/tests/features/behavior/pattern-relationships/implements-tag.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:ImplementsTagProcessing -@libar-docs-status:completed -@libar-docs-implements:PatternRelationshipModel -@libar-docs-product-area:Annotation +@architect +@architect-pattern:ImplementsTagProcessing +@architect-status:completed +@architect-implements:PatternRelationshipModel +@architect-product-area:Annotation Feature: Implements Tag Extraction and Processing - Tests for the @libar-docs-implements tag which links implementation files + Tests for the @architect-implements tag which links implementation files to their corresponding roadmap pattern specifications. # =========================================================================== @@ -44,9 +44,9 @@ Feature: Implements Tag Extraction and Processing Given a TypeScript file with content: """typescript /** - * @libar-docs - * @libar-docs-implements EventStoreDurability - * @libar-docs-status roadmap + * @architect + * @architect-implements EventStoreDurability + * @architect-status roadmap */ export function outbox() {} """ @@ -74,8 +74,8 @@ Feature: Implements Tag Extraction and Processing Given a TypeScript file with content: """typescript /** - * @libar-docs - * @libar-docs-implements EventStoreDurability, IdempotentAppend + * @architect + * @architect-implements EventStoreDurability, IdempotentAppend */ export function durabilityPrimitive() {} """ diff --git a/tests/features/behavior/pattern-relationships/linter-validation.feature b/tests/features/behavior/pattern-relationships/linter-validation.feature index d329fb1c..45dd6f64 100644 --- a/tests/features/behavior/pattern-relationships/linter-validation.feature +++ b/tests/features/behavior/pattern-relationships/linter-validation.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:LinterValidationTesting -@libar-docs-status:completed -@libar-docs-implements:PatternRelationshipModel -@libar-docs-product-area:Validation +@architect +@architect-pattern:LinterValidationTesting +@architect-status:completed +@architect-implements:PatternRelationshipModel +@architect-product-area:Validation Feature: Linter Rules for Relationship Validation Tests for lint rules that validate relationship integrity, detect conflicts, @@ -26,9 +26,9 @@ Feature: Linter Rules for Relationship Validation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-pattern:EventStoreDurability - * @libar-docs-implements:EventStoreDurability + * @architect + * @architect-pattern:EventStoreDurability + * @architect-implements:EventStoreDurability */ """ When the linter runs @@ -41,9 +41,9 @@ Feature: Linter Rules for Relationship Validation Given a TypeScript file with: """typescript /** - * @libar-docs - * @libar-docs-implements:EventStoreDurability - * @libar-docs-status:roadmap + * @architect + * @architect-implements:EventStoreDurability + * @architect-status:roadmap */ """ When the linter runs diff --git a/tests/features/behavior/pattern-relationships/mermaid-rendering.feature b/tests/features/behavior/pattern-relationships/mermaid-rendering.feature index 85921ee2..830c8fe5 100644 --- a/tests/features/behavior/pattern-relationships/mermaid-rendering.feature +++ b/tests/features/behavior/pattern-relationships/mermaid-rendering.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:MermaidRelationshipRendering -@libar-docs-status:completed -@libar-docs-implements:PatternRelationshipModel -@libar-docs-product-area:Generation +@architect +@architect-pattern:MermaidRelationshipRendering +@architect-status:completed +@architect-implements:PatternRelationshipModel +@architect-product-area:Generation Feature: Mermaid Graph Rendering for Relationships Tests for rendering all relationship types in Mermaid dependency graphs diff --git a/tests/features/behavior/pattern-relationships/uses-tag.feature b/tests/features/behavior/pattern-relationships/uses-tag.feature index a5b01ce9..9f1b7980 100644 --- a/tests/features/behavior/pattern-relationships/uses-tag.feature +++ b/tests/features/behavior/pattern-relationships/uses-tag.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:UsesTagTesting -@libar-docs-status:active -@libar-docs-implements:PatternRelationshipModel -@libar-docs-product-area:Annotation +@architect +@architect-pattern:UsesTagTesting +@architect-status:active +@architect-implements:PatternRelationshipModel +@architect-product-area:Annotation @pattern-relationships Feature: Uses Tag Extraction - Tests extraction and processing of @libar-docs-uses and @libar-docs-used-by + Tests extraction and processing of @architect-uses and @architect-used-by relationship tags from TypeScript files. # =========================================================================== @@ -50,10 +50,10 @@ Feature: Uses Tag Extraction Given a TypeScript file with content: """typescript /** - * @libar-docs - * @libar-docs-pattern ServiceA - * @libar-docs-status active - * @libar-docs-uses ServiceB + * @architect + * @architect-pattern ServiceA + * @architect-status active + * @architect-uses ServiceB */ export class ServiceA {} """ @@ -65,10 +65,10 @@ Feature: Uses Tag Extraction Given a TypeScript file with content: """typescript /** - * @libar-docs - * @libar-docs-pattern Orchestrator - * @libar-docs-status active - * @libar-docs-uses ServiceA, ServiceB, ServiceC + * @architect + * @architect-pattern Orchestrator + * @architect-status active + * @architect-uses ServiceA, ServiceB, ServiceC */ export class Orchestrator {} """ @@ -90,10 +90,10 @@ Feature: Uses Tag Extraction Given a TypeScript file with content: """typescript /** - * @libar-docs - * @libar-docs-pattern CoreService - * @libar-docs-status active - * @libar-docs-used-by HighLevelOrchestrator + * @architect + * @architect-pattern CoreService + * @architect-status active + * @architect-used-by HighLevelOrchestrator */ export class CoreService {} """ @@ -105,10 +105,10 @@ Feature: Uses Tag Extraction Given a TypeScript file with content: """typescript /** - * @libar-docs - * @libar-docs-pattern Foundation - * @libar-docs-status active - * @libar-docs-used-by ServiceA, ServiceB + * @architect + * @architect-pattern Foundation + * @architect-status active + * @architect-used-by ServiceA, ServiceB */ export class Foundation {} """ diff --git a/tests/features/behavior/pattern-tag-extraction.feature b/tests/features/behavior/pattern-tag-extraction.feature index de904a68..1f0b1112 100644 --- a/tests/features/behavior/pattern-tag-extraction.feature +++ b/tests/features/behavior/pattern-tag-extraction.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:PatternTagExtraction -@libar-docs-status:completed -@libar-docs-product-area:Annotation +@architect +@architect-pattern:PatternTagExtraction +@architect-status:completed +@architect-product-area:Annotation @behavior @scanner @pattern-tags Feature: Pattern Tag Extraction from Gherkin Feature Tags The extractPatternTags function parses Gherkin feature tags diff --git a/tests/features/behavior/patterns-codec.feature b/tests/features/behavior/patterns-codec.feature index d663125f..e4550761 100644 --- a/tests/features/behavior/patterns-codec.feature +++ b/tests/features/behavior/patterns-codec.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:PatternsCodecTesting -@libar-docs-implements:PatternsCodec -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:PatternsCodecTesting +@architect-implements:PatternsCodec +@architect-status:completed +@architect-product-area:Generation @behavior @patterns-codec Feature: Patterns Document Codec The PatternsDocumentCodec transforms MasterDataset into a RenderableDocument diff --git a/tests/features/behavior/pr-changes-generation.feature b/tests/features/behavior/pr-changes-generation.feature index 7d97d167..45c3ed83 100644 --- a/tests/features/behavior/pr-changes-generation.feature +++ b/tests/features/behavior/pr-changes-generation.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:PrChangesGeneration -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:PrChangesGeneration +@architect-status:completed +@architect-product-area:Generation @behavior @pr-changes Feature: PR Changes Generation The delivery process generates PR-CHANGES.md from active or completed phases, diff --git a/tests/features/behavior/remaining-work-enhancement.feature b/tests/features/behavior/remaining-work-enhancement.feature index 86eed2fa..b3a3dbcb 100644 --- a/tests/features/behavior/remaining-work-enhancement.feature +++ b/tests/features/behavior/remaining-work-enhancement.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:RemainingWorkEnhancement -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:RemainingWorkEnhancement +@architect-status:completed +@architect-product-area:Generation @behavior @remaining-work Feature: Remaining Work Enhancement Enhanced REMAINING-WORK.md generation with priority-based sorting, diff --git a/tests/features/behavior/remaining-work-totals.feature b/tests/features/behavior/remaining-work-totals.feature index bfc1030e..79dc1c2f 100644 --- a/tests/features/behavior/remaining-work-totals.feature +++ b/tests/features/behavior/remaining-work-totals.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:RemainingWorkSummaryAccuracy -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:RemainingWorkSummaryAccuracy +@architect-status:completed +@architect-product-area:Generation Feature: Remaining Work Summary Accuracy Summary totals in REMAINING-WORK.md must match the sum of phase table rows. diff --git a/tests/features/behavior/render-blocks.feature b/tests/features/behavior/render-blocks.feature index ceeb73e4..cc355b13 100644 --- a/tests/features/behavior/render-blocks.feature +++ b/tests/features/behavior/render-blocks.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:RendererBlockTypes -@libar-docs-implements:UniversalMarkdownRenderer -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-product-area:Generation +@architect +@architect-pattern:RendererBlockTypes +@architect-implements:UniversalMarkdownRenderer +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-product-area:Generation @behavior @render Feature: Universal Markdown Renderer - Block Types The universal renderer converts RenderableDocument to markdown. diff --git a/tests/features/behavior/render-output.feature b/tests/features/behavior/render-output.feature index dd7fdeb7..8ea54a63 100644 --- a/tests/features/behavior/render-output.feature +++ b/tests/features/behavior/render-output.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:RendererOutputFormats -@libar-docs-implements:UniversalMarkdownRenderer -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:RendererOutputFormats +@architect-implements:UniversalMarkdownRenderer +@architect-status:completed +@architect-product-area:Generation @behavior @render Feature: Universal Markdown Renderer - Output Formats The universal renderer converts RenderableDocument to markdown. diff --git a/tests/features/behavior/rich-content-helpers.feature b/tests/features/behavior/rich-content-helpers.feature index fa2888fc..90b50e8c 100644 --- a/tests/features/behavior/rich-content-helpers.feature +++ b/tests/features/behavior/rich-content-helpers.feature @@ -1,10 +1,10 @@ -@libar-docs -@libar-docs-pattern:RichContentHelpersTesting -@libar-docs-implements:RichContentHelpers -@libar-docs-status:completed -@libar-docs-unlock-reason:Retroactive-completion -@libar-docs-phase:44 -@libar-docs-product-area:Generation +@architect +@architect-pattern:RichContentHelpersTesting +@architect-implements:RichContentHelpers +@architect-status:completed +@architect-unlock-reason:Retroactive-completion +@architect-phase:44 +@architect-product-area:Generation @behavior Feature: Rich Content Rendering Helpers diff --git a/tests/features/behavior/scanner-core.feature b/tests/features/behavior/scanner-core.feature index 7561b55e..e0b88ade 100644 --- a/tests/features/behavior/scanner-core.feature +++ b/tests/features/behavior/scanner-core.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:ScannerCore -@libar-docs-status:completed -@libar-docs-product-area:Annotation +@architect +@architect-pattern:ScannerCore +@architect-status:completed +@architect-product-area:Annotation @behavior @scanner-core Feature: Scanner Core Integration The scanPatterns function orchestrates file discovery, directive detection, @@ -9,7 +9,7 @@ Feature: Scanner Core Integration **Problem:** - Need to scan entire codebases for documentation directives efficiently - - Files without @libar-docs opt-in should be skipped to save processing time + - Files without @architect opt-in should be skipped to save processing time - Parse errors in one file shouldn't prevent scanning of other files - Must support exclusion patterns for node_modules, tests, and custom paths @@ -36,11 +36,11 @@ Feature: Scanner Core Integration Given a file "src/auth.ts" with content: """ /** - * @libar-docs + * @architect */ /** - * @libar-docs-core @libar-docs-security + * @architect-core @architect-security * Authentication utilities */ export function authenticate(username: string, password: string): boolean { @@ -51,7 +51,7 @@ Feature: Scanner Core Integration Then the scan should succeed with 1 file And the scan should have 0 errors And file "auth.ts" should have 1 directive - And the directive should have tag "@libar-docs-core" + And the directive should have tag "@architect-core" And the directive should have 1 export @happy-path @basic-scanning @@ -70,10 +70,10 @@ Feature: Scanner Core Integration Scenario: Extract complete directive information Given a file "src/complete.ts" with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core @libar-docs-validation + * @architect-core @architect-validation * Validates user input * * This function performs comprehensive validation @@ -91,7 +91,7 @@ Feature: Scanner Core Integration When scanning with pattern "src/**/*.ts" Then the scan should succeed with 1 file And the scan should have 0 errors - And the directive should have tags "@libar-docs-core" and "@libar-docs-validation" + And the directive should have tags "@architect-core" and "@architect-validation" And the directive description should contain "Validates user input" And the directive description should also contain "comprehensive validation" And the directive should have 1 example @@ -112,10 +112,10 @@ Feature: Scanner Core Integration Scenario: Collect errors for files that fail to parse Given a file "src/valid.ts" with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * Valid file */ export function valid() { @@ -124,10 +124,10 @@ Feature: Scanner Core Integration """ And a file "src/invalid.ts" with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * This will fail */ export function broken( @@ -170,20 +170,20 @@ Feature: Scanner Core Integration Scenario: Respect exclusion patterns Given a file "src/public.ts" with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * Public API */ export function publicApi() {} """ And a file "src/internal/secret.ts" with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * Internal implementation */ export function internalImpl() {} @@ -197,26 +197,26 @@ Feature: Scanner Core Integration Scenario: Handle multiple files with multiple directives each Given a file "src/file1.ts" with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * First directive */ export function first() {} /** - * @libar-docs-domain + * @architect-domain * Second directive */ export function second() {} """ And a file "src/file2.ts" with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-validation + * @architect-validation * Third directive */ export function third() {} @@ -229,11 +229,11 @@ Feature: Scanner Core Integration Rule: File opt-in requirement gates scanning - **Invariant:** Only files containing a standalone @libar-docs marker (not @libar-docs-*) are eligible for directive extraction. + **Invariant:** Only files containing a standalone @architect marker (not @architect-*) are eligible for directive extraction. **Rationale:** Without opt-in gating, every TypeScript file in the monorepo would be parsed, wasting processing time on files that have no documentation directives. - **Verified by:** Handle files with quick directive check optimization, Skip files without @libar-docs file-level opt-in, Not confuse @libar-docs-* with @libar-docs opt-in, Detect @libar-docs opt-in combined with section tags + **Verified by:** Handle files with quick directive check optimization, Skip files without @architect file-level opt-in, Not confuse @architect-* with @architect opt-in, Detect @architect opt-in combined with section tags @happy-path @optimization Scenario: Handle files with quick directive check optimization @@ -245,10 +245,10 @@ Feature: Scanner Core Integration """ And a file "src/with-docs.ts" with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * Documented */ export function documented() { @@ -260,21 +260,21 @@ Feature: Scanner Core Integration And file "with-docs.ts" should be in the results @edge-case @opt-in-required - Scenario: Skip files without @libar-docs file-level opt-in + Scenario: Skip files without @architect file-level opt-in Given a file "src/no-optin.ts" with content: """ /** - * @libar-docs-core + * @architect-core * This file has section tags but no file-level opt-in */ export function noOptIn() {} """ And a file "src/with-optin.ts" with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * This file has proper opt-in */ export function withOptIn() {} @@ -285,11 +285,11 @@ Feature: Scanner Core Integration And the scan should have 0 errors @edge-case @opt-in-distinction - Scenario: Not confuse @libar-docs-* with @libar-docs opt-in + Scenario: Not confuse @architect-* with @architect opt-in Given a file "src/section-only.ts" with content: """ /** - * @libar-docs-core @libar-docs-event-sourcing + * @architect-core @architect-event-sourcing * Multiple section tags but no opt-in */ export function sectionOnly() {} @@ -299,11 +299,11 @@ Feature: Scanner Core Integration And the scan should have 0 errors @happy-path @opt-in-combined - Scenario: Detect @libar-docs opt-in combined with section tags + Scenario: Detect @architect opt-in combined with section tags Given a file "src/combined.ts" with content: """ /** - * @libar-docs @libar-docs-core + * @architect @architect-core * Combined opt-in and section tag */ export function combined() {} @@ -311,5 +311,5 @@ Feature: Scanner Core Integration When scanning with pattern "src/**/*.ts" Then the scan should succeed with 1 file And file "combined.ts" should have 1 directive - And the directive should have tag "@libar-docs-core" + And the directive should have tag "@architect-core" And the scan should have 0 errors diff --git a/tests/features/behavior/session-file-lifecycle.feature b/tests/features/behavior/session-file-lifecycle.feature index 2ce21835..677a4230 100644 --- a/tests/features/behavior/session-file-lifecycle.feature +++ b/tests/features/behavior/session-file-lifecycle.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:SessionFileLifecycle -@libar-docs-status:completed -@libar-docs-unlock-reason:Add-process-workflow-include-tag -@libar-docs-product-area:Process -@libar-docs-include:process-workflow +@architect +@architect-pattern:SessionFileLifecycle +@architect-status:completed +@architect-unlock-reason:Add-process-workflow-include-tag +@architect-product-area:Process +@architect-include:process-workflow @behavior @session-lifecycle Feature: Session File Lifecycle Management Orphaned session files are automatically cleaned up during generation, diff --git a/tests/features/behavior/session-handoffs.feature b/tests/features/behavior/session-handoffs.feature index c452fbfa..0059e27d 100644 --- a/tests/features/behavior/session-handoffs.feature +++ b/tests/features/behavior/session-handoffs.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:SessionHandoffs -@libar-docs-status:completed -@libar-docs-unlock-reason:Add-process-workflow-include-tag -@libar-docs-product-area:Process -@libar-docs-include:process-workflow +@architect +@architect-pattern:SessionHandoffs +@architect-status:completed +@architect-unlock-reason:Add-process-workflow-include-tag +@architect-product-area:Process +@architect-include:process-workflow @behavior @session-handoffs Feature: Session Handoffs and Multi-Developer Coordination The delivery process supports mid-phase handoffs between sessions and diff --git a/tests/features/behavior/transform-dataset.feature b/tests/features/behavior/transform-dataset.feature index 6ae4c62c..6a4677cd 100644 --- a/tests/features/behavior/transform-dataset.feature +++ b/tests/features/behavior/transform-dataset.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:TransformDatasetTesting -@libar-docs-implements:TransformDataset -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:TransformDatasetTesting +@architect-implements:TransformDataset +@architect-status:completed +@architect-product-area:Generation @behavior @transform-dataset Feature: Transform Dataset Pipeline The transformToMasterDataset function transforms raw extracted patterns diff --git a/tests/features/cli/data-api-cache.feature b/tests/features/cli/data-api-cache.feature index c1d5dd64..a44bd45a 100644 --- a/tests/features/cli/data-api-cache.feature +++ b/tests/features/cli/data-api-cache.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ProcessApiCliCache -@libar-docs-implements:DataAPICLIErgonomics -@libar-docs-status:active -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:ProcessApiCliCache +@architect-implements:DataAPICLIErgonomics +@architect-status:active +@architect-product-area:DataAPI @cli @process-api @cache Feature: Process API CLI - Dataset Cache MasterDataset caching between CLI invocations: cache hits, mtime invalidation, and --no-cache bypass. diff --git a/tests/features/cli/data-api-dryrun.feature b/tests/features/cli/data-api-dryrun.feature index 8b151163..1e14ed57 100644 --- a/tests/features/cli/data-api-dryrun.feature +++ b/tests/features/cli/data-api-dryrun.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ProcessApiCliDryRun -@libar-docs-implements:DataAPICLIErgonomics -@libar-docs-status:active -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:ProcessApiCliDryRun +@architect-implements:DataAPICLIErgonomics +@architect-status:active +@architect-product-area:DataAPI @cli @process-api @dry-run Feature: Process API CLI - Dry Run Dry-run mode shows pipeline scope without processing data. diff --git a/tests/features/cli/data-api-help.feature b/tests/features/cli/data-api-help.feature index 62388303..789b9c22 100644 --- a/tests/features/cli/data-api-help.feature +++ b/tests/features/cli/data-api-help.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ProcessApiCliHelp -@libar-docs-implements:DataAPICLIErgonomics -@libar-docs-status:active -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:ProcessApiCliHelp +@architect-implements:DataAPICLIErgonomics +@architect-status:active +@architect-product-area:DataAPI @cli @process-api @help Feature: Process API CLI - Per-Subcommand Help Per-subcommand help displays usage, flags, and examples for individual subcommands. diff --git a/tests/features/cli/data-api-metadata.feature b/tests/features/cli/data-api-metadata.feature index f1be8ff9..e88a3c84 100644 --- a/tests/features/cli/data-api-metadata.feature +++ b/tests/features/cli/data-api-metadata.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ProcessApiCliMetadata -@libar-docs-implements:DataAPICLIErgonomics -@libar-docs-status:active -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:ProcessApiCliMetadata +@architect-implements:DataAPICLIErgonomics +@architect-status:active +@architect-product-area:DataAPI @cli @process-api @metadata Feature: Process API CLI - Response Metadata Response metadata includes validation summary and pipeline timing for diagnostics. diff --git a/tests/features/cli/data-api-repl.feature b/tests/features/cli/data-api-repl.feature index d14d4760..de898ea4 100644 --- a/tests/features/cli/data-api-repl.feature +++ b/tests/features/cli/data-api-repl.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ProcessApiCliRepl -@libar-docs-implements:DataAPICLIErgonomics -@libar-docs-status:active -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:ProcessApiCliRepl +@architect-implements:DataAPICLIErgonomics +@architect-status:active +@architect-product-area:DataAPI @cli @process-api @repl Feature: Process API CLI - REPL Mode Interactive REPL mode keeps the pipeline loaded for multi-query sessions and supports reload. diff --git a/tests/features/cli/generate-docs.feature b/tests/features/cli/generate-docs.feature index 4d160add..dadab8a3 100644 --- a/tests/features/cli/generate-docs.feature +++ b/tests/features/cli/generate-docs.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:GenerateDocsCli -@libar-docs-status:completed -@libar-docs-product-area:DataAPI -@libar-docs-implements:CliBehaviorTesting +@architect +@architect-pattern:GenerateDocsCli +@architect-status:completed +@architect-product-area:DataAPI +@architect-implements:CliBehaviorTesting @cli @generate-docs Feature: generate-docs CLI Command-line interface for generating documentation from annotated TypeScript. diff --git a/tests/features/cli/generate-tag-taxonomy.feature b/tests/features/cli/generate-tag-taxonomy.feature index 5cc850d0..daca13f5 100644 --- a/tests/features/cli/generate-tag-taxonomy.feature +++ b/tests/features/cli/generate-tag-taxonomy.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:GenerateTagTaxonomyCli -@libar-docs-status:completed -@libar-docs-product-area:DataAPI -@libar-docs-implements:CliBehaviorTesting +@architect +@architect-pattern:GenerateTagTaxonomyCli +@architect-status:completed +@architect-product-area:DataAPI +@architect-implements:CliBehaviorTesting @cli @generate-tag-taxonomy Feature: generate-tag-taxonomy CLI Command-line interface for generating TAG_TAXONOMY.md from tag registry configuration. @@ -36,7 +36,7 @@ Feature: generate-tag-taxonomy CLI Scenario: Display version with --version flag When running "generate-tag-taxonomy --version" Then exit code is 0 - And stdout contains "generate-tag-taxonomy" + And stdout contains "architect-taxonomy" @happy-path Scenario: Display version with -v flag diff --git a/tests/features/cli/lint-patterns.feature b/tests/features/cli/lint-patterns.feature index ed547c3d..f189a86d 100644 --- a/tests/features/cli/lint-patterns.feature +++ b/tests/features/cli/lint-patterns.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:LintPatternsCli -@libar-docs-status:completed -@libar-docs-product-area:DataAPI -@libar-docs-implements:CliBehaviorTesting +@architect +@architect-pattern:LintPatternsCli +@architect-status:completed +@architect-product-area:DataAPI +@architect-implements:CliBehaviorTesting @cli @lint-patterns Feature: lint-patterns CLI Command-line interface for validating pattern annotation quality. diff --git a/tests/features/cli/lint-process.feature b/tests/features/cli/lint-process.feature index ad279cd0..e5992950 100644 --- a/tests/features/cli/lint-process.feature +++ b/tests/features/cli/lint-process.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:LintProcessCli -@libar-docs-status:completed -@libar-docs-product-area:DataAPI -@libar-docs-implements:CliBehaviorTesting +@architect +@architect-pattern:LintProcessCli +@architect-status:completed +@architect-product-area:DataAPI +@architect-implements:CliBehaviorTesting @cli @lint-process Feature: lint-process CLI Command-line interface for validating changes against delivery process rules. @@ -36,7 +36,7 @@ Feature: lint-process CLI Scenario: Display version with --version flag When running "lint-process --version" Then exit code is 0 - And stdout contains "lint-process" + And stdout contains "architect-guard" @happy-path Scenario: Display version with -v flag diff --git a/tests/features/cli/process-api-core.feature b/tests/features/cli/process-api-core.feature index e9ab484c..e2db69f6 100644 --- a/tests/features/cli/process-api-core.feature +++ b/tests/features/cli/process-api-core.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:ProcessApiCliCore -@libar-docs-implements:ProcessApiCli -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:ProcessApiCliCore +@architect-implements:ProcessApiCli +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-product-area:DataAPI @cli @process-api Feature: Process API CLI - Core Infrastructure Core CLI infrastructure: help, version, input validation, status, query, pattern, arch basics, missing args, edge cases. diff --git a/tests/features/cli/process-api-modifiers-rules.feature b/tests/features/cli/process-api-modifiers-rules.feature index 8663f179..f4f0dc22 100644 --- a/tests/features/cli/process-api-modifiers-rules.feature +++ b/tests/features/cli/process-api-modifiers-rules.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:ProcessApiCliModifiersAndRules -@libar-docs-implements:ProcessApiCli -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:ProcessApiCliModifiersAndRules +@architect-implements:ProcessApiCli +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-product-area:DataAPI @cli @process-api Feature: Process API CLI - Output Modifiers and Rules Output modifiers, arch health, and rules subcommand. diff --git a/tests/features/cli/process-api-subcommands.feature b/tests/features/cli/process-api-subcommands.feature index cab28ae1..4d2a295c 100644 --- a/tests/features/cli/process-api-subcommands.feature +++ b/tests/features/cli/process-api-subcommands.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:ProcessApiCliSubcommands -@libar-docs-implements:ProcessApiCli -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-product-area:DataAPI +@architect +@architect-pattern:ProcessApiCliSubcommands +@architect-implements:ProcessApiCli +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-product-area:DataAPI @cli @process-api Feature: Process API CLI - Discovery Subcommands Discovery subcommands: list, search, context assembly, tags/sources, extended arch, unannotated. @@ -157,7 +157,7 @@ Feature: Process API CLI - Discovery Subcommands Rule: CLI unannotated subcommand finds files without annotations - **Invariant:** The unannotated subcommand must return valid JSON listing every TypeScript file that lacks the `@libar-docs` opt-in marker. + **Invariant:** The unannotated subcommand must return valid JSON listing every TypeScript file that lacks the `@architect` opt-in marker. **Rationale:** Files missing the opt-in marker are invisible to the scanner; without this subcommand, unannotated files silently drop out of generated documentation and validation. @happy-path diff --git a/tests/features/cli/validate-patterns.feature b/tests/features/cli/validate-patterns.feature index bac91a52..02288cff 100644 --- a/tests/features/cli/validate-patterns.feature +++ b/tests/features/cli/validate-patterns.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ValidatePatternsCli -@libar-docs-status:completed -@libar-docs-product-area:DataAPI -@libar-docs-implements:CliBehaviorTesting +@architect +@architect-pattern:ValidatePatternsCli +@architect-status:completed +@architect-product-area:DataAPI +@architect-implements:CliBehaviorTesting @cli @validate-patterns Feature: validate-patterns CLI Command-line interface for cross-validating TypeScript patterns vs Gherkin feature files. @@ -36,7 +36,7 @@ Feature: validate-patterns CLI Scenario: Display version with --version flag When running "validate-patterns --version" Then exit code is 0 - And stdout contains "validate-patterns" + And stdout contains "architect-validate" @happy-path Scenario: Display version with -v flag diff --git a/tests/features/config/config-loader.feature b/tests/features/config/config-loader.feature index 22551e96..3b779690 100644 --- a/tests/features/config/config-loader.feature +++ b/tests/features/config/config-loader.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:ConfigLoaderTesting -@libar-docs-implements:ConfigLoader -@libar-docs-status:completed -@libar-docs-product-area:Configuration +@architect +@architect-pattern:ConfigLoaderTesting +@architect-implements:ConfigLoader +@architect-status:completed +@architect-product-area:Configuration @behavior @config Feature: Config Loader - TypeScript Configuration Discovery - The config loader discovers and loads `delivery-process.config.ts` files + The config loader discovers and loads `architect.config.ts` files for hierarchical configuration, enabling package-level and repo-level taxonomy customization. @@ -15,7 +15,7 @@ Feature: Config Loader - TypeScript Configuration Discovery - CLI tools need automatic config discovery **Solution:** - - Walk up directories looking for `delivery-process.config.ts` + - Walk up directories looking for `architect.config.ts` - Stop at repo root (.git marker) - Fall back to libar-generic preset (3 categories) if no config found @@ -36,30 +36,30 @@ Feature: Config Loader - TypeScript Configuration Discovery Scenario: Find config file in current directory Given a directory structure: | path | type | - | delivery-process.config.js | config | + | architect.config.js | config | When finding config file from the base directory Then config file should be found - And config path should end with "delivery-process.config.js" + And config path should end with "architect.config.js" @happy-path Scenario: Find config file in parent directory Given a directory structure: | path | type | - | delivery-process.config.js | config | + | architect.config.js | config | | nested/src/file.ts | source | When finding config file from "nested/src" Then config file should be found - And config path should end with "delivery-process.config.js" + And config path should end with "architect.config.js" @happy-path Scenario: Prefer TypeScript config over JavaScript Given a directory structure: | path | type | - | delivery-process.config.ts | config | - | delivery-process.config.js | config | + | architect.config.ts | config | + | architect.config.js | config | When finding config file from the base directory Then config file should be found - And config path should end with "delivery-process.config.ts" + And config path should end with "architect.config.ts" @edge-case Scenario: Return null when no config file exists @@ -84,7 +84,7 @@ Feature: Config Loader - TypeScript Configuration Discovery Given a directory structure: | path | type | | .git/config | git | - | delivery-process.config.js | config | + | architect.config.js | config | | project/nested/src/file.ts | source | When finding config file from "project/nested/src" Then config file should be found @@ -106,7 +106,7 @@ Feature: Config Loader - TypeScript Configuration Discovery When loading config from base directory Then config loading should succeed And loaded config should be the default - And loaded registry tagPrefix should be "@libar-docs-" + And loaded registry tagPrefix should be "@architect-" And loaded registry should have exactly 3 categories @happy-path @@ -129,7 +129,7 @@ Feature: Config Loader - TypeScript Configuration Discovery Given a config file exporting wrong type When loading config from base directory Then config loading should fail - And config error message should contain "DeliveryProcessInstance" + And config error message should contain "ArchitectInstance" # ========================================================================== # Error Formatting diff --git a/tests/features/config/config-resolution.feature b/tests/features/config/config-resolution.feature index 59be0bef..bd3b4ace 100644 --- a/tests/features/config/config-resolution.feature +++ b/tests/features/config/config-resolution.feature @@ -1,10 +1,10 @@ -@libar-docs -@libar-docs-pattern:ConfigResolution -@libar-docs-status:completed -@libar-docs-product-area:Configuration +@architect +@architect-pattern:ConfigResolution +@architect-status:completed +@architect-product-area:Configuration @behavior @config Feature: Config Resolution - Defaults and Merging - resolveProjectConfig transforms a raw DeliveryProcessProjectConfig into + resolveProjectConfig transforms a raw ArchitectProjectConfig into a fully resolved ResolvedConfig with all defaults applied. **Problem:** @@ -45,7 +45,7 @@ Feature: Config Resolution - Defaults and Merging Given a raw config with preset "libar-generic" When resolving the project config Then the instance should have 3 categories - And the instance tagPrefix should be "@libar-docs-" + And the instance tagPrefix should be "@architect-" Rule: Stubs are merged into typescript sources diff --git a/tests/features/config/configuration-api.feature b/tests/features/config/configuration-api.feature index 5dcad0eb..38843109 100644 --- a/tests/features/config/configuration-api.feature +++ b/tests/features/config/configuration-api.feature @@ -1,10 +1,10 @@ -@libar-docs -@libar-docs-pattern:ConfigurationAPI -@libar-docs-status:completed -@libar-docs-product-area:Configuration +@architect +@architect-pattern:ConfigurationAPI +@architect-status:completed +@architect-product-area:Configuration @behavior @configuration Feature: Configuration API for Open-Sourcing - The createDeliveryProcess factory provides a type-safe way to configure + The createArchitect factory provides a type-safe way to configure the delivery process with custom tag prefixes and presets. **Problem:** @@ -13,7 +13,7 @@ Feature: Configuration API for Open-Sourcing - Configuration should be type-safe and validated **Solution:** - - createDeliveryProcess() factory with preset support + - createArchitect() factory with preset support - Custom tagPrefix and fileOptInTag overrides - Type-safe configuration with generics @@ -32,30 +32,30 @@ Feature: Configuration API for Open-Sourcing @happy-path Scenario: Create with no arguments uses libar-generic preset - When I call createDeliveryProcess without arguments - Then the registry tagPrefix should be "@libar-docs-" - And the registry fileOptInTag should be "@libar-docs" + When I call createArchitect without arguments + Then the registry tagPrefix should be "@architect-" + And the registry fileOptInTag should be "@architect" And the registry should have exactly 3 categories @happy-path Scenario: Create with generic preset - When I call createDeliveryProcess with preset "generic" + When I call createArchitect with preset "generic" Then the registry tagPrefix should be "@docs-" And the registry fileOptInTag should be "@docs" And the registry should have exactly 3 categories @happy-path Scenario: Create with libar-generic preset - When I call createDeliveryProcess with preset "libar-generic" - Then the registry tagPrefix should be "@libar-docs-" - And the registry fileOptInTag should be "@libar-docs" + When I call createArchitect with preset "libar-generic" + Then the registry tagPrefix should be "@architect-" + And the registry fileOptInTag should be "@architect" And the registry should have exactly 3 categories @happy-path Scenario: Create with ddd-es-cqrs preset explicitly - When I call createDeliveryProcess with preset "ddd-es-cqrs" - Then the registry tagPrefix should be "@libar-docs-" - And the registry fileOptInTag should be "@libar-docs" + When I call createArchitect with preset "ddd-es-cqrs" + Then the registry tagPrefix should be "@architect-" + And the registry fileOptInTag should be "@architect" And the registry should have 21 categories # ========================================================================== @@ -70,17 +70,17 @@ Feature: Configuration API for Open-Sourcing @happy-path Scenario: Custom tag prefix overrides preset - When I call createDeliveryProcess with tagPrefix "@custom-" + When I call createArchitect with tagPrefix "@custom-" Then the registry tagPrefix should be "@custom-" @happy-path Scenario: Custom file opt-in tag overrides preset - When I call createDeliveryProcess with fileOptInTag "@my-docs" + When I call createArchitect with fileOptInTag "@my-docs" Then the registry fileOptInTag should be "@my-docs" @happy-path Scenario: Both prefix and opt-in tag can be customized together - When I call createDeliveryProcess with tagPrefix "@proj-" and fileOptInTag "@proj" + When I call createArchitect with tagPrefix "@proj-" and fileOptInTag "@proj" Then the registry tagPrefix should be "@proj-" And the registry fileOptInTag should be "@proj" @@ -96,7 +96,7 @@ Feature: Configuration API for Open-Sourcing @happy-path Scenario: Generic preset excludes DDD categories - When I call createDeliveryProcess with preset "generic" + When I call createArchitect with preset "generic" Then the registry should NOT include category "ddd" And the registry should NOT include category "event-sourcing" And the registry should NOT include category "cqrs" @@ -104,7 +104,7 @@ Feature: Configuration API for Open-Sourcing @happy-path Scenario: Libar-generic preset excludes DDD categories - When I call createDeliveryProcess with preset "libar-generic" + When I call createArchitect with preset "libar-generic" Then the registry should NOT include category "ddd" And the registry should NOT include category "event-sourcing" And the registry should NOT include category "cqrs" diff --git a/tests/features/config/define-config.feature b/tests/features/config/define-config.feature index 56ee4648..b432b162 100644 --- a/tests/features/config/define-config.feature +++ b/tests/features/config/define-config.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:DefineConfigTesting -@libar-docs-implements:DefineConfig -@libar-docs-status:completed -@libar-docs-product-area:Configuration +@architect +@architect-pattern:DefineConfigTesting +@architect-implements:DefineConfig +@architect-status:completed +@architect-product-area:Configuration @behavior @config Feature: Define Config - Schema Validation and Type Guards - The defineConfig identity function and DeliveryProcessProjectConfigSchema + The defineConfig identity function and ArchitectProjectConfigSchema provide type-safe configuration authoring with runtime validation. **Problem:** @@ -42,13 +42,13 @@ Feature: Define Config - Schema Validation and Type Guards @happy-path Scenario: Valid minimal config passes validation Given a config object with only preset "libar-generic" - When validating against DeliveryProcessProjectConfigSchema + When validating against ArchitectProjectConfigSchema Then validation should succeed @happy-path Scenario: Valid full config passes validation Given a config object with all fields populated - When validating against DeliveryProcessProjectConfigSchema + When validating against ArchitectProjectConfigSchema Then validation should succeed Rule: Schema rejects invalid configurations @@ -60,14 +60,14 @@ Feature: Define Config - Schema Validation and Type Guards @validation Scenario: Empty glob pattern rejected Given a config with an empty string in typescript sources - When validating against DeliveryProcessProjectConfigSchema + When validating against ArchitectProjectConfigSchema Then validation should fail And the validation error should contain "empty" @validation Scenario: Parent directory traversal rejected in globs Given a config with a glob containing ".." - When validating against DeliveryProcessProjectConfigSchema + When validating against ArchitectProjectConfigSchema Then validation should fail And the validation error should contain "parent directory traversal" @@ -81,13 +81,13 @@ Feature: Define Config - Schema Validation and Type Guards @validation Scenario: Invalid preset name rejected Given a config object with preset "nonexistent-preset" - When validating against DeliveryProcessProjectConfigSchema + When validating against ArchitectProjectConfigSchema Then validation should fail @validation Scenario: Unknown fields rejected in strict mode Given a config object with an unknown field "foobar" - When validating against DeliveryProcessProjectConfigSchema + When validating against ArchitectProjectConfigSchema Then validation should fail Rule: Type guards distinguish config formats diff --git a/tests/features/config/preset-system.feature b/tests/features/config/preset-system.feature index 30738e11..b6e5b234 100644 --- a/tests/features/config/preset-system.feature +++ b/tests/features/config/preset-system.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:PresetSystem -@libar-docs-status:completed -@libar-docs-product-area:Configuration +@architect +@architect-pattern:PresetSystem +@architect-status:completed +@architect-product-area:Configuration @behavior @presets Feature: Preset System for Configuration Presets provide pre-configured taxonomies for different project types. @@ -50,15 +50,15 @@ Feature: Preset System for Configuration Rule: Libar generic preset provides minimal taxonomy with libar prefix - **Invariant:** The libar-generic preset must provide exactly 3 categories with @libar-docs- prefix. - **Rationale:** This package uses @libar-docs- prefix to avoid collisions with consumer projects' annotations. + **Invariant:** The libar-generic preset must provide exactly 3 categories with @architect- prefix. + **Rationale:** This package uses @architect- prefix to avoid collisions with consumer projects' annotations. **Verified by:** Libar generic preset has correct prefix configuration, Libar generic preset has core categories only @happy-path Scenario: Libar generic preset has correct prefix configuration Given the libar-generic preset - Then it should have tagPrefix "@libar-docs-" - And it should have fileOptInTag "@libar-docs" + Then it should have tagPrefix "@architect-" + And it should have fileOptInTag "@architect" @happy-path Scenario: Libar generic preset has core categories only @@ -85,8 +85,8 @@ Feature: Preset System for Configuration @happy-path Scenario: Full preset has correct prefix configuration Given the ddd-es-cqrs preset - Then it should have tagPrefix "@libar-docs-" - And it should have fileOptInTag "@libar-docs" + Then it should have tagPrefix "@architect-" + And it should have fileOptInTag "@architect" @happy-path Scenario: Full preset has all DDD categories @@ -133,9 +133,9 @@ Feature: Preset System for Configuration @happy-path Scenario: DDD preset accessible via PRESETS map When I access PRESETS with key "ddd-es-cqrs" - Then the preset tagPrefix should be "@libar-docs-" + Then the preset tagPrefix should be "@architect-" @happy-path Scenario: Libar generic preset accessible via PRESETS map When I access PRESETS with key "libar-generic" - Then the preset tagPrefix should be "@libar-docs-" + Then the preset tagPrefix should be "@architect-" diff --git a/tests/features/config/project-config-loader.feature b/tests/features/config/project-config-loader.feature index d0e5d686..38e5a280 100644 --- a/tests/features/config/project-config-loader.feature +++ b/tests/features/config/project-config-loader.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:ProjectConfigLoader -@libar-docs-status:completed -@libar-docs-product-area:Configuration +@architect +@architect-pattern:ProjectConfigLoader +@architect-status:completed +@architect-product-area:Configuration @behavior @config Feature: Project Config Loader - Unified Configuration Loading loadProjectConfig loads and resolves configuration from file, - supporting both new-style defineConfig and legacy createDeliveryProcess formats. + supporting both new-style defineConfig and legacy createArchitect formats. **Problem:** - Two config formats exist (new-style and legacy) that need unified loading @@ -49,12 +49,12 @@ Feature: Project Config Loader - Unified Configuration Loading Rule: Legacy config is loaded with backward compatibility - **Invariant:** A file exporting createDeliveryProcess must be loaded and produce a valid resolved config. + **Invariant:** A file exporting createArchitect must be loaded and produce a valid resolved config. **Rationale:** Backward compatibility prevents breaking existing consumers during migration to the new config format. - **Verified by:** Legacy createDeliveryProcess export loads correctly + **Verified by:** Legacy createArchitect export loads correctly @happy-path - Scenario: Legacy createDeliveryProcess export loads correctly + Scenario: Legacy createArchitect export loads correctly Given a legacy config file with registry and regexBuilders When loading project config from temp directory Then project config loading should succeed diff --git a/tests/features/config/source-merging.feature b/tests/features/config/source-merging.feature index 03dd3d68..e75fb287 100644 --- a/tests/features/config/source-merging.feature +++ b/tests/features/config/source-merging.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:SourceMerging -@libar-docs-status:completed -@libar-docs-product-area:Configuration +@architect +@architect-pattern:SourceMerging +@architect-status:completed +@architect-product-area:Configuration @behavior @config Feature: Source Merging - Per-Generator Override Resolution mergeSourcesForGenerator computes effective sources for a specific diff --git a/tests/features/doc-generation/architecture-doc-refactoring.feature b/tests/features/doc-generation/architecture-doc-refactoring.feature index e62bfd70..55526adf 100644 --- a/tests/features/doc-generation/architecture-doc-refactoring.feature +++ b/tests/features/doc-generation/architecture-doc-refactoring.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:ArchitectureDocRefactoringTesting -@libar-docs-status:active -@libar-docs-product-area:Generation +@architect +@architect-pattern:ArchitectureDocRefactoringTesting +@architect-status:active +@architect-product-area:Generation @integration Feature: Architecture Doc Refactoring Coverage @@ -43,7 +43,7 @@ Feature: Architecture Doc Refactoring Coverage Rule: Four-Stage Pipeline section retains annotation format examples - **Invariant:** The Four-Stage Pipeline section contains annotation format examples (e.g., @libar-docs-shape, extract-shapes) and appears before the Source Systems section in document order. + **Invariant:** The Four-Stage Pipeline section contains annotation format examples (e.g., @architect-shape, extract-shapes) and appears before the Source Systems section in document order. **Rationale:** Annotation format examples in the pipeline section demonstrate the source-first architecture. Their ordering establishes the conceptual flow: pipeline stages first, then the source systems that feed them. @@ -52,7 +52,7 @@ Feature: Architecture Doc Refactoring Coverage @acceptance-criteria @happy-path Scenario: Annotation format examples appear before Source Systems When reading the "Four-Stage Pipeline" section - Then the section contains "@libar-docs-shape" + Then the section contains "@architect-shape" And the section also contains "extract-shapes" And section "Four-Stage Pipeline" appears before section "Source Systems" diff --git a/tests/features/doc-generation/content-deduplication.feature b/tests/features/doc-generation/content-deduplication.feature index 746dc5dd..915e12b3 100644 --- a/tests/features/doc-generation/content-deduplication.feature +++ b/tests/features/doc-generation/content-deduplication.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:ContentDeduplication -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:ContentDeduplication +@architect-status:completed +@architect-product-area:Generation Feature: Content Deduplication **Context:** Multiple sources may extract identical content, leading to diff --git a/tests/features/doc-generation/decision-doc-codec.feature b/tests/features/doc-generation/decision-doc-codec.feature index 7fedd756..dc9c19ea 100644 --- a/tests/features/doc-generation/decision-doc-codec.feature +++ b/tests/features/doc-generation/decision-doc-codec.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:DecisionDocCodecTesting -@libar-docs-implements:DecisionDocCodec -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:DecisionDocCodecTesting +@architect-implements:DecisionDocCodec +@architect-status:completed +@architect-product-area:Generation Feature: Decision Document Codec Validates the Decision Doc Codec that parses decision documents (ADR/PDR diff --git a/tests/features/doc-generation/decision-doc-generator.feature b/tests/features/doc-generation/decision-doc-generator.feature index 6d41d2cd..3c3f1d92 100644 --- a/tests/features/doc-generation/decision-doc-generator.feature +++ b/tests/features/doc-generation/decision-doc-generator.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:DecisionDocGeneratorTesting -@libar-docs-implements:DecisionDocGenerator -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:DecisionDocGeneratorTesting +@architect-implements:DecisionDocGenerator +@architect-status:completed +@architect-product-area:Generation Feature: Decision Document Generator The Decision Doc Generator orchestrates the full documentation generation diff --git a/tests/features/doc-generation/poc-integration.feature b/tests/features/doc-generation/poc-integration.feature index 01cee058..2595faad 100644 --- a/tests/features/doc-generation/poc-integration.feature +++ b/tests/features/doc-generation/poc-integration.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:PocIntegration -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:PocIntegration +@architect-status:completed +@architect-product-area:Generation Feature: Documentation Generation POC Integration End-to-end integration tests that exercise the full documentation generation @@ -25,7 +25,7 @@ Feature: Documentation Generation POC Integration @acceptance-criteria @integration Scenario: Load actual POC decision document - Given the POC decision document at "delivery-process/specs/doc-generation-proof-of-concept.feature" + Given the POC decision document at "architect/specs/doc-generation-proof-of-concept.feature" When parsing the decision document Then parsed content should have correct structure @@ -110,7 +110,7 @@ Feature: Documentation Generation POC Integration @acceptance-criteria @integration Scenario: Extract Scenario Outline Examples from process-guard-linter.feature Given the source mapper with base directory at project root - When extracting from "delivery-process/specs/process-guard-linter.feature" with method "Scenario Outline Examples" + When extracting from "architect/specs/process-guard-linter.feature" with method "Scenario Outline Examples" Then extracted content should contain protection level table # ============================================================================ diff --git a/tests/features/doc-generation/robustness-integration.feature b/tests/features/doc-generation/robustness-integration.feature index 9d3ac217..23f9a804 100644 --- a/tests/features/doc-generation/robustness-integration.feature +++ b/tests/features/doc-generation/robustness-integration.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:RobustnessIntegration -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:RobustnessIntegration +@architect-status:completed +@architect-product-area:Generation Feature: Robustness Integration **Context:** Document generation pipeline needs validation, deduplication, and diff --git a/tests/features/doc-generation/source-mapper.feature b/tests/features/doc-generation/source-mapper.feature index 80b3ad89..cdc56889 100644 --- a/tests/features/doc-generation/source-mapper.feature +++ b/tests/features/doc-generation/source-mapper.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:SourceMapperTesting -@libar-docs-implements:SourceMapper -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:SourceMapperTesting +@architect-implements:SourceMapper +@architect-status:completed +@architect-product-area:Generation Feature: Source Mapper The Source Mapper aggregates content from multiple source files based on diff --git a/tests/features/doc-generation/source-mapping-validator.feature b/tests/features/doc-generation/source-mapping-validator.feature index 2b8d1acc..8b6e25a3 100644 --- a/tests/features/doc-generation/source-mapping-validator.feature +++ b/tests/features/doc-generation/source-mapping-validator.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:SourceMappingValidatorTesting -@libar-docs-implements:SourceMappingValidator -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:SourceMappingValidatorTesting +@architect-implements:SourceMappingValidator +@architect-status:completed +@architect-product-area:Generation Feature: Source Mapping Validator **Context:** Source mappings reference files that may not exist, use invalid diff --git a/tests/features/doc-generation/taxonomy-codec.feature b/tests/features/doc-generation/taxonomy-codec.feature index d96b5cb4..588fb289 100644 --- a/tests/features/doc-generation/taxonomy-codec.feature +++ b/tests/features/doc-generation/taxonomy-codec.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:TaxonomyCodecTesting -@libar-docs-implements:TaxonomyCodec -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:TaxonomyCodecTesting +@architect-implements:TaxonomyCodec +@architect-status:completed +@architect-product-area:Generation Feature: Taxonomy Document Codec Validates the Taxonomy Codec that transforms MasterDataset into a diff --git a/tests/features/doc-generation/validation-rules-codec.feature b/tests/features/doc-generation/validation-rules-codec.feature index e89c2332..b2a7912e 100644 --- a/tests/features/doc-generation/validation-rules-codec.feature +++ b/tests/features/doc-generation/validation-rules-codec.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ValidationRulesCodecTesting -@libar-docs-implements:ValidationRulesCodec -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:ValidationRulesCodecTesting +@architect-implements:ValidationRulesCodec +@architect-status:completed +@architect-product-area:Generation Feature: Validation Rules Document Codec Validates the Validation Rules Codec that transforms MasterDataset into a diff --git a/tests/features/doc-generation/warning-collector.feature b/tests/features/doc-generation/warning-collector.feature index e88835ef..5981a190 100644 --- a/tests/features/doc-generation/warning-collector.feature +++ b/tests/features/doc-generation/warning-collector.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:WarningCollectorTesting -@libar-docs-implements:WarningCollector -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:WarningCollectorTesting +@architect-implements:WarningCollector +@architect-status:completed +@architect-product-area:Generation Feature: Warning Collector The warning collector provides a unified system for capturing, categorizing, diff --git a/tests/features/extractor/declaration-level-shape-tagging.feature b/tests/features/extractor/declaration-level-shape-tagging.feature index 1d37b9a1..03000714 100644 --- a/tests/features/extractor/declaration-level-shape-tagging.feature +++ b/tests/features/extractor/declaration-level-shape-tagging.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:DeclarationLevelShapeTaggingTesting -@libar-docs-status:completed -@libar-docs-implements:DeclarationLevelShapeTagging -@libar-docs-product-area:Annotation +@architect +@architect-pattern:DeclarationLevelShapeTaggingTesting +@architect-status:completed +@architect-implements:DeclarationLevelShapeTagging +@architect-product-area:Annotation Feature: Declaration-Level Shape Tagging - Extraction Tests the discoverTaggedShapes function that scans TypeScript source @@ -29,7 +29,7 @@ Feature: Declaration-Level Shape Tagging - Extraction Scenario: Tagged declaration is extracted as shape Given a TypeScript source file containing: """typescript - /** @libar-docs-shape */ + /** @architect-shape */ export interface RiskLevel { readonly name: string; readonly severity: number; @@ -57,7 +57,7 @@ Feature: Declaration-Level Shape Tagging - Extraction Scenario: Group name is captured from tag value Given a TypeScript source file containing: """typescript - /** @libar-docs-shape api-types */ + /** @architect-shape api-types */ export type RiskLevel = 'low' | 'medium' | 'high' | 'critical'; """ When discoverTaggedShapes runs on the source @@ -68,7 +68,7 @@ Feature: Declaration-Level Shape Tagging - Extraction Scenario: Bare tag works without group name Given a TypeScript source file containing: """typescript - /** @libar-docs-shape */ + /** @architect-shape */ export enum Priority { Low, Medium, High } """ When discoverTaggedShapes runs on the source @@ -79,7 +79,7 @@ Feature: Declaration-Level Shape Tagging - Extraction Scenario: Non-exported tagged declaration is extracted Given a TypeScript source file containing: """typescript - /** @libar-docs-shape internal-types */ + /** @architect-shape internal-types */ interface InternalConfig { readonly maxRetries: number; } @@ -94,7 +94,7 @@ Feature: Declaration-Level Shape Tagging - Extraction Given a TypeScript source file containing: """typescript /** - * @libar-docs-shape core-types + * @architect-shape core-types */ export type Result = | { readonly ok: true; readonly value: T } @@ -118,12 +118,12 @@ Feature: Declaration-Level Shape Tagging - Extraction Scenario: Both same-name declarations tagged produces shapes for each Given a TypeScript source file containing: """typescript - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export type Result = | { readonly ok: true; readonly value: T } | { readonly ok: false; readonly error: E }; - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export const Result = { ok(value: T): Result { return { ok: true, value }; @@ -149,23 +149,23 @@ Feature: Declaration-Level Shape Tagging - Extraction Scenario: All five declaration kinds are discoverable Given a TypeScript source file containing: """typescript - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export interface Config { readonly name: string; } - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export type Status = 'active' | 'inactive'; - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export enum Priority { Low, Medium, High } - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export function validate(input: string): boolean { return input.length > 0; } - /** @libar-docs-shape core-types */ + /** @architect-shape core-types */ export const MAX_RETRIES: number = 3; """ When discoverTaggedShapes runs on the source @@ -177,7 +177,7 @@ Feature: Declaration-Level Shape Tagging - Extraction Scenario: JSDoc with gap larger than MAX_JSDOC_LINE_DISTANCE is not matched Given a TypeScript source file containing: """typescript - /** @libar-docs-shape */ + /** @architect-shape */ // unrelated comment @@ -196,7 +196,7 @@ Feature: Declaration-Level Shape Tagging - Extraction """typescript /** * Configuration options. - * @libar-docs-shape config-types + * @architect-shape config-types */ export interface AppConfig { readonly debug: boolean; @@ -210,7 +210,7 @@ Feature: Declaration-Level Shape Tagging - Extraction Scenario: Hypothetical libar-docs-shape-extended tag is not matched Given a TypeScript source file containing: """typescript - /** @libar-docs-shape-extended */ + /** @architect-shape-extended */ export interface NotAShape { readonly value: string; } @@ -225,7 +225,7 @@ Feature: Declaration-Level Shape Tagging - Extraction /** * Represents risk severity levels. * - * @libar-docs-shape risk-types + * @architect-shape risk-types * @see RiskCalculator */ export type RiskLevel = 'low' | 'medium' | 'high' | 'critical'; @@ -239,7 +239,7 @@ Feature: Declaration-Level Shape Tagging - Extraction Scenario: Generic arrow function in non-JSX context parses correctly Given a TypeScript source file containing: """typescript - /** @libar-docs-shape */ + /** @architect-shape */ export const identity = (value: T): T => value; """ When discoverTaggedShapes runs on the source diff --git a/tests/features/extractor/dual-source-extraction.feature b/tests/features/extractor/dual-source-extraction.feature index e7b9e692..abe4a1e4 100644 --- a/tests/features/extractor/dual-source-extraction.feature +++ b/tests/features/extractor/dual-source-extraction.feature @@ -1,12 +1,12 @@ -@libar-docs +@architect @behavior @extraction -@libar-docs-pattern:DualSourceExtractorTesting -@libar-docs-implements:DualSourceExtractor -@libar-docs-status:completed -@libar-docs-product-area:Annotation +@architect-pattern:DualSourceExtractorTesting +@architect-implements:DualSourceExtractor +@architect-status:completed +@architect-product-area:Annotation Feature: Dual-Source Extraction Extracts and combines pattern metadata from both TypeScript code stubs - (@libar-docs-*) and Gherkin feature files (@libar-process-*), validates + (@architect-*) and Gherkin feature files (@libar-process-*), validates consistency, and composes unified pattern data for documentation. **Problem:** diff --git a/tests/features/extractor/extraction-pipeline-enhancements.feature b/tests/features/extractor/extraction-pipeline-enhancements.feature index 972a5e31..a0f260bd 100644 --- a/tests/features/extractor/extraction-pipeline-enhancements.feature +++ b/tests/features/extractor/extraction-pipeline-enhancements.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ExtractionPipelineEnhancementsTesting -@libar-docs-status:completed -@libar-docs-implements:ReferenceDocShowcase -@libar-docs-product-area:Annotation +@architect +@architect-pattern:ExtractionPipelineEnhancementsTesting +@architect-status:completed +@architect-implements:ReferenceDocShowcase +@architect-product-area:Annotation Feature: Extraction Pipeline Enhancements Validates extraction pipeline capabilities for ReferenceDocShowcase: @@ -25,10 +25,10 @@ Feature: Extraction Pipeline Enhancements Scenario: Simple function signature is extracted with full types Given a TypeScript file with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * Simple utility */ export function greet(name: string): string { @@ -42,10 +42,10 @@ Feature: Extraction Pipeline Enhancements Scenario: Async function keeps async prefix in signature Given a TypeScript file with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * Async loader */ export async function loadData(url: string): Promise { @@ -59,10 +59,10 @@ Feature: Extraction Pipeline Enhancements Scenario: Multi-parameter function has all types in signature Given a TypeScript file with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * Merge utility */ export function merge(a: string[], b: string[], unique: boolean): string[] { @@ -76,10 +76,10 @@ Feature: Extraction Pipeline Enhancements Scenario: Function with object parameter type preserves braces Given a TypeScript file with content: """ - /** @libar-docs */ + /** @architect */ /** - * @libar-docs-core + * @architect-core * Config processor */ export function configure(opts: { timeout: number; retries: number }): void { diff --git a/tests/features/extractor/shape-extraction-rendering.feature b/tests/features/extractor/shape-extraction-rendering.feature index 4deeccb7..f75a560a 100644 --- a/tests/features/extractor/shape-extraction-rendering.feature +++ b/tests/features/extractor/shape-extraction-rendering.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:ShapeExtractionRenderingTesting -@libar-docs-implements:ReferenceDocShowcase -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-product-area:Annotation +@architect +@architect-pattern:ShapeExtractionRenderingTesting +@architect-implements:ReferenceDocShowcase +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-product-area:Annotation Feature: TypeScript Shape Extraction - Rendering and Validation Validates the shape extraction system that extracts TypeScript type @@ -160,7 +160,7 @@ Feature: TypeScript Shape Extraction - Rendering and Validation Rule: Annotation tags are stripped from extracted JSDoc while preserving standard tags - **Invariant:** Extracted shapes never contain @libar-docs-* annotation lines in their jsDoc field. + **Invariant:** Extracted shapes never contain @architect-* annotation lines in their jsDoc field. **Rationale:** Shape JSDoc is rendered in documentation output. Annotation tags are metadata for the extraction pipeline, not user-visible documentation content. @@ -170,9 +170,9 @@ Feature: TypeScript Shape Extraction - Rendering and Validation Given TypeScript source code: """ /** - * @libar-docs - * @libar-docs-pattern ShapeExtractor - * @libar-docs-status completed + * @architect + * @architect-pattern ShapeExtractor + * @architect-status completed */ export interface OnlyTags { value: string; @@ -186,8 +186,8 @@ Feature: TypeScript Shape Extraction - Rendering and Validation Given TypeScript source code: """ /** - * @libar-docs - * @libar-docs-status active + * @architect + * @architect-status active * * Configuration for the pipeline. * @@ -202,13 +202,13 @@ Feature: TypeScript Shape Extraction - Rendering and Validation Then the shape "MixedTags" jsDoc should contain "Configuration for the pipeline" And the shape "MixedTags" jsDoc should contain "@param timeout" And the shape "MixedTags" jsDoc should contain "@returns" - And the shape "MixedTags" jsDoc should not contain "@libar-docs" + And the shape "MixedTags" jsDoc should not contain "@architect" @acceptance-criteria @unit @edge-case Scenario: Single-line annotation-only JSDoc produces no jsDoc Given TypeScript source code: """ - /** @libar-docs-shape Foo */ + /** @architect-shape Foo */ export interface SingleLine { id: string; } @@ -221,8 +221,8 @@ Feature: TypeScript Shape Extraction - Rendering and Validation Given TypeScript source code: """ /** - * @libar-docs - * @libar-docs-status roadmap + * @architect + * @architect-status roadmap * * * Useful description here. diff --git a/tests/features/extractor/shape-extraction-types.feature b/tests/features/extractor/shape-extraction-types.feature index aad422e9..c46022b3 100644 --- a/tests/features/extractor/shape-extraction-types.feature +++ b/tests/features/extractor/shape-extraction-types.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ShapeExtractionTypesTesting -@libar-docs-implements:ReferenceDocShowcase -@libar-docs-status:completed -@libar-docs-product-area:Annotation +@architect +@architect-pattern:ShapeExtractionTypesTesting +@architect-implements:ReferenceDocShowcase +@architect-status:completed +@architect-product-area:Annotation Feature: TypeScript Shape Extraction - Type Extraction Validates the shape extraction system that extracts TypeScript type diff --git a/tests/features/generation/design-review-generator.feature b/tests/features/generation/design-review-generator.feature index 875e9fe3..57f00993 100644 --- a/tests/features/generation/design-review-generator.feature +++ b/tests/features/generation/design-review-generator.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:DesignReviewGeneratorLifecycleTests -@libar-docs-status:active -@libar-docs-product-area:Generation +@architect +@architect-pattern:DesignReviewGeneratorLifecycleTests +@architect-status:active +@architect-product-area:Generation @behavior @design-review Feature: Design Review Generator Lifecycle diff --git a/tests/features/generation/design-review.feature b/tests/features/generation/design-review.feature index fedf444a..288306e0 100644 --- a/tests/features/generation/design-review.feature +++ b/tests/features/generation/design-review.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:DesignReviewGenerationTests -@libar-docs-status:active -@libar-docs-product-area:Generation +@architect +@architect-pattern:DesignReviewGenerationTests +@architect-status:active +@architect-product-area:Generation @behavior @design-review Feature: Design Review Generation Pipeline @@ -182,14 +182,14 @@ Feature: Design Review Generation Pipeline Scenario: Duplicate step numbers are reported as malformed Given a pattern with duplicate sequence-step values When transforming the pattern with validation - Then validation issues contain "Duplicate @libar-docs-sequence-step:1" + Then validation issues contain "Duplicate @architect-sequence-step:1" And sequenceIndex does not contain the pattern @acceptance-criteria @validation Scenario: Sequence step without modules is reported as malformed Given a pattern with a sequence step but no sequence modules When transforming the pattern with validation - Then validation issues contain "has @libar-docs-sequence-step:1 but no @libar-docs-sequence-module values" + Then validation issues contain "has @architect-sequence-step:1 but no @architect-sequence-module values" And sequenceIndex does not contain the pattern Rule: Process API sequence lookup resolves pattern names case-insensitively diff --git a/tests/features/generation/load-preamble.feature b/tests/features/generation/load-preamble.feature index d4ca1a90..bf4c3583 100644 --- a/tests/features/generation/load-preamble.feature +++ b/tests/features/generation/load-preamble.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:LoadPreambleParser -@libar-docs-status:active -@libar-docs-product-area:Generation +@architect +@architect-pattern:LoadPreambleParser +@architect-status:active +@architect-product-area:Generation @behavior @load-preamble Feature: Markdown-to-SectionBlock Parser diff --git a/tests/features/generators/business-rules-codec.feature b/tests/features/generators/business-rules-codec.feature index ea2493c9..7e08fc4d 100644 --- a/tests/features/generators/business-rules-codec.feature +++ b/tests/features/generators/business-rules-codec.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:BusinessRulesDocumentCodec -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-implements:BusinessRulesGenerator +@architect +@architect-pattern:BusinessRulesDocumentCodec +@architect-status:completed +@architect-product-area:Generation +@architect-implements:BusinessRulesGenerator Feature: Business Rules Document Codec Tests the BusinessRulesCodec transformation from MasterDataset to RenderableDocument. diff --git a/tests/features/generators/codec-based.feature b/tests/features/generators/codec-based.feature index fb8b0b1d..2a278389 100644 --- a/tests/features/generators/codec-based.feature +++ b/tests/features/generators/codec-based.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:CodecBasedGeneratorTesting -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-implements:CodecBasedGenerator,GeneratorInfrastructureTesting +@architect +@architect-pattern:CodecBasedGeneratorTesting +@architect-status:completed +@architect-product-area:Generation +@architect-implements:CodecBasedGenerator,GeneratorInfrastructureTesting Feature: Codec-Based Generator Tests the CodecBasedGenerator which adapts the RenderableDocument Model (RDM) diff --git a/tests/features/generators/orchestrator.feature b/tests/features/generators/orchestrator.feature index 9d75702c..fa1dad6a 100644 --- a/tests/features/generators/orchestrator.feature +++ b/tests/features/generators/orchestrator.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:DocumentationOrchestrator -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-implements:GeneratorInfrastructureTesting +@architect +@architect-pattern:DocumentationOrchestrator +@architect-status:completed +@architect-product-area:Generation +@architect-implements:GeneratorInfrastructureTesting Feature: Documentation Generation Orchestrator Tests the orchestrator's pattern merging, conflict detection, and generator diff --git a/tests/features/generators/pr-changes-options.feature b/tests/features/generators/pr-changes-options.feature index 42a9c9ae..6f65d680 100644 --- a/tests/features/generators/pr-changes-options.feature +++ b/tests/features/generators/pr-changes-options.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:PrChangesOptions -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-implements:GeneratorInfrastructureTesting +@architect +@architect-pattern:PrChangesOptions +@architect-status:completed +@architect-product-area:Generation +@architect-implements:GeneratorInfrastructureTesting Feature: PR Changes Options Tests the PrChangesCodec filtering capabilities for generating PR-scoped diff --git a/tests/features/generators/prd-implementation-section.feature b/tests/features/generators/prd-implementation-section.feature index 22bc2fc3..c6d1a640 100644 --- a/tests/features/generators/prd-implementation-section.feature +++ b/tests/features/generators/prd-implementation-section.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:PrdImplementationSectionTesting -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-implements:PrdImplementationSection +@architect +@architect-pattern:PrdImplementationSectionTesting +@architect-status:completed +@architect-product-area:Generation +@architect-implements:PrdImplementationSection Feature: PRD Implementation Section Tests the Implementations section rendering in pattern documents. - Verifies that code stubs with @libar-docs-implements tags appear in pattern docs + Verifies that code stubs with @architect-implements tags appear in pattern docs with working links to the source files. Background: Pattern generator test context @@ -16,9 +16,9 @@ Feature: PRD Implementation Section # Rule 1: Implementation files appear in pattern docs # =========================================================================== - Rule: Implementation files appear in pattern docs via @libar-docs-implements + Rule: Implementation files appear in pattern docs via @architect-implements - **Invariant:** Any TypeScript file with a matching @libar-docs-implements tag must appear in the pattern document's Implementations section with a working file link. + **Invariant:** Any TypeScript file with a matching @architect-implements tag must appear in the pattern document's Implementations section with a working file link. **Rationale:** Implementation discovery relies on tag-based linking — missing entries break traceability between specs and code. **Verified by:** Implementations section renders with file links, Implementation includes description when available diff --git a/tests/features/generators/registry.feature b/tests/features/generators/registry.feature index bb18a129..e011dff7 100644 --- a/tests/features/generators/registry.feature +++ b/tests/features/generators/registry.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:GeneratorRegistryTesting -@libar-docs-status:completed -@libar-docs-product-area:Generation -@libar-docs-implements:GeneratorRegistry,GeneratorInfrastructureTesting +@architect +@architect-pattern:GeneratorRegistryTesting +@architect-status:completed +@architect-product-area:Generation +@architect-implements:GeneratorRegistry,GeneratorInfrastructureTesting Feature: Generator Registry Tests the GeneratorRegistry registration, lookup, and listing capabilities. diff --git a/tests/features/generators/table-extraction.feature b/tests/features/generators/table-extraction.feature index 5fc5616a..4e4d2a3a 100644 --- a/tests/features/generators/table-extraction.feature +++ b/tests/features/generators/table-extraction.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:TableExtraction -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:TableExtraction +@architect-status:completed +@architect-product-area:Generation Feature: Table Extraction Without Duplication Tables in business rule descriptions should appear exactly once in output. diff --git a/tests/features/lint/lint-engine.feature b/tests/features/lint/lint-engine.feature index 9db7e618..c04fe023 100644 --- a/tests/features/lint/lint-engine.feature +++ b/tests/features/lint/lint-engine.feature @@ -1,9 +1,9 @@ -@libar-docs -@lint @libar-docs-pattern:LintEngineTesting -@libar-docs-implements:LintEngine -@libar-docs-status:completed -@libar-docs-product-area:Validation -@libar-docs-depends-on:LintRules +@architect +@lint @architect-pattern:LintEngineTesting +@architect-implements:LintEngine +@architect-status:completed +@architect-product-area:Validation +@architect-depends-on:LintRules Feature: Lint Engine The lint engine orchestrates rule execution, aggregates violations, and formats output for human and machine consumption. diff --git a/tests/features/lint/lint-rules-advanced.feature b/tests/features/lint/lint-rules-advanced.feature index e070be70..31429a17 100644 --- a/tests/features/lint/lint-rules-advanced.feature +++ b/tests/features/lint/lint-rules-advanced.feature @@ -1,8 +1,8 @@ -@libar-docs -@lint @libar-docs-pattern:LintRuleAdvancedTesting -@libar-docs-implements:LintRules -@libar-docs-status:completed -@libar-docs-product-area:Validation +@architect +@lint @architect-pattern:LintRuleAdvancedTesting +@architect-implements:LintRules +@architect-status:completed +@architect-product-area:Validation Feature: Pattern Annotation Lint Rules - Advanced Rule Logic Complex lint rule logic and collection-level behavior. Tests tautological description detection, default collection, and severity filtering. diff --git a/tests/features/lint/lint-rules-individual.feature b/tests/features/lint/lint-rules-individual.feature index 293735af..7098721c 100644 --- a/tests/features/lint/lint-rules-individual.feature +++ b/tests/features/lint/lint-rules-individual.feature @@ -1,9 +1,9 @@ -@libar-docs -@lint @libar-docs-pattern:LintRuleIndividualTesting -@libar-docs-implements:LintRules -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-product-area:Validation +@architect +@lint @architect-pattern:LintRuleIndividualTesting +@architect-implements:LintRules +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-product-area:Validation Feature: Pattern Annotation Lint Rules - Individual Rule Validation Individual lint rules that check parsed directives for completeness. Tests presence/absence checks: pattern name, status, whenToUse, and relationships. @@ -66,7 +66,7 @@ Feature: Pattern Annotation Lint Rules - Individual Rule Validation When I apply the missing-status rule Then a violation should be detected And the violation severity should be "warning" - And the violation message should contain "@libar-docs-status" + And the violation message should contain "@architect-status" @rule:missing-status @happy-path Scenario: Accept completed status diff --git a/tests/features/mcp/mcp-server.feature b/tests/features/mcp/mcp-server.feature index 0a460f43..2b9b2b3a 100644 --- a/tests/features/mcp/mcp-server.feature +++ b/tests/features/mcp/mcp-server.feature @@ -1,4 +1,4 @@ -@libar-docs +@architect Feature: MCP Server Integration Tests Verifies the MCP-specific layer: tool registration, pipeline session @@ -74,42 +74,42 @@ Feature: MCP Server Integration Tests Rule: Tool registration creates correctly named tools with schemas **Invariant:** Every CLI subcommand is registered as an MCP tool with - dp_ prefix, non-empty description, and Zod input schema. + architect_ prefix, non-empty description, and Zod input schema. **Rationale:** Verifies tool registration correctness via MockMcpServer that records registerTool calls. - **Verified by:** All tools registered with dp_ prefix, + **Verified by:** All tools registered with architect_ prefix, Each tool has a non-empty description, - dp_overview returns formatted text, - dp_pattern returns error for unknown pattern, - dp_list filters apply cumulatively + architect_overview returns formatted text, + architect_pattern returns error for unknown pattern, + architect_list filters apply cumulatively - Scenario: All tools registered with dp_ prefix + Scenario: All tools registered with architect_ prefix Given an McpServer mock with registered tools Then at least 25 tools are registered - And each tool name starts with "dp_" + And each tool name starts with "architect_" Scenario: Each tool has a non-empty description Given an McpServer mock with registered tools Then each registered tool has a non-empty description - Scenario: dp_overview returns formatted text + Scenario: architect_overview returns formatted text Given an McpServer mock with registered tools - When the dp_overview handler is called + When the architect_overview handler is called Then the result contains text content And the result is not an error - Scenario: dp_pattern returns error for unknown pattern + Scenario: architect_pattern returns error for unknown pattern Given an McpServer mock with registered tools - When the dp_pattern handler is called with name "NonExistentPattern" + When the architect_pattern handler is called with name "NonExistentPattern" Then the result is an error And the error message contains "not found" - Scenario: dp_list filters apply cumulatively + Scenario: architect_list filters apply cumulatively Given a session with patterns of mixed status and phase And an McpServer mock with registered tools using that session - When dp_list is called with status "active" and phase 46 + When architect_list is called with status "active" and phase 46 Then only patterns matching both status and phase are returned Rule: File watcher filters file types correctly @@ -193,47 +193,47 @@ Feature: MCP Server Integration Tests **Verified by:** Session-aware tools return text content, Data query tools return valid JSON, - dp_status returns JSON with counts + architect_status returns JSON with counts Scenario: Session-aware tools return text content Given an McpServer mock with registered tools - When the dp_overview handler is called + When the architect_overview handler is called Then the result content type is "text" Scenario: Data query tools return valid JSON Given an McpServer mock with registered tools - When the dp_status handler is called + When the architect_status handler is called Then the result content is valid JSON - Scenario: dp_status returns JSON with counts + Scenario: architect_status returns JSON with counts Given an McpServer mock with registered tools - When the dp_status handler is called + When the architect_status handler is called Then the JSON result contains "counts" key And the JSON result contains "distribution" key Rule: Tool output correctness for edge cases - **Invariant:** dp_rules without a pattern filter returns a compact summary - instead of the full rules corpus. dp_pattern returns full metadata including + **Invariant:** architect_rules without a pattern filter returns a compact summary + instead of the full rules corpus. architect_pattern returns full metadata including deliverables, dependencies, business rules, and extracted shapes. - **Rationale:** Unfiltered dp_rules returned 889K chars which breaks MCP clients. - dp_pattern must match its description ("full metadata") to enable accurate tool selection. + **Rationale:** Unfiltered architect_rules returned 889K chars which breaks MCP clients. + architect_pattern must match its description ("full metadata") to enable accurate tool selection. - **Verified by:** dp_rules without pattern returns compact summary, - dp_pattern returns full metadata including business rules and extracted shapes + **Verified by:** architect_rules without pattern returns compact summary, + architect_pattern returns full metadata including business rules and extracted shapes - Scenario: dp_rules without pattern returns compact summary + Scenario: architect_rules without pattern returns compact summary Given an McpServer mock with registered tools - When the dp_rules handler is called without pattern + When the architect_rules handler is called without pattern Then the result contains totalRules and allRuleNames And the result contains a hint about using pattern parameter And the result does not contain full rule details - Scenario: dp_pattern returns full metadata including business rules and extracted shapes + Scenario: architect_pattern returns full metadata including business rules and extracted shapes Given a session with a pattern that has deliverables and dependencies And an McpServer mock with registered tools using that session - When dp_pattern is called for that pattern + When architect_pattern is called for that pattern Then the result contains deliverables array And the result contains dependencies object And the result contains directive and source metadata diff --git a/tests/features/poc/rule-keyword-poc.feature b/tests/features/poc/rule-keyword-poc.feature index b361cbd8..c2f0c8ef 100644 --- a/tests/features/poc/rule-keyword-poc.feature +++ b/tests/features/poc/rule-keyword-poc.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:RuleKeywordPoC -@libar-docs-status:completed -@libar-docs-product-area:Generation +@architect +@architect-pattern:RuleKeywordPoC +@architect-status:completed +@architect-product-area:Generation @poc @rule-keyword Feature: PoC - Rule Keyword Support This feature tests whether vitest-cucumber supports the Rule keyword diff --git a/tests/features/poc/test-content-blocks.feature b/tests/features/poc/test-content-blocks.feature index 091e24cd..da86ea72 100644 --- a/tests/features/poc/test-content-blocks.feature +++ b/tests/features/poc/test-content-blocks.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:TestContentBlocks -@libar-docs-status:roadmap -@libar-docs-phase:99 -@libar-docs-product-area:Generation -@libar-docs-business-value:test-what-generators-capture +@architect +@architect-pattern:TestContentBlocks +@architect-status:roadmap +@architect-phase:99 +@architect-product-area:Generation +@architect-business-value:test-what-generators-capture Feature: Test Content Blocks This feature demonstrates what content blocks are captured and rendered diff --git a/tests/features/scanner/ast-parser-exports.feature b/tests/features/scanner/ast-parser-exports.feature index f5314bd4..2ad1809b 100644 --- a/tests/features/scanner/ast-parser-exports.feature +++ b/tests/features/scanner/ast-parser-exports.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:AstParserExports -@libar-docs-implements:AstParser -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-product-area:Annotation +@architect +@architect-pattern:AstParserExports +@architect-implements:AstParser +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-product-area:Annotation Feature: TypeScript AST Parser - Export Type Identification - The AST Parser extracts @libar-docs-* directives from TypeScript source files + The AST Parser extracts @architect-* directives from TypeScript source files using the TypeScript compiler API. It identifies exports, extracts metadata, and validates directive structure. @@ -23,7 +23,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Test function for authentication */ export function authenticate(username: string, password: string): boolean { @@ -32,7 +32,7 @@ Feature: TypeScript AST Parser - Export Type Identification """ When the file is parsed for directives Then 1 directive should be found - And the directive should have tag "@libar-docs-core" + And the directive should have tag "@architect-core" And the directive description should contain "Test function for authentication" And the first export should be: | field | value | @@ -44,7 +44,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core @libar-docs-types + * @architect-core @architect-types * User type definition */ export type User = { @@ -56,8 +56,8 @@ Feature: TypeScript AST Parser - Export Type Identification Then 1 directive should be found And the directive should have tags: | value | - | @libar-docs-core | - | @libar-docs-types | + | @architect-core | + | @architect-types | And the first export should be: | field | value | | type | type | @@ -68,7 +68,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Config interface */ export interface Config { @@ -88,7 +88,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * API configuration */ export const API_CONFIG = { @@ -108,7 +108,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * User service class */ export class UserService { @@ -131,7 +131,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Enum export */ export enum Status { @@ -153,7 +153,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Const enum export */ export const enum Direction { @@ -176,7 +176,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Abstract class export */ export abstract class BaseService { @@ -199,7 +199,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Arrow function export */ export const fetchData = async (url: string): Promise => { @@ -218,7 +218,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Async function export */ export async function loadData(id: string): Promise { @@ -239,7 +239,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Generic function export */ export function map(items: T[], fn: (item: T) => U): U[] { @@ -259,7 +259,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Default export */ export default function authenticate() { @@ -278,7 +278,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Re-exported utilities */ export { foo, bar } from './utils'; @@ -296,7 +296,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Multiple exports */ export const USER_ROLE = 'admin', USER_STATUS = 'active'; @@ -314,7 +314,7 @@ Feature: TypeScript AST Parser - Export Type Identification Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * First function */ export function first() { @@ -322,7 +322,7 @@ Feature: TypeScript AST Parser - Export Type Identification } /** - * @libar-docs-domain + * @architect-domain * Second function */ export function second() { @@ -333,5 +333,5 @@ Feature: TypeScript AST Parser - Export Type Identification Then 2 directives should be found And the directives should have details: | index | tag | exportName | - | 1 | @libar-docs-core | first | - | 2 | @libar-docs-domain | second | + | 1 | @architect-core | first | + | 2 | @architect-domain | second | diff --git a/tests/features/scanner/ast-parser-metadata.feature b/tests/features/scanner/ast-parser-metadata.feature index 1cdc7095..4d5054f7 100644 --- a/tests/features/scanner/ast-parser-metadata.feature +++ b/tests/features/scanner/ast-parser-metadata.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:AstParserMetadata -@libar-docs-implements:AstParser -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-product-area:Annotation +@architect +@architect-pattern:AstParserMetadata +@architect-implements:AstParser +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-product-area:Annotation Feature: TypeScript AST Parser - Metadata Extraction - The AST Parser extracts @libar-docs-* directives from TypeScript source files + The AST Parser extracts @architect-* directives from TypeScript source files using the TypeScript compiler API. It identifies exports, extracts metadata, and validates directive structure. @@ -23,7 +23,7 @@ Feature: TypeScript AST Parser - Metadata Extraction Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Test function with examples * * @example @@ -54,7 +54,7 @@ Feature: TypeScript AST Parser - Metadata Extraction Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * * This is a detailed description * that spans multiple lines @@ -79,7 +79,7 @@ Feature: TypeScript AST Parser - Metadata Extraction // Line 1 // Line 2 /** - * @libar-docs-core + * @architect-core * Test */ export function test() { @@ -98,7 +98,7 @@ Feature: TypeScript AST Parser - Metadata Extraction Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Function with signature */ export function calculate(a: number, b: number, c: string): number { @@ -114,7 +114,7 @@ Feature: TypeScript AST Parser - Metadata Extraction Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Test function * * @param input - The input string @@ -143,8 +143,8 @@ Feature: TypeScript AST Parser - Metadata Extraction Given a TypeScript file with content: """ /** - * @libar-docs-core @libar-docs-api - * @libar-docs-overview + * @architect-core @architect-api + * @architect-overview * * This is the description. */ @@ -157,16 +157,16 @@ Feature: TypeScript AST Parser - Metadata Extraction And the directive should have 3 tags And the directive should have tags: | value | - | @libar-docs-core | - | @libar-docs-api | - | @libar-docs-overview| + | @architect-core | + | @architect-api | + | @architect-overview| @function:parseFileDirectives @tags Scenario: Extract tag with description on same line Given a TypeScript file with content: """ /** - * @libar-docs-core Brief description on same line + * @architect-core Brief description on same line */ export function inlineDesc() { return true; @@ -175,17 +175,17 @@ Feature: TypeScript AST Parser - Metadata Extraction When the file is parsed for directives Then 1 directive should be found And the directive should have 1 tag - And the directive should have tag "@libar-docs-core" + And the directive should have tag "@architect-core" @function:parseFileDirectives @tags @regression Scenario: NOT extract tags mentioned in description Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * - * This function works with @libar-docs-api patterns. - * It supports @libar-docs-saga for orchestration. + * This function works with @architect-api patterns. + * It supports @architect-saga for orchestration. */ export function processRequest() { return true; @@ -194,38 +194,38 @@ Feature: TypeScript AST Parser - Metadata Extraction When the file is parsed for directives Then 1 directive should be found And the directive should have 1 tag - And the directive should have tag "@libar-docs-core" + And the directive should have tag "@architect-core" And the directive should not have any tags: | value | - | @libar-docs-api | - | @libar-docs-saga | + | @architect-api | + | @architect-saga | @function:parseFileDirectives @tags @regression Scenario: NOT extract tags mentioned in @example sections Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Test function * * @example * ```typescript - * hasTag('@libar-docs-example'); // checking for a tag - * hasTag('@libar-docs-saga'); // another example + * hasTag('@architect-example'); // checking for a tag + * hasTag('@architect-saga'); // another example * ``` */ export function hasTag(tag: string): boolean { - return tag.startsWith('@libar-docs'); + return tag.startsWith('@architect'); } """ When the file is parsed for directives Then 1 directive should be found And the directive should have 1 tag - And the directive should have tag "@libar-docs-core" + And the directive should have tag "@architect-core" And the directive should not have any tags: | value | - | @libar-docs-example | - | @libar-docs-saga | + | @architect-example | + | @architect-saga | Rule: When to Use sections are extracted in all supported formats @@ -238,7 +238,7 @@ Feature: TypeScript AST Parser - Metadata Extraction Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * * ## Pattern Description * @@ -266,7 +266,7 @@ Feature: TypeScript AST Parser - Metadata Extraction Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * * **When to use:** Command validation requires complex business rules. * @@ -288,7 +288,7 @@ Feature: TypeScript AST Parser - Metadata Extraction Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * * ## Pattern * @@ -315,7 +315,7 @@ Feature: TypeScript AST Parser - Metadata Extraction Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * * Just a regular description without When to Use section. */ diff --git a/tests/features/scanner/ast-parser-relationships-edges.feature b/tests/features/scanner/ast-parser-relationships-edges.feature index f6b2b073..68b3592c 100644 --- a/tests/features/scanner/ast-parser-relationships-edges.feature +++ b/tests/features/scanner/ast-parser-relationships-edges.feature @@ -1,11 +1,11 @@ -@libar-docs -@libar-docs-pattern:AstParserRelationshipsEdges -@libar-docs-implements:AstParser -@libar-docs-status:completed -@libar-docs-unlock-reason:'Split-from-original' -@libar-docs-product-area:Annotation +@architect +@architect-pattern:AstParserRelationshipsEdges +@architect-implements:AstParser +@architect-status:completed +@architect-unlock-reason:'Split-from-original' +@architect-product-area:Annotation Feature: TypeScript AST Parser - Relationships and Edge Cases - The AST Parser extracts @libar-docs-* directives from TypeScript source files + The AST Parser extracts @architect-* directives from TypeScript source files using the TypeScript compiler API. It identifies exports, extracts metadata, and validates directive structure. @@ -16,15 +16,15 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases **Invariant:** The uses and usedBy relationship arrays are populated from directive tags, not from description content. When no relationship tags exist, the fields are undefined. **Rationale:** Relationship data drives dependency diagrams and impact analysis — extracting from prose would produce false edges from incidental mentions. - **Verified by:** Extract @libar-docs-uses with single value, Extract @libar-docs-uses with comma-separated values, Extract @libar-docs-used-by with single value, Extract @libar-docs-used-by with comma-separated values, Extract both uses and usedBy from same directive, NOT capture uses/usedBy values in description, Not set uses/usedBy when no relationship tags exist + **Verified by:** Extract @architect-uses with single value, Extract @architect-uses with comma-separated values, Extract @architect-used-by with single value, Extract @architect-used-by with comma-separated values, Extract both uses and usedBy from same directive, NOT capture uses/usedBy values in description, Not set uses/usedBy when no relationship tags exist @function:parseFileDirectives @relationships - Scenario: Extract @libar-docs-uses with single value + Scenario: Extract @architect-uses with single value Given a TypeScript file with content: """ /** - * @libar-docs-core - * @libar-docs-uses FSM Types + * @architect-core + * @architect-uses FSM Types * * Pattern that uses another pattern. */ @@ -39,12 +39,12 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases | FSM Types | @function:parseFileDirectives @relationships - Scenario: Extract @libar-docs-uses with comma-separated values + Scenario: Extract @architect-uses with comma-separated values Given a TypeScript file with content: """ /** - * @libar-docs-core - * @libar-docs-uses FSM Types, Invariant Error, CMS Types + * @architect-core + * @architect-uses FSM Types, Invariant Error, CMS Types * * Pattern that uses multiple patterns. */ @@ -62,12 +62,12 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases | CMS Types | @function:parseFileDirectives @relationships - Scenario: Extract @libar-docs-used-by with single value + Scenario: Extract @architect-used-by with single value Given a TypeScript file with content: """ /** - * @libar-docs-core - * @libar-docs-used-by createDeciderHandler Factory + * @architect-core + * @architect-used-by createDeciderHandler Factory * * Pattern used by another pattern. */ @@ -82,12 +82,12 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases | createDeciderHandler Factory | @function:parseFileDirectives @relationships - Scenario: Extract @libar-docs-used-by with comma-separated values + Scenario: Extract @architect-used-by with comma-separated values Given a TypeScript file with content: """ /** - * @libar-docs-core - * @libar-docs-used-by defineFSM Factory, Decider Types + * @architect-core + * @architect-used-by defineFSM Factory, Decider Types * * Pattern used by multiple patterns. */ @@ -108,9 +108,9 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases Given a TypeScript file with content: """ /** - * @libar-docs-core - * @libar-docs-uses FSM Types - * @libar-docs-used-by createDeciderHandler Factory + * @architect-core + * @architect-uses FSM Types + * @architect-used-by createDeciderHandler Factory * * Pattern with both uses and used-by relationships. */ @@ -132,9 +132,9 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases Given a TypeScript file with content: """ /** - * @libar-docs-core - * @libar-docs-uses FSM Types - * @libar-docs-used-by createDeciderHandler Factory + * @architect-core + * @architect-uses FSM Types + * @architect-used-by createDeciderHandler Factory * * ## Decider Pattern - Pure Domain Decision Logic * @@ -163,7 +163,7 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * * Pattern without relationship tags. */ @@ -180,10 +180,10 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases **Invariant:** The parser never crashes on invalid input. Files without directives return empty results. Malformed TypeScript returns a structured error with the file path. **Rationale:** The scanner processes hundreds of files in bulk — a single malformed file must not abort the entire pipeline or produce an undiagnosable crash. - **Verified by:** Skip comments without @libar-docs-* tags, Skip invalid directive with incomplete tag, Handle malformed TypeScript gracefully, Handle empty file gracefully, Handle whitespace-only file, Handle file with only comments and no exports, Skip inline comments (non-block), Handle unicode characters in descriptions + **Verified by:** Skip comments without @architect-* tags, Skip invalid directive with incomplete tag, Handle malformed TypeScript gracefully, Handle empty file gracefully, Handle whitespace-only file, Handle file with only comments and no exports, Skip inline comments (non-block), Handle unicode characters in descriptions @function:parseFileDirectives @edge-case - Scenario: Skip comments without @libar-docs-* tags + Scenario: Skip comments without @architect-* tags Given a TypeScript file with content: """ /** @@ -203,7 +203,7 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases Given a TypeScript file with content: """ /** - * @libar-docs- + * @architect- */ export function invalid() { return 'invalid'; @@ -217,7 +217,7 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases Given a TypeScript file with malformed content: """ /** - * @libar-docs-core + * @architect-core * This will fail to parse */ export function broken( @@ -249,7 +249,7 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * This is a comment with no following export */ @@ -262,7 +262,7 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases Scenario: Skip inline comments (non-block) Given a TypeScript file with content: """ - // @libar-docs-core - This is an inline comment + // @architect-core - This is an inline comment export function test() { return 'test'; } @@ -275,7 +275,7 @@ Feature: TypeScript AST Parser - Relationships and Edge Cases Given a TypeScript file with content: """ /** - * @libar-docs-core + * @architect-core * Funcion de autenticacion con emojis */ export function autenticar() { diff --git a/tests/features/scanner/docstring-mediatype.feature b/tests/features/scanner/docstring-mediatype.feature index dc3a3575..951285ce 100644 --- a/tests/features/scanner/docstring-mediatype.feature +++ b/tests/features/scanner/docstring-mediatype.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:DocStringMediaType -@libar-docs-status:completed -@libar-docs-product-area:Annotation +@architect +@architect-pattern:DocStringMediaType +@architect-status:completed +@architect-product-area:Annotation Feature: DocString MediaType Preservation DocString language hints (mediaType) should be preserved through the parsing diff --git a/tests/features/scanner/file-discovery.feature b/tests/features/scanner/file-discovery.feature index e20dba9d..55192da6 100644 --- a/tests/features/scanner/file-discovery.feature +++ b/tests/features/scanner/file-discovery.feature @@ -1,7 +1,7 @@ -@libar-docs -@scanner @libar-docs-pattern:FileDiscovery @unit -@libar-docs-status:completed -@libar-docs-product-area:Annotation +@architect +@scanner @architect-pattern:FileDiscovery @unit +@architect-status:completed +@architect-product-area:Annotation Feature: File Discovery The file discovery system uses glob patterns to find TypeScript files for documentation extraction. It applies sensible defaults to exclude diff --git a/tests/features/scanner/gherkin-parser.feature b/tests/features/scanner/gherkin-parser.feature index 6081a7f1..4b8893db 100644 --- a/tests/features/scanner/gherkin-parser.feature +++ b/tests/features/scanner/gherkin-parser.feature @@ -1,7 +1,7 @@ -@libar-docs -@scanner @libar-docs-pattern:GherkinAstParser @unit -@libar-docs-status:completed -@libar-docs-product-area:Annotation +@architect +@scanner @architect-pattern:GherkinAstParser @unit +@architect-status:completed +@architect-product-area:Annotation Feature: Gherkin AST Parser The Gherkin AST parser extracts feature metadata, scenarios, and steps from .feature files for timeline generation and process documentation. @@ -19,7 +19,7 @@ Feature: Gherkin AST Parser Scenario: Parse valid feature file with pattern metadata Given a Gherkin feature file with content: """ - @libar-docs-pattern:ProjectionCategories @libar-docs-phase:15 @libar-docs-status:roadmap + @architect-pattern:ProjectionCategories @architect-phase:15 @architect-status:roadmap Feature: Projection Categories A taxonomy that categorizes projections by purpose. @@ -59,7 +59,7 @@ Feature: Gherkin AST Parser Scenario: Parse multiple scenarios Given a Gherkin feature file with content: """ - @libar-docs-pattern:MyPattern + @architect-pattern:MyPattern Feature: My Pattern Description @@ -106,7 +106,7 @@ Feature: Gherkin AST Parser Given a Gherkin feature file with content: """ This is not valid Gherkin - @libar-docs-pattern:Invalid + @architect-pattern:Invalid """ When the feature file is parsed Then parsing should fail @@ -116,7 +116,7 @@ Feature: Gherkin AST Parser Scenario: Return error for file without feature Given a Gherkin feature file with content: """ - @libar-docs-pattern:Invalid + @architect-pattern:Invalid # Just a comment """ When the feature file is parsed diff --git a/tests/features/types/deliverable-status.feature b/tests/features/types/deliverable-status.feature index 9d72345c..0a99f007 100644 --- a/tests/features/types/deliverable-status.feature +++ b/tests/features/types/deliverable-status.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:DeliverableStatusTaxonomyTesting -@libar-docs-status:active -@libar-docs-product-area:CoreTypes -@libar-docs-include:core-types +@architect +@architect-pattern:DeliverableStatusTaxonomyTesting +@architect-status:active +@architect-product-area:CoreTypes +@architect-include:core-types @taxonomy @deliverable Feature: Deliverable Status Taxonomy The deliverable status module defines the 6 canonical status values for diff --git a/tests/features/types/error-factories.feature b/tests/features/types/error-factories.feature index b6096339..89a56ce3 100644 --- a/tests/features/types/error-factories.feature +++ b/tests/features/types/error-factories.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ErrorFactories -@libar-docs-status:completed -@libar-docs-product-area:CoreTypes -@libar-docs-include:core-types +@architect +@architect-pattern:ErrorFactories +@architect-status:completed +@architect-product-area:CoreTypes +@architect-include:core-types @types @errors Feature: Error Factory Functions Error factories create structured, discriminated error types with consistent @@ -67,8 +67,8 @@ Feature: Error Factory Functions @function:createDirectiveValidationError Scenario: createDirectiveValidationError includes optional directive snippet - When I create a DirectiveValidationError with directive "@libar-docs-" - Then the error should have directive "@libar-docs-" + When I create a DirectiveValidationError with directive "@architect-" + Then the error should have directive "@architect-" @function:createDirectiveValidationError Scenario: createDirectiveValidationError omits directive when not provided diff --git a/tests/features/types/normalized-status.feature b/tests/features/types/normalized-status.feature index afdd1334..0cf4eba5 100644 --- a/tests/features/types/normalized-status.feature +++ b/tests/features/types/normalized-status.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:NormalizedStatusTesting -@libar-docs-status:active -@libar-docs-product-area:CoreTypes -@libar-docs-include:core-types +@architect +@architect-pattern:NormalizedStatusTesting +@architect-status:active +@architect-product-area:CoreTypes +@architect-include:core-types @taxonomy @status Feature: Normalized Status Taxonomy The normalized status module maps any status input — raw FSM states (roadmap, diff --git a/tests/features/types/result-monad.feature b/tests/features/types/result-monad.feature index b1823291..6e9550fd 100644 --- a/tests/features/types/result-monad.feature +++ b/tests/features/types/result-monad.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:ResultMonad -@libar-docs-status:completed -@libar-docs-product-area:CoreTypes -@libar-docs-include:core-types +@architect +@architect-pattern:ResultMonad +@architect-status:completed +@architect-product-area:CoreTypes +@architect-include:core-types @types @result Feature: Result Monad The Result type provides explicit error handling via a discriminated union. diff --git a/tests/features/types/tag-registry-builder.feature b/tests/features/types/tag-registry-builder.feature index 75d40f01..66ea13b9 100644 --- a/tests/features/types/tag-registry-builder.feature +++ b/tests/features/types/tag-registry-builder.feature @@ -1,12 +1,12 @@ -@libar-docs -@libar-docs-pattern:TagRegistryBuilderTesting -@libar-docs-status:active -@libar-docs-product-area:CoreTypes -@libar-docs-include:core-types +@architect +@architect-pattern:TagRegistryBuilderTesting +@architect-status:active +@architect-product-area:CoreTypes +@architect-include:core-types @taxonomy @registry Feature: Tag Registry Builder The tag registry builder constructs a complete TagRegistry from TypeScript - constants. It is the single source of truth for the delivery-process + constants. It is the single source of truth for the Architect annotation taxonomy, providing tag definitions, categories, and format options used by scanners and extractors. diff --git a/tests/features/utils/file-cache.feature b/tests/features/utils/file-cache.feature index 56e95fd2..077cbced 100644 --- a/tests/features/utils/file-cache.feature +++ b/tests/features/utils/file-cache.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:FileCacheTesting -@libar-docs-status:active -@libar-docs-product-area:CoreTypes -@libar-docs-include:core-types +@architect +@architect-pattern:FileCacheTesting +@architect-status:active +@architect-product-area:CoreTypes +@architect-include:core-types @cache @utils Feature: File Cache The file cache provides request-scoped content caching for generation runs. diff --git a/tests/features/utils/git-branch-diff.feature b/tests/features/utils/git-branch-diff.feature index bd9c14d9..7e23c7f8 100644 --- a/tests/features/utils/git-branch-diff.feature +++ b/tests/features/utils/git-branch-diff.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:GitBranchDiffTesting -@libar-docs-status:active -@libar-docs-product-area:Generation -@libar-docs-implements:GitBranchDiff +@architect +@architect-pattern:GitBranchDiffTesting +@architect-status:active +@architect-product-area:Generation +@architect-implements:GitBranchDiff @git @branch-diff Feature: Git Branch Diff The branch diff utility returns changed files relative to a base branch for diff --git a/tests/features/utils/string-utils.feature b/tests/features/utils/string-utils.feature index 9d2e169b..758522ac 100644 --- a/tests/features/utils/string-utils.feature +++ b/tests/features/utils/string-utils.feature @@ -1,8 +1,8 @@ -@libar-docs -@libar-docs-pattern:StringUtils -@libar-docs-status:completed -@libar-docs-product-area:CoreTypes -@libar-docs-include:core-types +@architect +@architect-pattern:StringUtils +@architect-status:completed +@architect-product-area:CoreTypes +@architect-include:core-types @utils @strings Feature: String Utility Functions String utilities provide consistent text transformations across the codebase. diff --git a/tests/features/validation/anti-patterns.feature b/tests/features/validation/anti-patterns.feature index 0d9f4bb8..8cd36685 100644 --- a/tests/features/validation/anti-patterns.feature +++ b/tests/features/validation/anti-patterns.feature @@ -1,10 +1,10 @@ -@libar-docs +@architect @behavior @anti-patterns -@libar-docs-pattern:AntiPatternDetectorTesting -@libar-docs-implements:AntiPatternDetector -@libar-docs-status:completed -@libar-docs-product-area:Validation -@libar-docs-depends-on:DoDValidationTypes +@architect-pattern:AntiPatternDetectorTesting +@architect-implements:AntiPatternDetector +@architect-status:completed +@architect-product-area:Validation +@architect-depends-on:DoDValidationTypes Feature: Anti-Pattern Detection Detects violations of the dual-source documentation architecture and process hygiene issues that lead to documentation drift. @@ -27,7 +27,7 @@ Feature: Anti-Pattern Detection Rule: Process metadata should not appear in TypeScript code - **Invariant:** Process metadata tags (@libar-docs-status, @libar-docs-phase, etc.) must only appear in Gherkin feature files, never in TypeScript source code. + **Invariant:** Process metadata tags (@architect-status, @architect-phase, etc.) must only appear in Gherkin feature files, never in TypeScript source code. **Rationale:** TypeScript owns runtime behavior while Gherkin owns delivery process metadata — mixing them creates dual-source conflicts and validation ambiguity. **Verified by:** Code without process tags passes, Feature-only process tags in code are flagged @@ -35,10 +35,10 @@ Feature: Anti-Pattern Detection Scenario: Code without process tags passes Given a TypeScript file with directive tags: | tag | - | @libar-docs | - | @libar-docs-pattern | - | @libar-docs-status | - | @libar-docs-depends-on | + | @architect | + | @architect-pattern | + | @architect-status | + | @architect-depends-on | When detecting process-in-code anti-patterns Then no violations are found @@ -52,12 +52,12 @@ Feature: Anti-Pattern Detection Examples: | process_tag | - | @libar-docs-quarter | - | @libar-docs-team | - | @libar-docs-effort | - | @libar-docs-workflow | - | @libar-docs-completed | - | @libar-docs-effort-actual | + | @architect-quarter | + | @architect-team | + | @architect-effort | + | @architect-workflow | + | @architect-completed | + | @architect-effort-actual | # ========================================================================== # Magic Comments Detection @@ -164,8 +164,8 @@ Feature: Anti-Pattern Detection Scenario: Combined detection finds process-in-code issues Given a TypeScript file with directive tags: | tag | - | @libar-docs | - | @libar-docs-quarter | + | @architect | + | @architect-quarter | And a feature file with tags: | tag | | libar-docs-pattern:MyTest | diff --git a/tests/features/validation/codec-utils.feature b/tests/features/validation/codec-utils.feature index d0ca78c1..53d55f6e 100644 --- a/tests/features/validation/codec-utils.feature +++ b/tests/features/validation/codec-utils.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:CodecUtilsValidation -@libar-docs-status:active -@libar-docs-product-area:Validation +@architect +@architect-pattern:CodecUtilsValidation +@architect-status:active +@architect-product-area:Validation @validation @codec Feature: Codec Utils Validation The codec utilities provide factory functions for creating type-safe JSON diff --git a/tests/features/validation/config-schemas.feature b/tests/features/validation/config-schemas.feature index 7a50b56c..a239ca72 100644 --- a/tests/features/validation/config-schemas.feature +++ b/tests/features/validation/config-schemas.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:ConfigSchemaValidation -@libar-docs-status:completed -@libar-docs-product-area:Validation +@architect +@architect-pattern:ConfigSchemaValidation +@architect-status:completed +@architect-product-area:Validation @validation @config @security Feature: Configuration Schema Validation Configuration schemas validate scanner and generator inputs with security diff --git a/tests/features/validation/detect-changes.feature b/tests/features/validation/detect-changes.feature index 31125a58..38a1f0c6 100644 --- a/tests/features/validation/detect-changes.feature +++ b/tests/features/validation/detect-changes.feature @@ -1,8 +1,8 @@ -@libar-docs -@behavior @detect-changes @libar-docs-pattern:DetectChangesTesting -@libar-docs-implements:DetectChanges -@libar-docs-status:completed -@libar-docs-product-area:Validation +@architect +@behavior @detect-changes @architect-pattern:DetectChangesTesting +@architect-implements:DetectChanges +@architect-status:completed +@architect-product-area:Validation Feature: Deliverable Change Detection from Git Diff Tests for the detectDeliverableChanges function that parses git diff output. Verifies that status changes are correctly identified as modifications, diff --git a/tests/features/validation/dod-validator.feature b/tests/features/validation/dod-validator.feature index 73c91216..73438a7e 100644 --- a/tests/features/validation/dod-validator.feature +++ b/tests/features/validation/dod-validator.feature @@ -1,10 +1,10 @@ -@libar-docs -@libar-docs-implements:DoDValidation +@architect +@architect-implements:DoDValidation @behavior @dod-validation -@libar-docs-pattern:DoDValidatorTesting -@libar-docs-status:completed -@libar-docs-product-area:Validation -@libar-docs-depends-on:AntiPatternDetector +@architect-pattern:DoDValidatorTesting +@architect-status:completed +@architect-product-area:Validation +@architect-depends-on:AntiPatternDetector Feature: Definition of Done (DoD) Validation Validates that completed phases meet Definition of Done criteria: 1. All deliverables must have "complete" status diff --git a/tests/features/validation/fsm-validator.feature b/tests/features/validation/fsm-validator.feature index 7e9fce7f..45b7673f 100644 --- a/tests/features/validation/fsm-validator.feature +++ b/tests/features/validation/fsm-validator.feature @@ -1,10 +1,10 @@ -@libar-docs -@libar-docs-implements:PhaseStateMachineValidation +@architect +@architect-implements:PhaseStateMachineValidation @behavior @fsm-validation -@libar-docs-pattern:FSMValidatorTesting -@libar-docs-status:completed -@libar-docs-product-area:Validation -@libar-docs-depends-on:FSMTransitions,FSMStates +@architect-pattern:FSMValidatorTesting +@architect-status:completed +@architect-product-area:Validation +@architect-depends-on:FSMTransitions,FSMStates Feature: Phase State Machine Validation Pure validation functions for the 4-state FSM defined in PDR-005. All validation follows the Decider pattern: no I/O, no side effects. @@ -146,7 +146,7 @@ Feature: Phase State Machine Validation Given a pattern with status "completed" When validating completion metadata Then validation passes - And warnings include "missing @libar-docs-completed date" + And warnings include "missing @architect-completed date" @edge-case Scenario: Completed pattern with planned but no actual effort shows warning @@ -155,7 +155,7 @@ Feature: Phase State Machine Validation And the pattern has effort planned "4h" When validating completion metadata Then validation passes - And warnings include "missing @libar-docs-effort-actual" + And warnings include "missing @architect-effort-actual" @happy-path Scenario: Non-completed pattern skips metadata validation diff --git a/tests/features/validation/process-guard.feature b/tests/features/validation/process-guard.feature index baad1889..fc7c2ac5 100644 --- a/tests/features/validation/process-guard.feature +++ b/tests/features/validation/process-guard.feature @@ -1,10 +1,10 @@ -@libar-docs -@libar-docs-implements:ProcessGuardLinter -@behavior @process-guard @libar-docs-pattern:ProcessGuardTesting -@libar-docs-status:completed -@libar-docs-product-area:Validation -@libar-docs-depends-on:PhaseStateMachineValidation,AntiPatternDetector -@libar-docs-include:reference-sample +@architect +@architect-implements:ProcessGuardLinter +@behavior @process-guard @architect-pattern:ProcessGuardTesting +@architect-status:completed +@architect-product-area:Validation +@architect-depends-on:PhaseStateMachineValidation,AntiPatternDetector +@architect-include:reference-sample Feature: Process Guard Linter Pure validation functions for enforcing delivery process rules per PDR-005. All validation follows the Decider pattern: (state, changes, options) => result. @@ -31,7 +31,7 @@ Feature: Process Guard Linter Rule: Completed files require unlock-reason to modify - **Invariant:** A completed spec file cannot be modified unless it carries an @libar-docs-unlock-reason tag. + **Invariant:** A completed spec file cannot be modified unless it carries an @architect-unlock-reason tag. **Rationale:** Completed work represents validated, shipped functionality — accidental modification risks regression. **Verified by:** Completed file with unlock-reason passes validation, Completed file without unlock-reason fails validation, Protection levels and unlock requirement, File transitioning to completed does not require unlock-reason diff --git a/tests/features/validation/status-transition-detection.feature b/tests/features/validation/status-transition-detection.feature index 11811d45..47c5f4e2 100644 --- a/tests/features/validation/status-transition-detection.feature +++ b/tests/features/validation/status-transition-detection.feature @@ -1,8 +1,8 @@ -@libar-docs -@behavior @status-transitions @libar-docs-pattern:StatusTransitionDetectionTesting -@libar-docs-implements:DetectChanges -@libar-docs-status:completed -@libar-docs-product-area:Validation +@architect +@behavior @status-transitions @architect-pattern:StatusTransitionDetectionTesting +@architect-implements:DetectChanges +@architect-status:completed +@architect-product-area:Validation Feature: Status Transition Detection from Git Diff Tests for the detectStatusTransitions function that parses git diff output. Verifies that status tags inside docstrings are ignored and only file-level @@ -17,7 +17,7 @@ Feature: Status Transition Detection from Git Diff Rule: Status transitions are detected from file-level tags - **Invariant:** Status transitions must be detected by comparing @libar-docs-status tags at the file level between the old and new versions of a file. + **Invariant:** Status transitions must be detected by comparing @architect-status tags at the file level between the old and new versions of a file. **Rationale:** File-level tags are the canonical source of pattern status — detecting transitions from tags ensures consistency with the FSM validator. **Verified by:** New file with status tag is detected as transition from roadmap, Modified file with status change is detected, No transition when status unchanged @@ -57,9 +57,9 @@ Feature: Status Transition Detection from Git Diff Scenario: Status tag inside docstring is not used for transition Given a git diff for new file "specs/test.feature" with: | line | content | - | 2 | @libar-docs-status:active | + | 2 | @architect-status:active | | 10 | """ | - | 11 | @libar-docs-status:completed | + | 11 | @architect-status:completed | | 12 | """ | When detecting status transitions Then a transition is detected for "specs/test.feature" @@ -70,12 +70,12 @@ Feature: Status Transition Detection from Git Diff Scenario: Multiple docstring status tags are all ignored Given a git diff for new file "specs/multi-docstring.feature" with: | line | content | - | 2 | @libar-docs-status:active | + | 2 | @architect-status:active | | 15 | """ | - | 16 | @libar-docs-status:roadmap | + | 16 | @architect-status:roadmap | | 17 | """ | | 30 | """ | - | 31 | @libar-docs-status:completed | + | 31 | @architect-status:completed | | 32 | """ | When detecting status transitions Then a transition is detected for "specs/multi-docstring.feature" @@ -87,7 +87,7 @@ Feature: Status Transition Detection from Git Diff Given a git diff for new file "specs/only-docstring.feature" with: | line | content | | 5 | """ | - | 6 | @libar-docs-status:active | + | 6 | @architect-status:active | | 7 | """ | When detecting status transitions Then no transition is detected for "specs/only-docstring.feature" @@ -106,8 +106,8 @@ Feature: Status Transition Detection from Git Diff Scenario: First file-level tag wins over subsequent tags Given a git diff for new file "specs/multi-tag.feature" with: | line | content | - | 2 | @libar-docs-status:active | - | 50 | @libar-docs-status:completed | + | 2 | @architect-status:active | + | 50 | @architect-status:completed | When detecting status transitions Then a transition is detected for "specs/multi-tag.feature" And the transition is from "roadmap" to "active" diff --git a/tests/features/validation/tag-registry-schemas.feature b/tests/features/validation/tag-registry-schemas.feature index ff2de642..2ae84aa1 100644 --- a/tests/features/validation/tag-registry-schemas.feature +++ b/tests/features/validation/tag-registry-schemas.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:TagRegistrySchemasValidation -@libar-docs-status:active -@libar-docs-product-area:Validation +@architect +@architect-pattern:TagRegistrySchemasValidation +@architect-status:active +@architect-product-area:Validation @validation @tag-registry Feature: Tag Registry Schema Validation The tag registry configuration module provides schema-validated taxonomy @@ -36,7 +36,7 @@ Feature: Tag Registry Schema Validation @function:createDefaultTagRegistry Scenario: Default registry has expected tag prefix When I create a default tag registry - Then the registry tag prefix should be "@libar-docs-" + Then the registry tag prefix should be "@architect-" Rule: mergeTagRegistries deep-merges registries by tag @@ -59,7 +59,7 @@ Feature: Tag Registry Schema Validation @function:mergeTagRegistries Scenario: Merge replaces scalar fields when provided - Given a base registry with tag prefix "@libar-docs-" + Given a base registry with tag prefix "@architect-" When I merge with an override that sets tag prefix "@custom-" Then the merged registry tag prefix should be "@custom-" diff --git a/tests/features/validation/workflow-config-schemas.feature b/tests/features/validation/workflow-config-schemas.feature index 7963e970..46e6112f 100644 --- a/tests/features/validation/workflow-config-schemas.feature +++ b/tests/features/validation/workflow-config-schemas.feature @@ -1,7 +1,7 @@ -@libar-docs -@libar-docs-pattern:WorkflowConfigSchemasValidation -@libar-docs-status:active -@libar-docs-product-area:Validation +@architect +@architect-pattern:WorkflowConfigSchemasValidation +@architect-status:active +@architect-product-area:Validation @validation @workflow Feature: Workflow Config Schema Validation The workflow configuration module defines Zod schemas for validating diff --git a/tests/fixtures/dataset-factories.ts b/tests/fixtures/dataset-factories.ts index da764c1f..87d85b9a 100644 --- a/tests/fixtures/dataset-factories.ts +++ b/tests/fixtures/dataset-factories.ts @@ -6,7 +6,7 @@ * wrap the pattern factories and transformToMasterDataset to produce * fully-formed datasets with all pre-computed views. * - * @libar-docs + * @architect */ import type { ExtractedPattern } from '../../src/validation-schemas/index.js'; diff --git a/tests/fixtures/pattern-factories.ts b/tests/fixtures/pattern-factories.ts index aafa9996..8e4f5852 100644 --- a/tests/fixtures/pattern-factories.ts +++ b/tests/fixtures/pattern-factories.ts @@ -238,7 +238,7 @@ export function createTestPattern(options: TestPatternOptions = {}): ExtractedPa } = options; const directive: DocDirective = { - tags: [asDirectiveTag(`@libar-docs-${category}`)], + tags: [asDirectiveTag(`@architect-${category}`)], description, examples: [], position: { startLine: lines[0], endLine: lines[1] }, diff --git a/tests/fixtures/scanner-fixtures.ts b/tests/fixtures/scanner-fixtures.ts index 8f45fdb7..475bd49f 100644 --- a/tests/fixtures/scanner-fixtures.ts +++ b/tests/fixtures/scanner-fixtures.ts @@ -5,7 +5,7 @@ * These builders create various export types and directive configurations * needed to test the AST parser comprehensively. * - * @libar-docs + * @architect */ // ============================================================================= @@ -29,7 +29,7 @@ export type ExportType = | 'multiple-const'; /** - * Options for building TypeScript content with @libar-docs directives. + * Options for building TypeScript content with @architect directives. */ export interface TsContentOptions { /** Export type to generate */ @@ -56,14 +56,14 @@ export interface TsContentOptions { whenToUse?: string[]; /** When to use inline format (single string) */ whenToUseInline?: string; - /** Include file-level @libar-docs opt-in */ + /** Include file-level @architect opt-in */ includeFileOptIn?: boolean; /** Use asterisk bullets instead of dashes in When to Use */ useAsteriskBullets?: boolean; } /** - * Build TypeScript file content with @libar-docs directive. + * Build TypeScript file content with @architect directive. * * @example * ```typescript @@ -97,7 +97,7 @@ export function buildTsContent(options: TsContentOptions = {}): string { // File-level opt-in (separate comment block) if (includeFileOptIn) { - lines.push('/** @libar-docs */'); + lines.push('/** @architect */'); lines.push(''); } @@ -105,30 +105,27 @@ export function buildTsContent(options: TsContentOptions = {}): string { lines.push('/**'); // Category tags on first line - const categoryTags = [ - `@libar-docs-${category}`, - ...additionalTags.map((t) => `@libar-docs-${t}`), - ]; + const categoryTags = [`@architect-${category}`, ...additionalTags.map((t) => `@architect-${t}`)]; lines.push(` * ${categoryTags.join(' ')}`); // Pattern name if (patternName) { - lines.push(` * @libar-docs-pattern ${patternName}`); + lines.push(` * @architect-pattern ${patternName}`); } // Status if (status) { - lines.push(` * @libar-docs-status ${status}`); + lines.push(` * @architect-status ${status}`); } // Uses relationships if (uses.length > 0) { - lines.push(` * @libar-docs-uses ${uses.join(', ')}`); + lines.push(` * @architect-uses ${uses.join(', ')}`); } // Used-by relationships if (usedBy.length > 0) { - lines.push(` * @libar-docs-used-by ${usedBy.join(', ')}`); + lines.push(` * @architect-used-by ${usedBy.join(', ')}`); } // Description @@ -232,10 +229,10 @@ function buildExportStatement(exportType: ExportType, name: string): string { */ export function buildContentWithTagsInDescription(category: string): string { return `/** - * @libar-docs-${category} + * @architect-${category} * - * This function works with @libar-docs-api patterns. - * It supports @libar-docs-saga for orchestration. + * This function works with @architect-api patterns. + * It supports @architect-saga for orchestration. */ export function processRequest() { return true; @@ -247,17 +244,17 @@ export function processRequest() { */ export function buildContentWithTagsInExample(category: string): string { return `/** - * @libar-docs-${category} + * @architect-${category} * Test function * * @example * \`\`\`typescript - * hasTag('@libar-docs-example'); // checking for a tag - * hasTag('@libar-docs-saga'); // another example + * hasTag('@architect-example'); // checking for a tag + * hasTag('@architect-saga'); // another example * \`\`\` */ export function hasTag(tag: string): boolean { - return tag.startsWith('@libar-docs'); + return tag.startsWith('@architect'); }`; } @@ -270,7 +267,7 @@ export function buildContentWithMultipleDirectives( return items .map( (item) => `/** - * @libar-docs-${item.category} + * @architect-${item.category} * ${item.description} */ export function ${item.name}() { @@ -285,7 +282,7 @@ export function ${item.name}() { */ export function buildMalformedTsContent(): string { return `/** - * @libar-docs-core + * @architect-core * This will fail to parse */ export function broken( @@ -299,7 +296,7 @@ export function buildContentWithLineNumbers(): string { return `// Line 1 // Line 2 /** - * @libar-docs-core + * @architect-core * Test */ export function test() { @@ -308,7 +305,7 @@ export function test() { } /** - * Build content without @libar-docs-* tags (regular JSDoc). + * Build content without @architect-* tags (regular JSDoc). */ export function buildContentWithoutDirective(): string { return `/** @@ -325,7 +322,7 @@ export function regular(foo: string) { * Build content with inline comment (not block comment). */ export function buildContentWithInlineComment(): string { - return `// @libar-docs-core - This is an inline comment + return `// @architect-core - This is an inline comment export function test() { return 'test'; }`; @@ -336,7 +333,7 @@ export function test() { */ export function buildContentWithJsDocTags(): string { return `/** - * @libar-docs-core + * @architect-core * Test function * * @param input - The input string @@ -352,7 +349,7 @@ export function test(input: string): string { */ export function buildContentWithUnicode(): string { return `/** - * @libar-docs-core + * @architect-core * Función de autenticación con émojis */ export function autenticar() { @@ -365,7 +362,7 @@ export function autenticar() { */ export function buildContentWithMultilineDescription(): string { return `/** - * @libar-docs-core + * @architect-core * * This is a detailed description * that spans multiple lines @@ -417,7 +414,7 @@ export interface GherkinContentOptions { } /** - * Build Gherkin feature file content with @libar-docs-* tags. + * Build Gherkin feature file content with @architect-* tags. * * @example * ```typescript @@ -462,33 +459,33 @@ Scenario: Orphan scenario const lines: string[] = []; - // Process metadata tags (using @libar-docs-* prefix per PDR-004) + // Process metadata tags (using @architect-* prefix per PDR-004) if (phase !== undefined) { - lines.push(`@libar-docs-phase:${phase}`); + lines.push(`@architect-phase:${phase}`); } if (status) { - lines.push(`@libar-docs-status:${status}`); + lines.push(`@architect-status:${status}`); } if (quarter) { - lines.push(`@libar-docs-quarter:${quarter}`); + lines.push(`@architect-quarter:${quarter}`); } if (effort) { - lines.push(`@libar-docs-effort:${effort}`); + lines.push(`@architect-effort:${effort}`); } if (team) { - lines.push(`@libar-docs-team:${team}`); + lines.push(`@architect-team:${team}`); } if (patternName) { - lines.push(`@libar-docs-pattern:${patternName}`); + lines.push(`@architect-pattern:${patternName}`); } if (briefPath) { - lines.push(`@libar-docs-brief:${briefPath}`); + lines.push(`@architect-brief:${briefPath}`); } for (const dep of dependencies) { - lines.push(`@libar-docs-depends-on:${dep}`); + lines.push(`@architect-depends-on:${dep}`); } for (const enable of enables) { - lines.push(`@libar-docs-enables:${enable}`); + lines.push(`@architect-enables:${enable}`); } for (const cat of categories) { lines.push(`@${cat}`); @@ -502,7 +499,7 @@ Scenario: Orphan scenario // Scenarios for (const scenario of scenarios) { if (scenario.status) { - lines.push(` @libar-docs-status:${scenario.status}`); + lines.push(` @architect-status:${scenario.status}`); } lines.push(` Scenario: ${scenario.name}`); lines.push(` Given some precondition`); diff --git a/tests/planning-stubs/architecture/sequence-diagram.feature b/tests/planning-stubs/architecture/sequence-diagram.feature index 671e786a..f42d822e 100644 --- a/tests/planning-stubs/architecture/sequence-diagram.feature +++ b/tests/planning-stubs/architecture/sequence-diagram.feature @@ -1,9 +1,9 @@ -@libar-docs -@libar-docs-pattern:SequenceDiagramGeneration -@libar-docs-status:roadmap -@libar-docs-implements:ArchitectureDiagramGeneration -@libar-docs-phase:23 -@libar-docs-product-area:DeliveryProcess +@architect +@architect-pattern:SequenceDiagramGeneration +@architect-status:roadmap +@architect-implements:ArchitectureDiagramGeneration +@architect-phase:23 +@architect-product-area:DeliveryProcess @architecture @future Feature: Sequence Diagram Generation diff --git a/tests/planning-stubs/architecture/sequence-diagram.steps.ts b/tests/planning-stubs/architecture/sequence-diagram.steps.ts index bda6867f..67f24879 100644 --- a/tests/planning-stubs/architecture/sequence-diagram.steps.ts +++ b/tests/planning-stubs/architecture/sequence-diagram.steps.ts @@ -6,7 +6,7 @@ * * STATUS: NOT IMPLEMENTED - Move to tests/steps/architecture/ when ready. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/api/architecture-queries/arch-queries.steps.ts b/tests/steps/api/architecture-queries/arch-queries.steps.ts index 8f9e8cf9..4228f1a3 100644 --- a/tests/steps/api/architecture-queries/arch-queries.steps.ts +++ b/tests/steps/api/architecture-queries/arch-queries.steps.ts @@ -322,7 +322,7 @@ describeFeature(feature, ({ Background, Rule }) => { createTestPattern({ name: 'FeaturePattern', filePath: 'specs/handler.feature' }), createTestPattern({ name: 'StubPattern', - filePath: 'delivery-process/stubs/handler/stub.ts', + filePath: 'architect/stubs/handler/stub.ts', }) ); buildDataset(); diff --git a/tests/steps/api/context-assembly/context-assembler.steps.ts b/tests/steps/api/context-assembly/context-assembler.steps.ts index 3b8064a1..c82b187e 100644 --- a/tests/steps/api/context-assembly/context-assembler.steps.ts +++ b/tests/steps/api/context-assembly/context-assembler.steps.ts @@ -89,7 +89,7 @@ describeFeature(feature, ({ Rule }) => { name, status: status as 'roadmap' | 'active' | 'completed' | 'deferred', phase, - filePath: `delivery-process/specs/${name.toLowerCase()}.feature`, + filePath: `architect/specs/${name.toLowerCase()}.feature`, deliverables: [ { name: 'API design', status: 'pending', tests: 0, location: 'src/api/design.ts' }, { @@ -141,7 +141,7 @@ describeFeature(feature, ({ Rule }) => { createTestPattern({ name: 'OrderSagaStub', status: 'roadmap', - filePath: 'delivery-process/stubs/order-saga/saga.ts', + filePath: 'architect/stubs/order-saga/saga.ts', implementsPatterns: ['OrderSaga'], targetPath: 'src/domain/order-saga.ts', }) @@ -222,7 +222,7 @@ describeFeature(feature, ({ Rule }) => { name, status: status as 'roadmap' | 'active' | 'completed' | 'deferred', phase, - filePath: `delivery-process/specs/${name.toLowerCase()}.feature`, + filePath: `architect/specs/${name.toLowerCase()}.feature`, }) ); } @@ -286,7 +286,7 @@ describeFeature(feature, ({ Rule }) => { name, status: status as 'roadmap' | 'active' | 'completed' | 'deferred', phase, - filePath: `delivery-process/specs/${name.toLowerCase()}.feature`, + filePath: `architect/specs/${name.toLowerCase()}.feature`, deliverables: [ { name: 'Core types', status: 'complete', tests: 1, location: 'src/types.ts' }, { name: 'Validation', status: 'pending', tests: 0, location: 'src/validate.ts' }, @@ -354,7 +354,7 @@ describeFeature(feature, ({ Rule }) => { name, status: status as 'roadmap' | 'active' | 'completed' | 'deferred', phase, - filePath: `delivery-process/specs/${name.toLowerCase()}.feature`, + filePath: `architect/specs/${name.toLowerCase()}.feature`, dependsOn: [dep], }) ); @@ -369,7 +369,7 @@ describeFeature(feature, ({ Rule }) => { name, status: status as 'roadmap' | 'active' | 'completed' | 'deferred', phase, - filePath: `delivery-process/specs/${name.toLowerCase()}.feature`, + filePath: `architect/specs/${name.toLowerCase()}.feature`, dependsOn: [dep], }) ); @@ -459,7 +459,7 @@ describeFeature(feature, ({ Rule }) => { name, status: 'roadmap', phase: 22, - filePath: `delivery-process/specs/${name.toLowerCase()}.feature`, + filePath: `architect/specs/${name.toLowerCase()}.feature`, }); state.patterns.push({ ...base, @@ -504,7 +504,7 @@ describeFeature(feature, ({ Rule }) => { name, status: 'roadmap', phase: 22, - filePath: `delivery-process/specs/${name.toLowerCase()}.feature`, + filePath: `architect/specs/${name.toLowerCase()}.feature`, }); state.patterns.push({ ...base, @@ -826,7 +826,7 @@ describeFeature(feature, ({ Rule }) => { createTestPattern({ name, status: 'roadmap', - filePath: `delivery-process/specs/${name.toLowerCase()}.feature`, + filePath: `architect/specs/${name.toLowerCase()}.feature`, dependsOn: ['CompletedDep', 'RoadmapDep'], }), createTestPattern({ @@ -837,7 +837,7 @@ describeFeature(feature, ({ Rule }) => { createTestPattern({ name: 'RoadmapDep', status: 'roadmap', - filePath: 'delivery-process/specs/roadmap-dep.feature', + filePath: 'architect/specs/roadmap-dep.feature', }), ]; buildDatasetAndApi(state.patterns); @@ -872,15 +872,15 @@ describeFeature(feature, ({ Rule }) => { createTestPattern({ name, status: 'roadmap', - filePath: `delivery-process/specs/${name.toLowerCase()}.feature`, + filePath: `architect/specs/${name.toLowerCase()}.feature`, dependsOn: [dep], }), createTestPattern({ name: dep, status: 'completed', - filePath: `delivery-process/specs/${dep.toLowerCase()}.feature`, + filePath: `architect/specs/${dep.toLowerCase()}.feature`, }), - // Implementation pattern that declares @libar-docs-implements CompletedLib + // Implementation pattern that declares @architect-implements CompletedLib createTestPattern({ name: `${dep}Impl`, status: 'completed', @@ -922,7 +922,7 @@ describeFeature(feature, ({ Rule }) => { createTestPattern({ name, status: 'roadmap', - filePath: `delivery-process/specs/${name.toLowerCase()}.feature`, + filePath: `architect/specs/${name.toLowerCase()}.feature`, dependsOn: ['SomeDep'], }), createTestPattern({ diff --git a/tests/steps/api/context-assembly/context-formatter.steps.ts b/tests/steps/api/context-assembly/context-formatter.steps.ts index 9ede0a5b..7406546f 100644 --- a/tests/steps/api/context-assembly/context-formatter.steps.ts +++ b/tests/steps/api/context-assembly/context-formatter.steps.ts @@ -58,14 +58,14 @@ function createDesignBundle(): ContextBundle { status: 'roadmap', phase: 22, category: 'agent', - file: 'delivery-process/specs/order-saga.feature', + file: 'architect/specs/order-saga.feature', summary: 'Orchestrates order lifecycle.', }, ], - specFiles: ['delivery-process/specs/order-saga.feature'], + specFiles: ['architect/specs/order-saga.feature'], stubs: [ { - stubFile: 'delivery-process/stubs/order-saga/saga.ts', + stubFile: 'architect/stubs/order-saga/saga.ts', targetPath: 'src/domain/order-saga.ts', }, ], @@ -97,11 +97,11 @@ function createImplementBundle(): ContextBundle { status: 'active', phase: 14, category: 'validation', - file: 'delivery-process/specs/process-guard.feature', + file: 'architect/specs/process-guard.feature', summary: 'Validates delivery workflow.', }, ], - specFiles: ['delivery-process/specs/process-guard.feature'], + specFiles: ['architect/specs/process-guard.feature'], stubs: [], dependencies: [], sharedDependencies: [], diff --git a/tests/steps/api/process-state-api.steps.ts b/tests/steps/api/process-state-api.steps.ts index cda71701..9d7a94a6 100644 --- a/tests/steps/api/process-state-api.steps.ts +++ b/tests/steps/api/process-state-api.steps.ts @@ -3,7 +3,7 @@ * * BDD step definitions for testing the ProcessStateAPI query interface. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/api/session-support/scope-validator.steps.ts b/tests/steps/api/session-support/scope-validator.steps.ts index 39d56011..02ae0fae 100644 --- a/tests/steps/api/session-support/scope-validator.steps.ts +++ b/tests/steps/api/session-support/scope-validator.steps.ts @@ -82,7 +82,7 @@ describeFeature(feature, ({ Rule }) => { }); const stub = createTestPattern({ name: 'MyStub', - filePath: 'delivery-process/stubs/MyPattern/my-stub.ts', + filePath: 'architect/stubs/MyPattern/my-stub.ts', status: 'roadmap', implementsPatterns: ['MyPattern'], targetPath: 'src/api/my-impl.ts', diff --git a/tests/steps/api/stub-integration/stub-resolver.steps.ts b/tests/steps/api/stub-integration/stub-resolver.steps.ts index e7e6edb6..b8d45e6f 100644 --- a/tests/steps/api/stub-integration/stub-resolver.steps.ts +++ b/tests/steps/api/stub-integration/stub-resolver.steps.ts @@ -66,7 +66,7 @@ describeFeature(feature, ({ Rule }) => { state = initState(); const stubPattern = createTestPattern({ name: 'StubA', - filePath: 'delivery-process/stubs/my-feature/stub-a.ts', + filePath: 'architect/stubs/my-feature/stub-a.ts', status: 'roadmap', }); const normalPattern = createTestPattern({ @@ -124,14 +124,14 @@ describeFeature(feature, ({ Rule }) => { state.patterns = [ createTestPattern({ name: 'ResolvedStub', - filePath: 'delivery-process/stubs/feat/resolved.ts', + filePath: 'architect/stubs/feat/resolved.ts', targetPath: 'src/api/resolved.ts', since: 'DS-A', implementsPatterns: ['FeatureA'], }), createTestPattern({ name: 'UnresolvedStub', - filePath: 'delivery-process/stubs/feat/unresolved.ts', + filePath: 'architect/stubs/feat/unresolved.ts', targetPath: 'src/api/unresolved.ts', since: 'DS-A', implementsPatterns: ['FeatureA'], diff --git a/tests/steps/api/stub-integration/taxonomy-tags.steps.ts b/tests/steps/api/stub-integration/taxonomy-tags.steps.ts index f38e84fd..27b51f47 100644 --- a/tests/steps/api/stub-integration/taxonomy-tags.steps.ts +++ b/tests/steps/api/stub-integration/taxonomy-tags.steps.ts @@ -1,7 +1,7 @@ /** * Taxonomy Tags Step Definitions * - * Tests for @libar-docs-target and @libar-docs-since tag registration. + * Tests for @architect-target and @architect-since tag registration. */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/architecture/arch-index.steps.ts b/tests/steps/architecture/arch-index.steps.ts index 883af20c..872a6384 100644 --- a/tests/steps/architecture/arch-index.steps.ts +++ b/tests/steps/architecture/arch-index.steps.ts @@ -5,7 +5,7 @@ * transformToMasterDataset. The archIndex groups patterns by role, * context, and layer for efficient architecture diagram generation. * - * @libar-docs + * @architect */ import { expect } from 'vitest'; diff --git a/tests/steps/architecture/arch-tag-extraction.steps.ts b/tests/steps/architecture/arch-tag-extraction.steps.ts index 722fa25d..08f2115b 100644 --- a/tests/steps/architecture/arch-tag-extraction.steps.ts +++ b/tests/steps/architecture/arch-tag-extraction.steps.ts @@ -5,7 +5,7 @@ * registry and AST parser. These tests verify that arch-role, arch-context, * and arch-layer tags are correctly defined and extracted. * - * @libar-docs + * @architect */ import { expect } from 'vitest'; diff --git a/tests/steps/architecture/component-diagram.steps.ts b/tests/steps/architecture/component-diagram.steps.ts index d04b1141..84c52098 100644 --- a/tests/steps/architecture/component-diagram.steps.ts +++ b/tests/steps/architecture/component-diagram.steps.ts @@ -5,7 +5,7 @@ * component diagram generation. Tests bounded context subgraphs, * relationship arrow rendering, and document structure. * - * @libar-docs + * @architect */ import { expect } from 'vitest'; @@ -106,7 +106,7 @@ function generateDiagram(): void { }); // Inject relationships into relationshipIndex - // (This simulates what the real pipeline would do from @libar-docs-uses tags) + // (This simulates what the real pipeline would do from @architect-uses tags) if (Object.keys(state.relationships).length > 0) { dataset.relationshipIndex = {}; for (const [name, rel] of Object.entries(state.relationships)) { diff --git a/tests/steps/architecture/generator-registration.steps.ts b/tests/steps/architecture/generator-registration.steps.ts index 1c06f332..1c000050 100644 --- a/tests/steps/architecture/generator-registration.steps.ts +++ b/tests/steps/architecture/generator-registration.steps.ts @@ -4,7 +4,7 @@ * BDD step definitions for testing the architecture generator * registration in the generator registry and CLI invocation. * - * @libar-docs + * @architect */ import { expect } from 'vitest'; diff --git a/tests/steps/architecture/layered-diagram.steps.ts b/tests/steps/architecture/layered-diagram.steps.ts index b4d8e423..b9b23678 100644 --- a/tests/steps/architecture/layered-diagram.steps.ts +++ b/tests/steps/architecture/layered-diagram.steps.ts @@ -5,7 +5,7 @@ * layered diagram generation. Tests layer subgraphs, * layer ordering, and context labels in nodes. * - * @libar-docs + * @architect */ import { expect } from 'vitest'; diff --git a/tests/steps/behavior/codecs/dedent.steps.ts b/tests/steps/behavior/codecs/dedent.steps.ts index 7ddf2848..cf75d52e 100644 --- a/tests/steps/behavior/codecs/dedent.steps.ts +++ b/tests/steps/behavior/codecs/dedent.steps.ts @@ -8,7 +8,7 @@ * - Unicode whitespace * - Relative indentation preservation * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/codecs/planning-codecs.steps.ts b/tests/steps/behavior/codecs/planning-codecs.steps.ts index 0bbec523..4ccebdfe 100644 --- a/tests/steps/behavior/codecs/planning-codecs.steps.ts +++ b/tests/steps/behavior/codecs/planning-codecs.steps.ts @@ -8,7 +8,7 @@ * * Tests document structure, sections, options, and content rendering. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/codecs/pr-changes-codec-options.steps.ts b/tests/steps/behavior/codecs/pr-changes-codec-options.steps.ts index 645dcd3b..23cca986 100644 --- a/tests/steps/behavior/codecs/pr-changes-codec-options.steps.ts +++ b/tests/steps/behavior/codecs/pr-changes-codec-options.steps.ts @@ -9,7 +9,7 @@ * - OR logic for combined filters * - Status filtering (active/completed only) * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/codecs/pr-changes-codec-rendering.steps.ts b/tests/steps/behavior/codecs/pr-changes-codec-rendering.steps.ts index 281db45a..a62cb25c 100644 --- a/tests/steps/behavior/codecs/pr-changes-codec-rendering.steps.ts +++ b/tests/steps/behavior/codecs/pr-changes-codec-rendering.steps.ts @@ -10,7 +10,7 @@ * - Deliverables rendering * - Acceptance criteria and business rules * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/codecs/reference-generators.steps.ts b/tests/steps/behavior/codecs/reference-generators.steps.ts index 86f02a2c..a51f5217 100644 --- a/tests/steps/behavior/codecs/reference-generators.steps.ts +++ b/tests/steps/behavior/codecs/reference-generators.steps.ts @@ -23,7 +23,7 @@ import { buildRegistry } from '../../../../src/taxonomy/registry-builder.js'; /** * Test configs: 7 product area configs + 2 manual reference configs. - * Mirrors the shape of delivery-process.config.ts. + * Mirrors the shape of architect.config.ts. */ const TEST_CONFIGS: readonly ReferenceDocConfig[] = [ ...createProductAreaConfigs(), diff --git a/tests/steps/behavior/codecs/reporting-codecs.steps.ts b/tests/steps/behavior/codecs/reporting-codecs.steps.ts index 5a3d9be9..625a927d 100644 --- a/tests/steps/behavior/codecs/reporting-codecs.steps.ts +++ b/tests/steps/behavior/codecs/reporting-codecs.steps.ts @@ -8,7 +8,7 @@ * * Tests document structure, sections, options, and formatting. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/codecs/requirements-adr-codecs.steps.ts b/tests/steps/behavior/codecs/requirements-adr-codecs.steps.ts index f387f61e..7ec31cde 100644 --- a/tests/steps/behavior/codecs/requirements-adr-codecs.steps.ts +++ b/tests/steps/behavior/codecs/requirements-adr-codecs.steps.ts @@ -7,7 +7,7 @@ * * Tests document structure, groupBy options, status filtering, and detail file generation. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/codecs/session-codecs.steps.ts b/tests/steps/behavior/codecs/session-codecs.steps.ts index 5356c935..224e5be3 100644 --- a/tests/steps/behavior/codecs/session-codecs.steps.ts +++ b/tests/steps/behavior/codecs/session-codecs.steps.ts @@ -7,7 +7,7 @@ * * Tests document structure, sections, options, and detail file generation. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/codecs/timeline-codecs.steps.ts b/tests/steps/behavior/codecs/timeline-codecs.steps.ts index 6493dce7..13c07123 100644 --- a/tests/steps/behavior/codecs/timeline-codecs.steps.ts +++ b/tests/steps/behavior/codecs/timeline-codecs.steps.ts @@ -8,7 +8,7 @@ * * Tests document structure, sections, options, and detail file generation. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/context-inference.steps.ts b/tests/steps/behavior/context-inference.steps.ts index 3f759270..ae934bfb 100644 --- a/tests/steps/behavior/context-inference.steps.ts +++ b/tests/steps/behavior/context-inference.steps.ts @@ -5,7 +5,7 @@ * in transformToMasterDataset. This feature infers bounded context from * file paths when patterns have archLayer but no explicit archContext. * - * @libar-docs + * @architect */ import { expect } from 'vitest'; diff --git a/tests/steps/behavior/description-headers.steps.ts b/tests/steps/behavior/description-headers.steps.ts index bb914d83..2857bd27 100644 --- a/tests/steps/behavior/description-headers.steps.ts +++ b/tests/steps/behavior/description-headers.steps.ts @@ -5,7 +5,7 @@ * Tests the stripLeadingHeaders utility and its integration with pattern * detail document generation. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/description-quality-foundation.steps.ts b/tests/steps/behavior/description-quality-foundation.steps.ts index 60e44323..93ed090a 100644 --- a/tests/steps/behavior/description-quality-foundation.steps.ts +++ b/tests/steps/behavior/description-quality-foundation.steps.ts @@ -5,7 +5,7 @@ * human-readable display names, behavior file verification, PRD formatting, * and business value display. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/directive-detection.steps.ts b/tests/steps/behavior/directive-detection.steps.ts index b26b34e8..f087a863 100644 --- a/tests/steps/behavior/directive-detection.steps.ts +++ b/tests/steps/behavior/directive-detection.steps.ts @@ -2,9 +2,9 @@ * Directive Detection Step Definitions * * BDD step definitions for testing hasDocDirectives and hasFileOptIn - * functions which detect @libar-docs directives in source code content. + * functions which detect @architect directives in source code content. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -47,18 +47,18 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { }); // =========================================================================== - // Rule: hasDocDirectives detects @libar-docs-* section directives + // Rule: hasDocDirectives detects @architect-* section directives // =========================================================================== Rule( - 'hasDocDirectives detects @libar-docs-* section directives', + 'hasDocDirectives detects @architect-* section directives', ({ RuleScenario, RuleScenarioOutline }) => { - RuleScenario('Detect @libar-docs-core directive in JSDoc block', ({ Given, When, Then }) => { - Given('source code with JSDoc containing "@libar-docs-core"', () => { + RuleScenario('Detect @architect-core directive in JSDoc block', ({ Given, When, Then }) => { + Given('source code with JSDoc containing "@architect-core"', () => { state = initState(); state.sourceCode = ` /** - * @libar-docs-core + * @architect-core * Test function */ export function test() {} @@ -75,7 +75,7 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { }); RuleScenarioOutline( - 'Detect various @libar-docs-* directives', + 'Detect various @architect-* directives', ({ Given, When, Then }, variables: { directive: string }) => { Given('source code containing directive {string}', () => { state = initState(); @@ -100,7 +100,7 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { export function foo() {} /** - * @libar-docs-core + * @architect-core */ export function bar() {} @@ -212,21 +212,21 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { ); // =========================================================================== - // Rule: hasFileOptIn detects file-level @libar-docs marker + // Rule: hasFileOptIn detects file-level @architect marker // =========================================================================== - Rule('hasFileOptIn detects file-level @libar-docs marker', ({ RuleScenario }) => { - RuleScenario('Detect @libar-docs in JSDoc block comment', ({ Given, When, Then }) => { - Given('source code with file-level "@libar-docs" opt-in', () => { + Rule('hasFileOptIn detects file-level @architect marker', ({ RuleScenario }) => { + RuleScenario('Detect @architect in JSDoc block comment', ({ Given, When, Then }) => { + Given('source code with file-level "@architect" opt-in', () => { state = initState(); state.sourceCode = ` /** - * @libar-docs + * @architect * This file contains documented patterns */ /** - * @libar-docs-core + * @architect-core * Some function */ export function test() {} @@ -242,7 +242,7 @@ export function test() {} }); }); - RuleScenario('Detect @libar-docs with description on same line', ({ Given, When, Then }) => { + RuleScenario('Detect @architect with description on same line', ({ Given, When, Then }) => { Given('source code {string}', (_ctx: unknown, code: string) => { state = initState(); state.sourceCode = code; @@ -257,14 +257,14 @@ export function test() {} }); }); - RuleScenario('Detect @libar-docs in multi-line JSDoc', ({ Given, When, Then }) => { - Given('source code with @libar-docs in middle of multi-line JSDoc', () => { + RuleScenario('Detect @architect in multi-line JSDoc', ({ Given, When, Then }) => { + Given('source code with @architect in middle of multi-line JSDoc', () => { state = initState(); state.sourceCode = ` /** * File-level documentation * - * @libar-docs + * @architect * * This file contains important patterns. */ @@ -281,18 +281,18 @@ export const VERSION = '1.0.0'; }); }); - RuleScenario('Detect @libar-docs anywhere in file', ({ Given, When, Then }) => { - Given('source code with @libar-docs after other content', () => { + RuleScenario('Detect @architect anywhere in file', ({ Given, When, Then }) => { + Given('source code with @architect after other content', () => { state = initState(); state.sourceCode = ` export function foo() {} /** - * @libar-docs + * @architect */ /** - * @libar-docs-core + * @architect-core */ export function bar() {} `; @@ -307,7 +307,7 @@ export function bar() {} }); }); - RuleScenario('Detect @libar-docs combined with section tags', ({ Given, When, Then }) => { + RuleScenario('Detect @architect combined with section tags', ({ Given, When, Then }) => { Given('source code {string}', (_ctx: unknown, code: string) => { state = initState(); state.sourceCode = code; @@ -323,11 +323,11 @@ export function bar() {} }); RuleScenario('Return false when only section tags present', ({ Given, When, Then }) => { - Given('source code with only "@libar-docs-core" section tag', () => { + Given('source code with only "@architect-core" section tag', () => { state = initState(); state.sourceCode = ` /** - * @libar-docs-core + * @architect-core * Some function without file opt-in */ export function test() {} @@ -376,7 +376,7 @@ export function test() {} }); }); - RuleScenario('Return false for @libar-docs in line comment', ({ Given, When, Then }) => { + RuleScenario('Return false for @architect in line comment', ({ Given, When, Then }) => { Given('source code {string}', (_ctx: unknown, code: string) => { state = initState(); state.sourceCode = code; @@ -391,7 +391,7 @@ export function test() {} }); }); - RuleScenario('Not confuse @libar-docs-* with @libar-docs opt-in', ({ Given, When, Then }) => { + RuleScenario('Not confuse @architect-* with @architect opt-in', ({ Given, When, Then }) => { Given('source code {string}', (_ctx: unknown, code: string) => { state = initState(); state.sourceCode = code; diff --git a/tests/steps/behavior/error-handling.steps.ts b/tests/steps/behavior/error-handling.steps.ts index 7835be04..97cc6ff5 100644 --- a/tests/steps/behavior/error-handling.steps.ts +++ b/tests/steps/behavior/error-handling.steps.ts @@ -320,9 +320,9 @@ describeFeature(feature, ({ Background, AfterEachScenario, Rule }) => { }); }); - RuleScenario('Skip feature files without @libar-docs opt-in', ({ Given, When, Then }) => { - Given('a Gherkin feature file without @libar-docs opt-in marker', () => { - // Create a file with pattern tags but NO @libar-docs opt-in marker + RuleScenario('Skip feature files without @architect opt-in', ({ Given, When, Then }) => { + Given('a Gherkin feature file without @architect opt-in marker', () => { + // Create a file with pattern tags but NO @architect opt-in marker const noOptInFile: ScannedGherkinFile = { filePath: '/test/no-optin.feature', feature: { diff --git a/tests/steps/behavior/implementation-links.steps.ts b/tests/steps/behavior/implementation-links.steps.ts index 3a09450c..42afb5eb 100644 --- a/tests/steps/behavior/implementation-links.steps.ts +++ b/tests/steps/behavior/implementation-links.steps.ts @@ -5,7 +5,7 @@ * Tests that repository prefixes like "libar-platform/" are stripped from * implementation paths to generate correct relative links in pattern documents. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/layer-inference.steps.ts b/tests/steps/behavior/layer-inference.steps.ts index c0b156d0..4f9a796f 100644 --- a/tests/steps/behavior/layer-inference.steps.ts +++ b/tests/steps/behavior/layer-inference.steps.ts @@ -86,14 +86,11 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { } ); - RuleScenario( - 'Detect timeline features in delivery-process package', - ({ Given, When, Then }) => { - Given('the feature file path {string}', givenFeatureFilePath); - When('I infer the feature layer', whenInferFeatureLayer); - Then('the inferred layer should be {string}', thenInferredLayerShouldBe); - } - ); + RuleScenario('Detect timeline features in Architect package', ({ Given, When, Then }) => { + Given('the feature file path {string}', givenFeatureFilePath); + When('I infer the feature layer', whenInferFeatureLayer); + Then('the inferred layer should be {string}', thenInferredLayerShouldBe); + }); }); // =========================================================================== diff --git a/tests/steps/behavior/pattern-relationships/depends-on-tag.steps.ts b/tests/steps/behavior/pattern-relationships/depends-on-tag.steps.ts index 1981697d..08e537af 100644 --- a/tests/steps/behavior/pattern-relationships/depends-on-tag.steps.ts +++ b/tests/steps/behavior/pattern-relationships/depends-on-tag.steps.ts @@ -1,7 +1,7 @@ /** * Planning Dependency Tags Step Definitions * - * BDD step definitions for testing @libar-docs-depends-on and @libar-docs-enables + * BDD step definitions for testing @architect-depends-on and @architect-enables * tag extraction from Gherkin files. * * These step definitions test: diff --git a/tests/steps/behavior/pattern-relationships/extends-tag.steps.ts b/tests/steps/behavior/pattern-relationships/extends-tag.steps.ts index c6133051..4151dd55 100644 --- a/tests/steps/behavior/pattern-relationships/extends-tag.steps.ts +++ b/tests/steps/behavior/pattern-relationships/extends-tag.steps.ts @@ -1,7 +1,7 @@ /** * Extends Tag Step Definitions * - * BDD step definitions for testing @libar-docs-extends tag extraction + * BDD step definitions for testing @architect-extends tag extraction * and processing for pattern generalization relationships. * * These step definitions test: diff --git a/tests/steps/behavior/pattern-relationships/implements-tag.steps.ts b/tests/steps/behavior/pattern-relationships/implements-tag.steps.ts index 77152d44..98e38f05 100644 --- a/tests/steps/behavior/pattern-relationships/implements-tag.steps.ts +++ b/tests/steps/behavior/pattern-relationships/implements-tag.steps.ts @@ -1,8 +1,8 @@ /** * Implements Tag Step Definitions * - * BDD step definitions for testing @libar-docs-implements tag extraction - * and processing through the delivery-process pipeline. + * BDD step definitions for testing @architect-implements tag extraction + * and processing through the Architect pipeline. * * These step definitions test: * 1. Tag registry definition (data-driven extraction) @@ -209,8 +209,8 @@ describeFeature(feature, ({ Rule }) => { RuleScenario('CSV values are trimmed', ({ Given, When, Then }) => { Given('a TypeScript file with implements " Pattern1 , Pattern2 "', () => { state!.sourceCode = `/** - * @libar-docs - * @libar-docs-implements Pattern1 , Pattern2 + * @architect + * @architect-implements Pattern1 , Pattern2 */ export function test() {}`; }); diff --git a/tests/steps/behavior/pattern-relationships/linter-validation.steps.ts b/tests/steps/behavior/pattern-relationships/linter-validation.steps.ts index f6233cec..211fb9fa 100644 --- a/tests/steps/behavior/pattern-relationships/linter-validation.steps.ts +++ b/tests/steps/behavior/pattern-relationships/linter-validation.steps.ts @@ -62,7 +62,7 @@ function initState(): LinterValidationState { */ function createTestDirective(overrides: Partial = {}): DocDirective { return { - tags: [asDirectiveTag('@libar-docs-test')], + tags: [asDirectiveTag('@architect-test')], description: '', examples: [], position: { startLine: 1, endLine: 10 }, diff --git a/tests/steps/behavior/pattern-relationships/uses-tag.steps.ts b/tests/steps/behavior/pattern-relationships/uses-tag.steps.ts index 4c9fdfe0..b6646857 100644 --- a/tests/steps/behavior/pattern-relationships/uses-tag.steps.ts +++ b/tests/steps/behavior/pattern-relationships/uses-tag.steps.ts @@ -1,8 +1,8 @@ /** * Uses Tag Step Definitions * - * BDD step definitions for testing @libar-docs-uses and @libar-docs-used-by - * tag extraction and processing through the delivery-process pipeline. + * BDD step definitions for testing @architect-uses and @architect-used-by + * tag extraction and processing through the Architect pipeline. * * These step definitions test: * 1. Tag registry definition (CSV format) diff --git a/tests/steps/behavior/pattern-tag-extraction.steps.ts b/tests/steps/behavior/pattern-tag-extraction.steps.ts index 4f24297e..fd1f6ade 100644 --- a/tests/steps/behavior/pattern-tag-extraction.steps.ts +++ b/tests/steps/behavior/pattern-tag-extraction.steps.ts @@ -254,7 +254,7 @@ describeFeature(feature, ({ Rule, Background, BeforeEachScenario }) => { RuleScenario('libar-docs opt-in marker is NOT a category', ({ Given, When, Then, And }) => { Given('feature tags "libar-docs", "ddd", and "core"', () => { - // @libar-docs is the opt-in marker, NOT a domain category + // @architect is the opt-in marker, NOT a domain category // After normalization, it becomes "libar-docs" and should be excluded state!.tags = ['libar-docs', 'ddd', 'core']; }); diff --git a/tests/steps/behavior/pr-changes-generation.steps.ts b/tests/steps/behavior/pr-changes-generation.steps.ts index bd0abf75..3b29d202 100644 --- a/tests/steps/behavior/pr-changes-generation.steps.ts +++ b/tests/steps/behavior/pr-changes-generation.steps.ts @@ -15,7 +15,7 @@ * Tests markdown string output, complementing pr-changes-codec.steps.ts * which tests at the RenderableDocument level. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/remaining-work-enhancement.steps.ts b/tests/steps/behavior/remaining-work-enhancement.steps.ts index e2dd4de5..8f8d9af5 100644 --- a/tests/steps/behavior/remaining-work-enhancement.steps.ts +++ b/tests/steps/behavior/remaining-work-enhancement.steps.ts @@ -7,7 +7,7 @@ * - Quarter-based grouping * - Progressive disclosure * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/remaining-work-totals.steps.ts b/tests/steps/behavior/remaining-work-totals.steps.ts index e6546b93..bf5fb396 100644 --- a/tests/steps/behavior/remaining-work-totals.steps.ts +++ b/tests/steps/behavior/remaining-work-totals.steps.ts @@ -5,7 +5,7 @@ * Ensures summary counts match phase table sums and backlog patterns are counted * correctly using pattern.id rather than patternName. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/behavior/scanner-core.steps.ts b/tests/steps/behavior/scanner-core.steps.ts index 93d2bbe5..56df1ac4 100644 --- a/tests/steps/behavior/scanner-core.steps.ts +++ b/tests/steps/behavior/scanner-core.steps.ts @@ -5,7 +5,7 @@ * orchestrates file discovery, directive detection, and AST parsing * to extract documentation directives from TypeScript files. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -462,7 +462,7 @@ describeFeature(feature, ({ Rule, Background, AfterEachScenario }) => { ); RuleScenario( - 'Skip files without @libar-docs file-level opt-in', + 'Skip files without @architect file-level opt-in', ({ Given, When, Then, And }) => { Given( 'a file {string} with content:', @@ -499,7 +499,7 @@ describeFeature(feature, ({ Rule, Background, AfterEachScenario }) => { ); RuleScenario( - 'Not confuse @libar-docs-* with @libar-docs opt-in', + 'Not confuse @architect-* with @architect opt-in', ({ Given, When, Then, And }) => { Given( 'a file {string} with content:', @@ -524,7 +524,7 @@ describeFeature(feature, ({ Rule, Background, AfterEachScenario }) => { ); RuleScenario( - 'Detect @libar-docs opt-in combined with section tags', + 'Detect @architect opt-in combined with section tags', ({ Given, When, Then, And }) => { Given( 'a file {string} with content:', diff --git a/tests/steps/behavior/session-handoffs.steps.ts b/tests/steps/behavior/session-handoffs.steps.ts index f191f930..41ae015c 100644 --- a/tests/steps/behavior/session-handoffs.steps.ts +++ b/tests/steps/behavior/session-handoffs.steps.ts @@ -7,7 +7,7 @@ * - Template and checklist validation * - PROCESS_SETUP.md documentation * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/cli/data-api-cache.steps.ts b/tests/steps/cli/data-api-cache.steps.ts index c322c609..5a13c78c 100644 --- a/tests/steps/cli/data-api-cache.steps.ts +++ b/tests/steps/cli/data-api-cache.steps.ts @@ -5,8 +5,8 @@ * between CLI invocations: cache hits, mtime invalidation, * and --no-cache bypass. * - * @libar-docs - * @libar-docs-implements DataAPICLIErgonomics + * @architect + * @architect-implements DataAPICLIErgonomics */ import * as fs from 'node:fs'; diff --git a/tests/steps/cli/data-api-dryrun.steps.ts b/tests/steps/cli/data-api-dryrun.steps.ts index 474b87b5..d666ff08 100644 --- a/tests/steps/cli/data-api-dryrun.steps.ts +++ b/tests/steps/cli/data-api-dryrun.steps.ts @@ -4,8 +4,8 @@ * BDD step definitions for testing --dry-run mode: * pipeline scope display without processing. * - * @libar-docs - * @libar-docs-implements DataAPICLIErgonomics + * @architect + * @architect-implements DataAPICLIErgonomics */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/cli/data-api-help.steps.ts b/tests/steps/cli/data-api-help.steps.ts index 99f23af5..48932349 100644 --- a/tests/steps/cli/data-api-help.steps.ts +++ b/tests/steps/cli/data-api-help.steps.ts @@ -4,8 +4,8 @@ * BDD step definitions for testing per-subcommand help output, * global help, and unknown subcommand help fallback. * - * @libar-docs - * @libar-docs-implements DataAPICLIErgonomics + * @architect + * @architect-implements DataAPICLIErgonomics */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/cli/data-api-metadata.steps.ts b/tests/steps/cli/data-api-metadata.steps.ts index 24efea90..07d36c1f 100644 --- a/tests/steps/cli/data-api-metadata.steps.ts +++ b/tests/steps/cli/data-api-metadata.steps.ts @@ -4,8 +4,8 @@ * BDD step definitions for testing response metadata: * validation summary counts and pipeline timing. * - * @libar-docs - * @libar-docs-implements DataAPICLIErgonomics + * @architect + * @architect-implements DataAPICLIErgonomics */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/cli/data-api-repl.steps.ts b/tests/steps/cli/data-api-repl.steps.ts index ad722897..9129b13e 100644 --- a/tests/steps/cli/data-api-repl.steps.ts +++ b/tests/steps/cli/data-api-repl.steps.ts @@ -4,8 +4,8 @@ * BDD step definitions for testing the interactive REPL mode: * multi-query sessions, help output, and pipeline reload. * - * @libar-docs - * @libar-docs-implements DataAPICLIErgonomics + * @architect + * @architect-implements DataAPICLIErgonomics */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/cli/generate-docs.steps.ts b/tests/steps/cli/generate-docs.steps.ts index f754f0aa..a22c2b8f 100644 --- a/tests/steps/cli/generate-docs.steps.ts +++ b/tests/steps/cli/generate-docs.steps.ts @@ -4,8 +4,8 @@ * BDD step definitions for testing the generate-docs CLI * which generates documentation from annotated TypeScript. * - * @libar-docs - * @libar-docs-implements CliBehaviorTesting + * @architect + * @architect-implements CliBehaviorTesting */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -45,13 +45,13 @@ function initState(): CLITestState { // ============================================================================= function createPatternFile(): string { - return `/** @libar-docs */ + return `/** @architect */ /** - * @libar-docs-core - * @libar-docs-pattern TestGeneratorPattern - * @libar-docs-status completed - * @libar-docs-uses AnotherPattern + * @architect-core + * @architect-pattern TestGeneratorPattern + * @architect-status completed + * @architect-uses AnotherPattern * * ## TestGeneratorPattern * diff --git a/tests/steps/cli/generate-tag-taxonomy.steps.ts b/tests/steps/cli/generate-tag-taxonomy.steps.ts index da73c406..9ca28abb 100644 --- a/tests/steps/cli/generate-tag-taxonomy.steps.ts +++ b/tests/steps/cli/generate-tag-taxonomy.steps.ts @@ -4,8 +4,8 @@ * BDD step definitions for testing the generate-tag-taxonomy CLI * which generates TAG_TAXONOMY.md from tag registry configuration. * - * @libar-docs - * @libar-docs-implements CliBehaviorTesting + * @architect + * @architect-implements CliBehaviorTesting */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/cli/lint-patterns.steps.ts b/tests/steps/cli/lint-patterns.steps.ts index ac9f65be..b27ead76 100644 --- a/tests/steps/cli/lint-patterns.steps.ts +++ b/tests/steps/cli/lint-patterns.steps.ts @@ -4,8 +4,8 @@ * BDD step definitions for testing the lint-patterns CLI * which validates pattern annotation quality. * - * @libar-docs - * @libar-docs-implements CliBehaviorTesting + * @architect + * @architect-implements CliBehaviorTesting */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -44,13 +44,13 @@ function initState(): CLITestState { // ============================================================================= function createCompletePatternFile(): string { - return `/** @libar-docs */ + return `/** @architect */ /** - * @libar-docs-core - * @libar-docs-pattern TestPattern - * @libar-docs-status completed - * @libar-docs-uses AnotherPattern + * @architect-core + * @architect-pattern TestPattern + * @architect-status completed + * @architect-uses AnotherPattern * * ## TestPattern * @@ -65,11 +65,11 @@ export interface TestPattern { } function createMissingPatternNameFile(): string { - return `/** @libar-docs */ + return `/** @architect */ /** - * @libar-docs-core - * @libar-docs-status completed + * @architect-core + * @architect-status completed * * ## Some Pattern * @@ -82,15 +82,15 @@ export interface MissingName { } function createMissingStatusFile(): string { - return `/** @libar-docs */ + return `/** @architect */ /** - * @libar-docs-core - * @libar-docs-pattern WarningPattern + * @architect-core + * @architect-pattern WarningPattern * * ## WarningPattern * - * Missing @libar-docs-status tag (warning level). + * Missing @architect-status tag (warning level). * * ### When to Use * diff --git a/tests/steps/cli/lint-process.steps.ts b/tests/steps/cli/lint-process.steps.ts index 8dd9441c..ab4f88ad 100644 --- a/tests/steps/cli/lint-process.steps.ts +++ b/tests/steps/cli/lint-process.steps.ts @@ -4,8 +4,8 @@ * BDD step definitions for testing the lint-process CLI * which validates changes against delivery process rules. * - * @libar-docs - * @libar-docs-implements CliBehaviorTesting + * @architect + * @architect-implements CliBehaviorTesting */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -57,9 +57,9 @@ function initGitRepo(dir: string): void { // ============================================================================= function createFeatureFile(status: string): string { - return `@libar-docs-pattern:TestPattern -@libar-docs-phase:1 -@libar-docs-status:${status} + return `@architect-pattern:TestPattern +@architect-phase:1 +@architect-status:${status} Feature: Test Pattern A test feature for lint-process CLI testing. diff --git a/tests/steps/cli/process-api-core.steps.ts b/tests/steps/cli/process-api-core.steps.ts index d05eb4a1..0a266065 100644 --- a/tests/steps/cli/process-api-core.steps.ts +++ b/tests/steps/cli/process-api-core.steps.ts @@ -5,8 +5,8 @@ * core infrastructure: help, version, input validation, * status, query, pattern, arch basics, missing args, edge cases. * - * @libar-docs - * @libar-docs-implements ProcessStateAPICLI + * @architect + * @architect-implements ProcessStateAPICLI */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/cli/process-api-modifiers-rules.steps.ts b/tests/steps/cli/process-api-modifiers-rules.steps.ts index 2f19d0ac..821bb0b1 100644 --- a/tests/steps/cli/process-api-modifiers-rules.steps.ts +++ b/tests/steps/cli/process-api-modifiers-rules.steps.ts @@ -4,8 +4,8 @@ * BDD step definitions for testing the process-api CLI * output modifiers, arch health, and rules subcommand. * - * @libar-docs - * @libar-docs-implements ProcessStateAPICLI + * @architect + * @architect-implements ProcessStateAPICLI */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/cli/process-api-subcommands.steps.ts b/tests/steps/cli/process-api-subcommands.steps.ts index 8dca50bc..4daa3377 100644 --- a/tests/steps/cli/process-api-subcommands.steps.ts +++ b/tests/steps/cli/process-api-subcommands.steps.ts @@ -5,8 +5,8 @@ * discovery subcommands: list, search, context assembly, * tags/sources, extended arch, unannotated. * - * @libar-docs - * @libar-docs-implements ProcessStateAPICLI + * @architect + * @architect-implements ProcessStateAPICLI */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/cli/validate-patterns.steps.ts b/tests/steps/cli/validate-patterns.steps.ts index cd1a7050..a7693e4b 100644 --- a/tests/steps/cli/validate-patterns.steps.ts +++ b/tests/steps/cli/validate-patterns.steps.ts @@ -4,8 +4,8 @@ * BDD step definitions for testing the validate-patterns CLI * which cross-validates TypeScript patterns vs Gherkin feature files. * - * @libar-docs - * @libar-docs-implements CliBehaviorTesting + * @architect + * @architect-implements CliBehaviorTesting */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -44,13 +44,13 @@ function initState(): CLITestState { // ============================================================================= function createTypeScriptPatternFile(patternName: string, phase: number, status: string): string { - return `/** @libar-docs */ + return `/** @architect */ /** - * @libar-docs-core - * @libar-docs-pattern ${patternName} - * @libar-docs-phase ${phase} - * @libar-docs-status ${status} + * @architect-core + * @architect-pattern ${patternName} + * @architect-phase ${phase} + * @architect-status ${status} * * ## ${patternName} * @@ -78,10 +78,10 @@ function createGherkinPatternFile(patternName: string, phase: number, status: st ` : ''; - return `@libar-docs -@libar-docs-pattern:${patternName} -@libar-docs-phase:${phase} -@libar-docs-status:${status} + return `@architect +@architect-pattern:${patternName} +@architect-phase:${phase} +@architect-status:${status} Feature: ${patternName} Test feature for validate-patterns CLI testing. ${backgroundSection} diff --git a/tests/steps/config/config-loader.steps.ts b/tests/steps/config/config-loader.steps.ts index fe73a395..d6db7e50 100644 --- a/tests/steps/config/config-loader.steps.ts +++ b/tests/steps/config/config-loader.steps.ts @@ -5,7 +5,7 @@ * Uses temp directories with actual config files to test the full * config loading pipeline. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -40,8 +40,8 @@ interface ConfigLoaderState { // ============================================================================= const VALID_GENERIC_CONFIG = ` -import { createDeliveryProcess } from "./src/index.js"; -export default createDeliveryProcess({ preset: "generic" }); +import { createArchitect } from "./src/index.js"; +export default createArchitect({ preset: "generic" }); `.trim(); const NO_DEFAULT_EXPORT_CONFIG = ` @@ -115,8 +115,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { expect(state!.configPath).not.toBeNull(); }); - And('config path should end with "delivery-process.config.js"', () => { - expect(state!.configPath!).toMatch(/delivery-process\.config\.js$/); + And('config path should end with "architect.config.js"', () => { + expect(state!.configPath!).toMatch(/architect\.config\.js$/); }); }); @@ -134,8 +134,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { expect(state!.configPath).not.toBeNull(); }); - And('config path should end with "delivery-process.config.js"', () => { - expect(state!.configPath!).toMatch(/delivery-process\.config\.js$/); + And('config path should end with "architect.config.js"', () => { + expect(state!.configPath!).toMatch(/architect\.config\.js$/); }); }); @@ -152,8 +152,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { expect(state!.configPath).not.toBeNull(); }); - And('config path should end with "delivery-process.config.ts"', () => { - expect(state!.configPath!).toMatch(/delivery-process\.config\.ts$/); + And('config path should end with "architect.config.ts"', () => { + expect(state!.configPath!).toMatch(/architect\.config\.ts$/); }); }); @@ -222,9 +222,9 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { expect(state!.configResult!.value.isDefault).toBe(true); }); - And('loaded registry tagPrefix should be "@libar-docs-"', () => { + And('loaded registry tagPrefix should be "@architect-"', () => { if (!state!.configResult!.ok) throw new Error('Expected success'); - expect(state!.configResult!.value.instance.registry.tagPrefix).toBe('@libar-docs-'); + expect(state!.configResult!.value.instance.registry.tagPrefix).toBe('@architect-'); }); And('loaded registry should have exactly 3 categories', () => { @@ -259,7 +259,7 @@ export default { } }; `.trim(); - const configPath = path.join(state!.tempDir!, 'delivery-process.config.js'); + const configPath = path.join(state!.tempDir!, 'architect.config.js'); await fs.writeFile(configPath, configContent); }); @@ -284,7 +284,7 @@ export default { RuleScenario('Error on config without default export', ({ Given, When, Then, And }) => { Given('a config file without default export', async () => { - const configPath = path.join(state!.tempDir!, 'delivery-process.config.js'); + const configPath = path.join(state!.tempDir!, 'architect.config.js'); await fs.writeFile(configPath, NO_DEFAULT_EXPORT_CONFIG); }); @@ -304,7 +304,7 @@ export default { RuleScenario('Error on config with wrong type', ({ Given, When, Then, And }) => { Given('a config file exporting wrong type', async () => { - const configPath = path.join(state!.tempDir!, 'delivery-process.config.js'); + const configPath = path.join(state!.tempDir!, 'architect.config.js'); await fs.writeFile(configPath, WRONG_TYPE_CONFIG); }); @@ -316,9 +316,9 @@ export default { expect(state!.configResult!.ok).toBe(false); }); - And('config error message should contain "DeliveryProcessInstance"', () => { + And('config error message should contain "ArchitectInstance"', () => { if (state!.configResult!.ok) throw new Error('Expected failure'); - expect(state!.configResult!.error.message).toContain('DeliveryProcessInstance'); + expect(state!.configResult!.error.message).toContain('ArchitectInstance'); }); }); }); diff --git a/tests/steps/config/config-resolution.steps.ts b/tests/steps/config/config-resolution.steps.ts index 099d8fd6..6ccb7077 100644 --- a/tests/steps/config/config-resolution.steps.ts +++ b/tests/steps/config/config-resolution.steps.ts @@ -5,7 +5,7 @@ * createDefaultResolvedConfig, verifying defaults, source merging, * and context inference rule ordering. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -15,17 +15,14 @@ import { createDefaultResolvedConfig, } from '../../../src/config/resolve-config.js'; import { DEFAULT_CONTEXT_INFERENCE_RULES } from '../../../src/config/defaults.js'; -import type { - DeliveryProcessProjectConfig, - ResolvedConfig, -} from '../../../src/config/project-config.js'; +import type { ArchitectProjectConfig, ResolvedConfig } from '../../../src/config/project-config.js'; // ============================================================================= // Types // ============================================================================= interface ConfigResolutionState { - rawConfig: DeliveryProcessProjectConfig | null; + rawConfig: ArchitectProjectConfig | null; resolvedConfig: ResolvedConfig | null; resolveOptions: { readonly configPath: string } | undefined; } @@ -117,8 +114,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { expect(state!.resolvedConfig!.instance.registry.categories).toHaveLength(3); }); - And('the instance tagPrefix should be "@libar-docs-"', () => { - expect(state!.resolvedConfig!.instance.registry.tagPrefix).toBe('@libar-docs-'); + And('the instance tagPrefix should be "@architect-"', () => { + expect(state!.resolvedConfig!.instance.registry.tagPrefix).toBe('@architect-'); }); }); }); diff --git a/tests/steps/config/configuration-api.steps.ts b/tests/steps/config/configuration-api.steps.ts index 3c62d670..da2ee842 100644 --- a/tests/steps/config/configuration-api.steps.ts +++ b/tests/steps/config/configuration-api.steps.ts @@ -1,18 +1,18 @@ /** * Configuration API Step Definitions * - * BDD step definitions for testing the createDeliveryProcess factory + * BDD step definitions for testing the createArchitect factory * and configuration options. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; import { - createDeliveryProcess, + createArchitect, createRegexBuilders, - type CreateDeliveryProcessOptions, + type CreateArchitectOptions, } from '../../../src/config/index.js'; import type { TagRegistry } from '../../../src/validation-schemas/tag-registry.js'; import type { RegexBuilders } from '../../../src/config/types.js'; @@ -22,7 +22,7 @@ import type { RegexBuilders } from '../../../src/config/types.js'; // ============================================================================= interface ConfigurationTestState { - options: CreateDeliveryProcessOptions; + options: CreateArchitectOptions; registry: TagRegistry | null; regexBuilders: RegexBuilders | null; content: string; @@ -70,17 +70,17 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { Rule('Factory creates configured instances with correct defaults', ({ RuleScenario }) => { RuleScenario('Create with no arguments uses libar-generic preset', ({ When, Then, And }) => { - When('I call createDeliveryProcess without arguments', () => { - const dp = createDeliveryProcess(); + When('I call createArchitect without arguments', () => { + const dp = createArchitect(); state!.registry = dp.registry; }); - Then('the registry tagPrefix should be "@libar-docs-"', () => { - expect(state!.registry!.tagPrefix).toBe('@libar-docs-'); + Then('the registry tagPrefix should be "@architect-"', () => { + expect(state!.registry!.tagPrefix).toBe('@architect-'); }); - And('the registry fileOptInTag should be "@libar-docs"', () => { - expect(state!.registry!.fileOptInTag).toBe('@libar-docs'); + And('the registry fileOptInTag should be "@architect"', () => { + expect(state!.registry!.fileOptInTag).toBe('@architect'); }); And('the registry should have exactly 3 categories', () => { @@ -94,8 +94,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }); RuleScenario('Create with generic preset', ({ When, Then, And }) => { - When('I call createDeliveryProcess with preset "generic"', () => { - const dp = createDeliveryProcess({ preset: 'generic' }); + When('I call createArchitect with preset "generic"', () => { + const dp = createArchitect({ preset: 'generic' }); state!.registry = dp.registry; }); @@ -119,17 +119,17 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }); RuleScenario('Create with libar-generic preset', ({ When, Then, And }) => { - When('I call createDeliveryProcess with preset "libar-generic"', () => { - const dp = createDeliveryProcess({ preset: 'libar-generic' }); + When('I call createArchitect with preset "libar-generic"', () => { + const dp = createArchitect({ preset: 'libar-generic' }); state!.registry = dp.registry; }); - Then('the registry tagPrefix should be "@libar-docs-"', () => { - expect(state!.registry!.tagPrefix).toBe('@libar-docs-'); + Then('the registry tagPrefix should be "@architect-"', () => { + expect(state!.registry!.tagPrefix).toBe('@architect-'); }); - And('the registry fileOptInTag should be "@libar-docs"', () => { - expect(state!.registry!.fileOptInTag).toBe('@libar-docs'); + And('the registry fileOptInTag should be "@architect"', () => { + expect(state!.registry!.fileOptInTag).toBe('@architect'); }); And('the registry should have exactly 3 categories', () => { @@ -143,17 +143,17 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }); RuleScenario('Create with ddd-es-cqrs preset explicitly', ({ When, Then, And }) => { - When('I call createDeliveryProcess with preset "ddd-es-cqrs"', () => { - const dp = createDeliveryProcess({ preset: 'ddd-es-cqrs' }); + When('I call createArchitect with preset "ddd-es-cqrs"', () => { + const dp = createArchitect({ preset: 'ddd-es-cqrs' }); state!.registry = dp.registry; }); - Then('the registry tagPrefix should be "@libar-docs-"', () => { - expect(state!.registry!.tagPrefix).toBe('@libar-docs-'); + Then('the registry tagPrefix should be "@architect-"', () => { + expect(state!.registry!.tagPrefix).toBe('@architect-'); }); - And('the registry fileOptInTag should be "@libar-docs"', () => { - expect(state!.registry!.fileOptInTag).toBe('@libar-docs'); + And('the registry fileOptInTag should be "@architect"', () => { + expect(state!.registry!.fileOptInTag).toBe('@architect'); }); And('the registry should have 21 categories', () => { @@ -168,8 +168,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { Rule('Custom prefix configuration works correctly', ({ RuleScenario }) => { RuleScenario('Custom tag prefix overrides preset', ({ When, Then }) => { - When('I call createDeliveryProcess with tagPrefix "@custom-"', () => { - const dp = createDeliveryProcess({ tagPrefix: '@custom-' }); + When('I call createArchitect with tagPrefix "@custom-"', () => { + const dp = createArchitect({ tagPrefix: '@custom-' }); state!.registry = dp.registry; }); @@ -179,8 +179,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }); RuleScenario('Custom file opt-in tag overrides preset', ({ When, Then }) => { - When('I call createDeliveryProcess with fileOptInTag "@my-docs"', () => { - const dp = createDeliveryProcess({ fileOptInTag: '@my-docs' }); + When('I call createArchitect with fileOptInTag "@my-docs"', () => { + const dp = createArchitect({ fileOptInTag: '@my-docs' }); state!.registry = dp.registry; }); @@ -190,8 +190,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }); RuleScenario('Both prefix and opt-in tag can be customized together', ({ When, Then, And }) => { - When('I call createDeliveryProcess with tagPrefix "@proj-" and fileOptInTag "@proj"', () => { - const dp = createDeliveryProcess({ tagPrefix: '@proj-', fileOptInTag: '@proj' }); + When('I call createArchitect with tagPrefix "@proj-" and fileOptInTag "@proj"', () => { + const dp = createArchitect({ tagPrefix: '@proj-', fileOptInTag: '@proj' }); state!.registry = dp.registry; }); @@ -211,8 +211,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { Rule('Preset categories replace base categories entirely', ({ RuleScenario }) => { RuleScenario('Generic preset excludes DDD categories', ({ When, Then, And }) => { - When('I call createDeliveryProcess with preset "generic"', () => { - const dp = createDeliveryProcess({ preset: 'generic' }); + When('I call createArchitect with preset "generic"', () => { + const dp = createArchitect({ preset: 'generic' }); state!.registry = dp.registry; }); @@ -238,8 +238,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }); RuleScenario('Libar-generic preset excludes DDD categories', ({ When, Then, And }) => { - When('I call createDeliveryProcess with preset "libar-generic"', () => { - const dp = createDeliveryProcess({ preset: 'libar-generic' }); + When('I call createArchitect with preset "libar-generic"', () => { + const dp = createArchitect({ preset: 'libar-generic' }); state!.registry = dp.registry; }); diff --git a/tests/steps/config/define-config.steps.ts b/tests/steps/config/define-config.steps.ts index 0d55dd05..748e12b6 100644 --- a/tests/steps/config/define-config.steps.ts +++ b/tests/steps/config/define-config.steps.ts @@ -2,29 +2,29 @@ * Define Config Step Definitions * * BDD step definitions for testing the defineConfig identity function, - * DeliveryProcessProjectConfigSchema Zod validation, and type guard functions. + * ArchitectProjectConfigSchema Zod validation, and type guard functions. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; import { defineConfig } from '../../../src/config/define-config.js'; import { - DeliveryProcessProjectConfigSchema, + ArchitectProjectConfigSchema, GeneratorSourceOverrideSchema, isProjectConfig, isLegacyInstance, } from '../../../src/config/project-config-schema.js'; -import type { DeliveryProcessProjectConfig } from '../../../src/config/project-config.js'; +import type { ArchitectProjectConfig } from '../../../src/config/project-config.js'; // ============================================================================= // Types // ============================================================================= interface DefineConfigState { - inputConfig: DeliveryProcessProjectConfig | null; - resultConfig: DeliveryProcessProjectConfig | null; + inputConfig: ArchitectProjectConfig | null; + resultConfig: ArchitectProjectConfig | null; validationResult: { success: boolean; error?: { issues: Array<{ message: string }> } } | null; overrideValidationResult: { success: boolean; @@ -106,8 +106,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { state!.testObject = { preset: 'libar-generic' }; }); - When('validating against DeliveryProcessProjectConfigSchema', () => { - state!.validationResult = DeliveryProcessProjectConfigSchema.safeParse(state!.testObject); + When('validating against ArchitectProjectConfigSchema', () => { + state!.validationResult = ArchitectProjectConfigSchema.safeParse(state!.testObject); }); Then('validation should succeed', () => { @@ -145,8 +145,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }; }); - When('validating against DeliveryProcessProjectConfigSchema', () => { - state!.validationResult = DeliveryProcessProjectConfigSchema.safeParse(state!.testObject); + When('validating against ArchitectProjectConfigSchema', () => { + state!.validationResult = ArchitectProjectConfigSchema.safeParse(state!.testObject); }); Then('validation should succeed', () => { @@ -169,8 +169,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }; }); - When('validating against DeliveryProcessProjectConfigSchema', () => { - state!.validationResult = DeliveryProcessProjectConfigSchema.safeParse(state!.testObject); + When('validating against ArchitectProjectConfigSchema', () => { + state!.validationResult = ArchitectProjectConfigSchema.safeParse(state!.testObject); }); Then('validation should fail', () => { @@ -194,8 +194,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }; }); - When('validating against DeliveryProcessProjectConfigSchema', () => { - state!.validationResult = DeliveryProcessProjectConfigSchema.safeParse(state!.testObject); + When('validating against ArchitectProjectConfigSchema', () => { + state!.validationResult = ArchitectProjectConfigSchema.safeParse(state!.testObject); }); Then('validation should fail', () => { @@ -244,8 +244,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { state!.testObject = { preset: 'nonexistent-preset' }; }); - When('validating against DeliveryProcessProjectConfigSchema', () => { - state!.validationResult = DeliveryProcessProjectConfigSchema.safeParse(state!.testObject); + When('validating against ArchitectProjectConfigSchema', () => { + state!.validationResult = ArchitectProjectConfigSchema.safeParse(state!.testObject); }); Then('validation should fail', () => { @@ -258,8 +258,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { state!.testObject = { preset: 'libar-generic', foobar: 'baz' }; }); - When('validating against DeliveryProcessProjectConfigSchema', () => { - state!.validationResult = DeliveryProcessProjectConfigSchema.safeParse(state!.testObject); + When('validating against ArchitectProjectConfigSchema', () => { + state!.validationResult = ArchitectProjectConfigSchema.safeParse(state!.testObject); }); Then('validation should fail', () => { diff --git a/tests/steps/config/preset-system.steps.ts b/tests/steps/config/preset-system.steps.ts index e019562f..6c761993 100644 --- a/tests/steps/config/preset-system.steps.ts +++ b/tests/steps/config/preset-system.steps.ts @@ -4,7 +4,7 @@ * BDD step definitions for testing the preset system including * GENERIC_PRESET, DDD_ES_CQRS_PRESET, and PRESETS lookup. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -16,15 +16,15 @@ import { PRESETS, type PresetName, } from '../../../src/config/presets.js'; -import type { DeliveryProcessConfig } from '../../../src/config/types.js'; +import type { ArchitectConfig } from '../../../src/config/types.js'; // ============================================================================= // Type Definitions // ============================================================================= interface PresetTestState { - preset: DeliveryProcessConfig | null; - presetFromMap: DeliveryProcessConfig | null; + preset: ArchitectConfig | null; + presetFromMap: ArchitectConfig | null; } // ============================================================================= @@ -131,12 +131,12 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { state.preset = LIBAR_GENERIC_PRESET; }); - Then('it should have tagPrefix "@libar-docs-"', () => { - expect(state!.preset!.tagPrefix).toBe('@libar-docs-'); + Then('it should have tagPrefix "@architect-"', () => { + expect(state!.preset!.tagPrefix).toBe('@architect-'); }); - And('it should have fileOptInTag "@libar-docs"', () => { - expect(state!.preset!.fileOptInTag).toBe('@libar-docs'); + And('it should have fileOptInTag "@architect"', () => { + expect(state!.preset!.fileOptInTag).toBe('@architect'); }); } ); @@ -199,12 +199,12 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { state.preset = DDD_ES_CQRS_PRESET; }); - Then('it should have tagPrefix "@libar-docs-"', () => { - expect(state!.preset!.tagPrefix).toBe('@libar-docs-'); + Then('it should have tagPrefix "@architect-"', () => { + expect(state!.preset!.tagPrefix).toBe('@architect-'); }); - And('it should have fileOptInTag "@libar-docs"', () => { - expect(state!.preset!.fileOptInTag).toBe('@libar-docs'); + And('it should have fileOptInTag "@architect"', () => { + expect(state!.preset!.fileOptInTag).toBe('@architect'); }); }); @@ -326,8 +326,8 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { state.presetFromMap = PRESETS['ddd-es-cqrs' as PresetName]; }); - Then('the preset tagPrefix should be "@libar-docs-"', () => { - expect(state!.presetFromMap!.tagPrefix).toBe('@libar-docs-'); + Then('the preset tagPrefix should be "@architect-"', () => { + expect(state!.presetFromMap!.tagPrefix).toBe('@architect-'); }); }); @@ -337,8 +337,8 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { state.presetFromMap = PRESETS['libar-generic' as PresetName]; }); - Then('the preset tagPrefix should be "@libar-docs-"', () => { - expect(state!.presetFromMap!.tagPrefix).toBe('@libar-docs-'); + Then('the preset tagPrefix should be "@architect-"', () => { + expect(state!.presetFromMap!.tagPrefix).toBe('@architect-'); }); }); }); diff --git a/tests/steps/config/project-config-loader.steps.ts b/tests/steps/config/project-config-loader.steps.ts index cf2866b9..a4571939 100644 --- a/tests/steps/config/project-config-loader.steps.ts +++ b/tests/steps/config/project-config-loader.steps.ts @@ -3,9 +3,9 @@ * * BDD step definitions for testing loadProjectConfig, the unified * config loader that supports both new-style defineConfig and legacy - * createDeliveryProcess config formats. + * createArchitect config formats. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -41,8 +41,8 @@ export default { const LEGACY_CONFIG = ` export default { registry: { - tagPrefix: "@libar-docs-", - fileOptInTag: "@libar-docs", + tagPrefix: "@architect-", + fileOptInTag: "@architect", categories: [ { tag: "core", label: "Core" }, { tag: "api", label: "API" }, @@ -52,9 +52,9 @@ export default { tags: [] }, regexBuilders: { - category: () => /@libar-docs-(core|api|infra)/, - status: () => /@libar-docs-status:(roadmap|active|completed|deferred)/, - pattern: () => /@libar-docs-pattern:([A-Za-z0-9]+)/ + category: () => /@architect-(core|api|infra)/, + status: () => /@architect-status:(roadmap|active|completed|deferred)/, + pattern: () => /@architect-pattern:([A-Za-z0-9]+)/ } }; `.trim(); @@ -148,7 +148,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { Given( 'a new-style config file with preset "libar-generic" and typescript sources', async () => { - const configPath = path.join(state!.tempDir!, 'delivery-process.config.js'); + const configPath = path.join(state!.tempDir!, 'architect.config.js'); await fs.writeFile(configPath, NEW_STYLE_CONFIG); } ); @@ -179,28 +179,25 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { // =========================================================================== Rule('Legacy config is loaded with backward compatibility', ({ RuleScenario }) => { - RuleScenario( - 'Legacy createDeliveryProcess export loads correctly', - ({ Given, When, Then, And }) => { - Given('a legacy config file with registry and regexBuilders', async () => { - const configPath = path.join(state!.tempDir!, 'delivery-process.config.js'); - await fs.writeFile(configPath, LEGACY_CONFIG); - }); + RuleScenario('Legacy createArchitect export loads correctly', ({ Given, When, Then, And }) => { + Given('a legacy config file with registry and regexBuilders', async () => { + const configPath = path.join(state!.tempDir!, 'architect.config.js'); + await fs.writeFile(configPath, LEGACY_CONFIG); + }); - When('loading project config from temp directory', async () => { - state!.loadResult = await loadProjectConfig(state!.tempDir!); - }); + When('loading project config from temp directory', async () => { + state!.loadResult = await loadProjectConfig(state!.tempDir!); + }); - Then('project config loading should succeed', () => { - expect(state!.loadResult!.ok).toBe(true); - }); + Then('project config loading should succeed', () => { + expect(state!.loadResult!.ok).toBe(true); + }); - And('project config isDefault should be false', () => { - if (!state!.loadResult!.ok) throw new Error('Expected success'); - expect(state!.loadResult!.value.isDefault).toBe(false); - }); - } - ); + And('project config isDefault should be false', () => { + if (!state!.loadResult!.ok) throw new Error('Expected success'); + expect(state!.loadResult!.value.isDefault).toBe(false); + }); + }); }); // =========================================================================== @@ -210,7 +207,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { Rule('Invalid configs produce clear errors', ({ RuleScenario }) => { RuleScenario('Config without default export returns error', ({ Given, When, Then, And }) => { Given('a config file without a default export', async () => { - const configPath = path.join(state!.tempDir!, 'delivery-process.config.js'); + const configPath = path.join(state!.tempDir!, 'architect.config.js'); await fs.writeFile(configPath, NO_DEFAULT_EXPORT_CONFIG); }); @@ -232,7 +229,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { 'Config with invalid project config returns Zod error', ({ Given, When, Then, And }) => { Given('a config file with invalid project config data', async () => { - const configPath = path.join(state!.tempDir!, 'delivery-process.config.js'); + const configPath = path.join(state!.tempDir!, 'architect.config.js'); await fs.writeFile(configPath, INVALID_PROJECT_CONFIG); }); diff --git a/tests/steps/config/source-merging.steps.ts b/tests/steps/config/source-merging.steps.ts index 546c103b..c6d2a2f7 100644 --- a/tests/steps/config/source-merging.steps.ts +++ b/tests/steps/config/source-merging.steps.ts @@ -4,7 +4,7 @@ * BDD step definitions for testing mergeSourcesForGenerator, * verifying override semantics for features, typescript sources, and exclude. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/doc-generation/content-deduplication.steps.ts b/tests/steps/doc-generation/content-deduplication.steps.ts index 87ad34a8..f3966897 100644 --- a/tests/steps/doc-generation/content-deduplication.steps.ts +++ b/tests/steps/doc-generation/content-deduplication.steps.ts @@ -7,7 +7,7 @@ * - Section ordering preservation * - Integration with source mapper pipeline * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/doc-generation/decision-doc-codec.steps.ts b/tests/steps/doc-generation/decision-doc-codec.steps.ts index 86795b59..7200a5c1 100644 --- a/tests/steps/doc-generation/decision-doc-codec.steps.ts +++ b/tests/steps/doc-generation/decision-doc-codec.steps.ts @@ -154,7 +154,7 @@ describeFeature(feature, ({ Background, Rule }) => { state.textContent = `Some explanation... """bash -npm install @libar-dev/delivery-process +npm install @libar-dev/architect """ More text here.`; diff --git a/tests/steps/doc-generation/decision-doc-generator.steps.ts b/tests/steps/doc-generation/decision-doc-generator.steps.ts index 821172de..0c68a1b1 100644 --- a/tests/steps/doc-generation/decision-doc-generator.steps.ts +++ b/tests/steps/doc-generation/decision-doc-generator.steps.ts @@ -676,8 +676,8 @@ describeFeature(feature, ({ Background, Rule }) => { createTestTypeScriptFile( 'src/types.ts', `/** - * @libar-docs - * @libar-docs-extract-shapes TestType + * @architect + * @architect-extract-shapes TestType */ export interface TestType { id: string; diff --git a/tests/steps/doc-generation/poc-integration.steps.ts b/tests/steps/doc-generation/poc-integration.steps.ts index d44def45..17f6900e 100644 --- a/tests/steps/doc-generation/poc-integration.steps.ts +++ b/tests/steps/doc-generation/poc-integration.steps.ts @@ -68,7 +68,7 @@ let state: TestState; function resetState(): void { state = { baseDir: process.cwd(), - pocPath: 'delivery-process/specs/doc-generation-proof-of-concept.feature', + pocPath: 'architect/specs/doc-generation-proof-of-concept.feature', pocContent: null, parsedFeature: null, decisionContent: null, diff --git a/tests/steps/doc-generation/robustness-integration.steps.ts b/tests/steps/doc-generation/robustness-integration.steps.ts index fb0c9fc4..5f6426d6 100644 --- a/tests/steps/doc-generation/robustness-integration.steps.ts +++ b/tests/steps/doc-generation/robustness-integration.steps.ts @@ -5,7 +5,7 @@ * generation pipeline. Tests verify that validation, deduplication, and warning * collection work together correctly. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -205,8 +205,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { createTypeScriptFile( 'src/types.ts', `/** - * @libar-docs - * @libar-docs-extract-shapes TestType + * @architect + * @architect-extract-shapes TestType */ export interface TestType { id: string; @@ -373,7 +373,7 @@ export interface TestType { createTypeScriptFile( 'src/types.ts', `/** - * @libar-docs + * @architect * * ## Protection Levels * @@ -533,7 +533,7 @@ export const LEVELS = {}; createTypeScriptFile( 'src/types.ts', `/** - * @libar-docs + * @architect */ export const EMPTY = {}; ` @@ -589,8 +589,8 @@ export const EMPTY = {}; createTypeScriptFile( 'src/types.ts', `/** - * @libar-docs - * @libar-docs-extract-shapes TestType + * @architect + * @architect-extract-shapes TestType */ export interface TestType { id: string; @@ -646,8 +646,8 @@ export interface TestType { createTypeScriptFile( newFileName, `/** - * @libar-docs - * @libar-docs-extract-shapes TestType + * @architect + * @architect-extract-shapes TestType */ export interface TestType { id: string; } ` @@ -725,7 +725,7 @@ export interface TestType { id: string; } // Create a file without the @extract-shapes tag (will cause extraction error) createTypeScriptFile( 'src/types.ts', - `// No @libar-docs-extract-shapes tag + `// No @architect-extract-shapes tag export const x = 1; ` ); diff --git a/tests/steps/doc-generation/source-mapper.steps.ts b/tests/steps/doc-generation/source-mapper.steps.ts index 8b9d1114..8c38f350 100644 --- a/tests/steps/doc-generation/source-mapper.steps.ts +++ b/tests/steps/doc-generation/source-mapper.steps.ts @@ -210,8 +210,8 @@ describeFeature(feature, ({ Background, Rule }) => { createTestTypeScriptFile( 'src/test-types.ts', `/** - * @libar-docs - * @libar-docs-extract-shapes TestInterface + * @architect + * @architect-extract-shapes TestInterface */ export interface TestInterface { @@ -441,8 +441,8 @@ export interface TestInterface { createTestTypeScriptFile( 'src/test-types.ts', `/** - * @libar-docs - * @libar-docs-extract-shapes MyInterface + * @architect + * @architect-extract-shapes MyInterface */ export interface MyInterface { id: string; } ` @@ -505,8 +505,8 @@ export interface MyInterface { id: string; } createTestTypeScriptFile( 'src/test-types.ts', `/** - * @libar-docs - * @libar-docs-extract-shapes Type + * @architect + * @architect-extract-shapes Type */ export type Type = string; ` diff --git a/tests/steps/doc-generation/source-mapping-validator.steps.ts b/tests/steps/doc-generation/source-mapping-validator.steps.ts index 4b7dda85..5ae7e249 100644 --- a/tests/steps/doc-generation/source-mapping-validator.steps.ts +++ b/tests/steps/doc-generation/source-mapping-validator.steps.ts @@ -8,7 +8,7 @@ * - Table format validation * - Validation result aggregation * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/doc-generation/warning-collector.steps.ts b/tests/steps/doc-generation/warning-collector.steps.ts index ce33e8ce..179c87cc 100644 --- a/tests/steps/doc-generation/warning-collector.steps.ts +++ b/tests/steps/doc-generation/warning-collector.steps.ts @@ -8,7 +8,7 @@ * - Result integration * - Output formatting * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/extractor/declaration-level-shape-tagging.steps.ts b/tests/steps/extractor/declaration-level-shape-tagging.steps.ts index 7a02ea12..22759ec8 100644 --- a/tests/steps/extractor/declaration-level-shape-tagging.steps.ts +++ b/tests/steps/extractor/declaration-level-shape-tagging.steps.ts @@ -2,7 +2,7 @@ * Step definitions for Declaration-Level Shape Tagging tests * * Tests the discoverTaggedShapes function that scans TypeScript source - * code for declarations annotated with the @libar-docs-shape JSDoc tag. + * code for declarations annotated with the @architect-shape JSDoc tag. */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/extractor/shape-extraction-rendering.steps.ts b/tests/steps/extractor/shape-extraction-rendering.steps.ts index ec7b1e96..8e4cd22c 100644 --- a/tests/steps/extractor/shape-extraction-rendering.steps.ts +++ b/tests/steps/extractor/shape-extraction-rendering.steps.ts @@ -294,9 +294,9 @@ describeFeature(feature, ({ Background, Rule }) => { expect(shape!.jsDoc).toContain('@returns'); }); - And('the shape "MixedTags" jsDoc should not contain "@libar-docs"', () => { + And('the shape "MixedTags" jsDoc should not contain "@architect"', () => { const shape = state.extractionResult!.shapes.find((s) => s.name === 'MixedTags'); - expect(shape!.jsDoc).not.toContain('@libar-docs'); + expect(shape!.jsDoc).not.toContain('@architect'); }); } ); diff --git a/tests/steps/generation/design-review-generator.steps.ts b/tests/steps/generation/design-review-generator.steps.ts index 10d36936..3fda0a68 100644 --- a/tests/steps/generation/design-review-generator.steps.ts +++ b/tests/steps/generation/design-review-generator.steps.ts @@ -3,8 +3,8 @@ * * Covers orphan cleanup for stale design-review markdown files. * - * @libar-docs - * @libar-docs-uses DesignReviewGenerator + * @architect + * @architect-uses DesignReviewGenerator */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -75,7 +75,7 @@ describeFeature(feature, ({ Background, AfterEachScenario, Rule }) => { const pattern = createTestPattern({ name: patternName, status: 'active', - filePath: 'delivery-process/specs/test-pattern.feature', + filePath: 'architect/specs/test-pattern.feature', sequenceOrchestrator: 'orch', rules: [ createSequenceRule({ diff --git a/tests/steps/generation/design-review.steps.ts b/tests/steps/generation/design-review.steps.ts index 32f147cf..0dce0ae5 100644 --- a/tests/steps/generation/design-review.steps.ts +++ b/tests/steps/generation/design-review.steps.ts @@ -14,8 +14,8 @@ * - Case-insensitive process-api sequence lookup * - Mermaid-safe escaping across rendered label positions * - * @libar-docs - * @libar-docs-uses DesignReviewCodec, SequenceIndex, renderToMarkdown + * @architect + * @architect-uses DesignReviewCodec, SequenceIndex, renderToMarkdown */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/generation/load-preamble.steps.ts b/tests/steps/generation/load-preamble.steps.ts index 0bf73e43..bf289f97 100644 --- a/tests/steps/generation/load-preamble.steps.ts +++ b/tests/steps/generation/load-preamble.steps.ts @@ -16,7 +16,7 @@ * using DocStrings because DocStrings containing code fences (```) * are mishandled by vitest-cucumber. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/generators/prd-implementation-section.steps.ts b/tests/steps/generators/prd-implementation-section.steps.ts index 292c0886..b00d8b0e 100644 --- a/tests/steps/generators/prd-implementation-section.steps.ts +++ b/tests/steps/generators/prd-implementation-section.steps.ts @@ -2,7 +2,7 @@ * PRD Implementation Section Step Definitions * * BDD step definitions for testing the Implementations section in pattern documents. - * Tests that code stubs with @libar-docs-implements tags appear in pattern docs + * Tests that code stubs with @architect-implements tags appear in pattern docs * with working links to source files. * * Uses Rule() + RuleScenario() pattern as feature file uses Rule: blocks. @@ -182,7 +182,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { // =========================================================================== Rule( - 'Implementation files appear in pattern docs via @libar-docs-implements', + 'Implementation files appear in pattern docs via @architect-implements', ({ RuleScenario }) => { RuleScenario( 'Implementations section renders with file links', diff --git a/tests/steps/generators/table-extraction.steps.ts b/tests/steps/generators/table-extraction.steps.ts index 4fbede46..a0f15949 100644 --- a/tests/steps/generators/table-extraction.steps.ts +++ b/tests/steps/generators/table-extraction.steps.ts @@ -5,7 +5,7 @@ * Tests that tables in business rule descriptions appear exactly once in output * and that stripMarkdownTables correctly removes table syntax from text. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/lint/lint-engine.steps.ts b/tests/steps/lint/lint-engine.steps.ts index 28db152d..20b6e8c6 100644 --- a/tests/steps/lint/lint-engine.steps.ts +++ b/tests/steps/lint/lint-engine.steps.ts @@ -76,7 +76,7 @@ let state: LintEngineScenarioState | null = null; */ function createTestDirective(overrides: Partial = {}): DocDirective { return { - tags: [asDirectiveTag('@libar-docs-test')], + tags: [asDirectiveTag('@architect-test')], description: '', examples: [], position: { startLine: 1, endLine: 10 }, diff --git a/tests/steps/mcp/mcp-server.steps.ts b/tests/steps/mcp/mcp-server.steps.ts index eea39f83..41cb3cb5 100644 --- a/tests/steps/mcp/mcp-server.steps.ts +++ b/tests/steps/mcp/mcp-server.steps.ts @@ -5,8 +5,8 @@ * Tests the MCP-specific layer: tool registration, pipeline session * lifecycle, file watcher filtering, CLI parsing, and output formatting. * - * @libar-docs - * @libar-docs-uses MCPServerImpl, MCPPipelineSession, MCPToolRegistry, MCPFileWatcher + * @architect + * @architect-uses MCPServerImpl, MCPPipelineSession, MCPToolRegistry, MCPFileWatcher */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -71,7 +71,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { const manager = new PipelineSessionManager(); session = await manager.initialize({ input: ['src/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + features: ['architect/specs/*.feature'], }); state!.session = session; }); @@ -120,7 +120,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { manager = new PipelineSessionManager(); originalSession = await manager.initialize({ input: ['src/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + features: ['architect/specs/*.feature'], }); }); @@ -155,7 +155,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { manager = new PipelineSessionManager(); originalSession = await manager.initialize({ input: ['src/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + features: ['architect/specs/*.feature'], }); }); @@ -194,7 +194,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { manager = new PipelineSessionManager(); originalSession = await manager.initialize({ input: ['src/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + features: ['architect/specs/*.feature'], }); }); @@ -234,30 +234,30 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { async () => { state!.tempDir = await fs.mkdtemp(path.join(os.tmpdir(), 'mcp-config-fallback-test-')); await fs.mkdir(path.join(state!.tempDir, 'src'), { recursive: true }); - await fs.mkdir(path.join(state!.tempDir, 'delivery-process', 'specs'), { + await fs.mkdir(path.join(state!.tempDir, 'architect', 'specs'), { recursive: true, }); await fs.writeFile( - path.join(state!.tempDir, 'delivery-process.config.js'), + path.join(state!.tempDir, 'architect.config.js'), "export default { preset: 'libar-generic' };\n" ); await fs.writeFile( path.join(state!.tempDir, 'src', 'example.ts'), [ '/**', - ' * @libar-docs', - ' * @libar-docs-pattern ExamplePattern', - ' * @libar-docs-status roadmap', + ' * @architect', + ' * @architect-pattern ExamplePattern', + ' * @architect-status roadmap', ' */', 'export const example = 1;', '', ].join('\n') ); await fs.writeFile( - path.join(state!.tempDir, 'delivery-process', 'specs', 'example.feature'), + path.join(state!.tempDir, 'architect', 'specs', 'example.feature'), [ - '@libar-docs', + '@architect', 'Feature: Example pattern metadata', '', ' Scenario: Placeholder', @@ -280,7 +280,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { And('the session source globs include conventional TypeScript and feature paths', () => { expect(session!.sourceGlobs.input).toContain('src/**/*.ts'); - expect(session!.sourceGlobs.features).toContain('delivery-process/specs/*.feature'); + expect(session!.sourceGlobs.features).toContain('architect/specs/*.feature'); }); } ); @@ -293,7 +293,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { manager = new PipelineSessionManager(); await manager.initialize({ input: ['src/**/*.ts'], - features: ['delivery-process/specs/*.feature'], + features: ['architect/specs/*.feature'], }); }); @@ -336,7 +336,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { state!.session = session; } - RuleScenario('All tools registered with dp_ prefix', ({ Given, Then, And }) => { + RuleScenario('All tools registered with architect_ prefix', ({ Given, Then, And }) => { Given('an McpServer mock with registered tools', () => { setupMockServer(); }); @@ -365,13 +365,13 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }); }); - RuleScenario('dp_overview returns formatted text', ({ Given, When, Then, And }) => { + RuleScenario('architect_overview returns formatted text', ({ Given, When, Then, And }) => { Given('an McpServer mock with registered tools', () => { setupMockServer(); }); - When('the dp_overview handler is called', () => { - const tool = state!.mockServer!.tools.get('dp_overview'); + When('the architect_overview handler is called', () => { + const tool = state!.mockServer!.tools.get('architect_overview'); expect(tool).toBeDefined(); state!.toolResult = tool!.handler({}) as McpTestState['toolResult']; }); @@ -388,27 +388,33 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }); }); - RuleScenario('dp_pattern returns error for unknown pattern', ({ Given, When, Then, And }) => { - Given('an McpServer mock with registered tools', () => { - setupMockServer(); - }); + RuleScenario( + 'architect_pattern returns error for unknown pattern', + ({ Given, When, Then, And }) => { + Given('an McpServer mock with registered tools', () => { + setupMockServer(); + }); - When('the dp_pattern handler is called with name {string}', (_ctx: unknown, name: string) => { - const tool = state!.mockServer!.tools.get('dp_pattern'); - expect(tool).toBeDefined(); - state!.toolResult = tool!.handler({ name }) as McpTestState['toolResult']; - }); + When( + 'the architect_pattern handler is called with name {string}', + (_ctx: unknown, name: string) => { + const tool = state!.mockServer!.tools.get('architect_pattern'); + expect(tool).toBeDefined(); + state!.toolResult = tool!.handler({ name }) as McpTestState['toolResult']; + } + ); - Then('the result is an error', () => { - expect(state!.toolResult!.isError).toBe(true); - }); + Then('the result is an error', () => { + expect(state!.toolResult!.isError).toBe(true); + }); - And('the error message contains {string}', (_ctx: unknown, expected: string) => { - expect(state!.toolResult!.content[0].text).toContain(expected); - }); - }); + And('the error message contains {string}', (_ctx: unknown, expected: string) => { + expect(state!.toolResult!.content[0].text).toContain(expected); + }); + } + ); - RuleScenario('dp_list filters apply cumulatively', ({ Given, When, Then, And }) => { + RuleScenario('architect_list filters apply cumulatively', ({ Given, When, Then, And }) => { Given('a session with patterns of mixed status and phase', () => { state!.session = createFilterTestSession(); }); @@ -424,9 +430,9 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }); When( - 'dp_list is called with status {string} and phase {int}', + 'architect_list is called with status {string} and phase {int}', (_ctx: unknown, status: string, phase: number) => { - const tool = state!.mockServer!.tools.get('dp_list'); + const tool = state!.mockServer!.tools.get('architect_list'); expect(tool).toBeDefined(); state!.toolResult = tool!.handler({ status, phase }) as McpTestState['toolResult']; } @@ -539,7 +545,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }); Then('the version text matches the package version', () => { - expect(versionText).toBe(`dp-mcp-server v${getPackageVersion()}`); + expect(versionText).toBe(`architect-mcp v${getPackageVersion()}`); }); }); }); @@ -566,8 +572,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { setupMockServer(); }); - When('the dp_overview handler is called', () => { - const tool = state!.mockServer!.tools.get('dp_overview'); + When('the architect_overview handler is called', () => { + const tool = state!.mockServer!.tools.get('architect_overview'); state!.toolResult = tool!.handler({}) as McpTestState['toolResult']; }); @@ -581,8 +587,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { setupMockServer(); }); - When('the dp_status handler is called', () => { - const tool = state!.mockServer!.tools.get('dp_status'); + When('the architect_status handler is called', () => { + const tool = state!.mockServer!.tools.get('architect_status'); state!.toolResult = tool!.handler({}) as McpTestState['toolResult']; }); @@ -594,13 +600,13 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { }); }); - RuleScenario('dp_status returns JSON with counts', ({ Given, When, Then, And }) => { + RuleScenario('architect_status returns JSON with counts', ({ Given, When, Then, And }) => { Given('an McpServer mock with registered tools', () => { setupMockServer(); }); - When('the dp_status handler is called', () => { - const tool = state!.mockServer!.tools.get('dp_status'); + When('the architect_status handler is called', () => { + const tool = state!.mockServer!.tools.get('architect_status'); state!.toolResult = tool!.handler({}) as McpTestState['toolResult']; }); @@ -622,7 +628,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { Rule('Tool output correctness for edge cases', ({ RuleScenario }) => { RuleScenario( - 'dp_rules without pattern returns compact summary', + 'architect_rules without pattern returns compact summary', ({ Given, When, Then, And }) => { Given('an McpServer mock with registered tools', () => { const session = createTestPipelineSession(); @@ -636,8 +642,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { state!.session = session; }); - When('the dp_rules handler is called without pattern', () => { - const tool = state!.mockServer!.tools.get('dp_rules'); + When('the architect_rules handler is called without pattern', () => { + const tool = state!.mockServer!.tools.get('architect_rules'); expect(tool).toBeDefined(); state!.toolResult = tool!.handler({}) as McpTestState['toolResult']; }); @@ -667,7 +673,7 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { ); RuleScenario( - 'dp_pattern returns full metadata including business rules and extracted shapes', + 'architect_pattern returns full metadata including business rules and extracted shapes', ({ Given, When, Then, And }) => { Given('a session with a pattern that has deliverables and dependencies', () => { state!.session = createRichPatternSession(); @@ -683,8 +689,8 @@ describeFeature(feature, ({ Background, Rule, AfterEachScenario }) => { state!.mockServer = mockServer; }); - When('dp_pattern is called for that pattern', () => { - const tool = state!.mockServer!.tools.get('dp_pattern'); + When('architect_pattern is called for that pattern', () => { + const tool = state!.mockServer!.tools.get('architect_pattern'); expect(tool).toBeDefined(); state!.toolResult = tool!.handler({ name: 'RichPattern' }) as McpTestState['toolResult']; }); diff --git a/tests/steps/scanner/ast-parser-exports.steps.ts b/tests/steps/scanner/ast-parser-exports.steps.ts index b3a257c8..e0409dbc 100644 --- a/tests/steps/scanner/ast-parser-exports.steps.ts +++ b/tests/steps/scanner/ast-parser-exports.steps.ts @@ -5,7 +5,7 @@ * that the parseFileDirectives function correctly identifies all TypeScript * export declaration types. * - * @libar-docs + * @architect */ import { diff --git a/tests/steps/scanner/ast-parser-metadata.steps.ts b/tests/steps/scanner/ast-parser-metadata.steps.ts index 69a01950..f3f17027 100644 --- a/tests/steps/scanner/ast-parser-metadata.steps.ts +++ b/tests/steps/scanner/ast-parser-metadata.steps.ts @@ -5,7 +5,7 @@ * that the parseFileDirectives function correctly extracts metadata, tags, * and When to Use sections from JSDoc comments. * - * @libar-docs + * @architect */ import { diff --git a/tests/steps/scanner/ast-parser-relationships-edges.steps.ts b/tests/steps/scanner/ast-parser-relationships-edges.steps.ts index bf5778e6..4f20e847 100644 --- a/tests/steps/scanner/ast-parser-relationships-edges.steps.ts +++ b/tests/steps/scanner/ast-parser-relationships-edges.steps.ts @@ -5,7 +5,7 @@ * These tests verify that uses/usedBy relationships are extracted correctly * and that malformed/empty input is handled gracefully. * - * @libar-docs + * @architect */ import { @@ -61,7 +61,7 @@ describeFeature(feature, ({ Rule, Background, AfterEachScenario }) => { // --------------------------------------------------------------------------- Rule('Relationship tags extract uses and usedBy dependencies', ({ RuleScenario }) => { - RuleScenario('Extract @libar-docs-uses with single value', ({ Given, When, Then, And }) => { + RuleScenario('Extract @architect-uses with single value', ({ Given, When, Then, And }) => { Given('a TypeScript file with content:', givenTypeScriptFileWithContent); When('the file is parsed for directives', whenFileIsParsed); Then('{int} directive should be found', thenDirectiveCountShouldBe); @@ -69,7 +69,7 @@ describeFeature(feature, ({ Rule, Background, AfterEachScenario }) => { }); RuleScenario( - 'Extract @libar-docs-uses with comma-separated values', + 'Extract @architect-uses with comma-separated values', ({ Given, When, Then, And }) => { Given('a TypeScript file with content:', givenTypeScriptFileWithContent); When('the file is parsed for directives', whenFileIsParsed); @@ -79,7 +79,7 @@ describeFeature(feature, ({ Rule, Background, AfterEachScenario }) => { } ); - RuleScenario('Extract @libar-docs-used-by with single value', ({ Given, When, Then, And }) => { + RuleScenario('Extract @architect-used-by with single value', ({ Given, When, Then, And }) => { Given('a TypeScript file with content:', givenTypeScriptFileWithContent); When('the file is parsed for directives', whenFileIsParsed); Then('{int} directive should be found', thenDirectiveCountShouldBe); @@ -87,7 +87,7 @@ describeFeature(feature, ({ Rule, Background, AfterEachScenario }) => { }); RuleScenario( - 'Extract @libar-docs-used-by with comma-separated values', + 'Extract @architect-used-by with comma-separated values', ({ Given, When, Then, And }) => { Given('a TypeScript file with content:', givenTypeScriptFileWithContent); When('the file is parsed for directives', whenFileIsParsed); @@ -138,7 +138,7 @@ describeFeature(feature, ({ Rule, Background, AfterEachScenario }) => { // --------------------------------------------------------------------------- Rule('Edge cases and malformed input are handled gracefully', ({ RuleScenario }) => { - RuleScenario('Skip comments without @libar-docs-* tags', ({ Given, When, Then }) => { + RuleScenario('Skip comments without @architect-* tags', ({ Given, When, Then }) => { Given('a TypeScript file with content:', givenTypeScriptFileWithContent); When('the file is parsed for directives', whenFileIsParsed); Then('{int} directives should be found', thenDirectiveCountShouldBe); diff --git a/tests/steps/scanner/docstring-mediatype.steps.ts b/tests/steps/scanner/docstring-mediatype.steps.ts index dcdd3d05..6c060f89 100644 --- a/tests/steps/scanner/docstring-mediatype.steps.ts +++ b/tests/steps/scanner/docstring-mediatype.steps.ts @@ -4,7 +4,7 @@ * BDD step definitions for testing DocString mediaType (language hint) preservation * through the parsing pipeline from feature files to rendered output. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; import { expect } from 'vitest'; diff --git a/tests/steps/scanner/file-discovery.steps.ts b/tests/steps/scanner/file-discovery.steps.ts index 198e2d4a..c278bf2e 100644 --- a/tests/steps/scanner/file-discovery.steps.ts +++ b/tests/steps/scanner/file-discovery.steps.ts @@ -5,7 +5,7 @@ * Tests file discovery with glob patterns, default exclusions, * and custom exclude patterns. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/scanner/gherkin-parser.steps.ts b/tests/steps/scanner/gherkin-parser.steps.ts index 8a0ef4e6..8e65f249 100644 --- a/tests/steps/scanner/gherkin-parser.steps.ts +++ b/tests/steps/scanner/gherkin-parser.steps.ts @@ -5,7 +5,7 @@ * Tests parseFeatureFile function for extracting feature metadata, * scenarios, and steps from .feature files. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/types/normalized-status.steps.ts b/tests/steps/types/normalized-status.steps.ts index 83448a19..9ac45319 100644 --- a/tests/steps/types/normalized-status.steps.ts +++ b/tests/steps/types/normalized-status.steps.ts @@ -1,7 +1,7 @@ /** - * @libar-docs - * @libar-docs-implements NormalizedStatusTesting - * @libar-docs-uses NormalizedStatus + * @architect + * @architect-implements NormalizedStatusTesting + * @architect-uses NormalizedStatus * * Normalized Status Step Definitions * diff --git a/tests/steps/types/tag-registry-builder.steps.ts b/tests/steps/types/tag-registry-builder.steps.ts index 697d9b33..8e121ae5 100644 --- a/tests/steps/types/tag-registry-builder.steps.ts +++ b/tests/steps/types/tag-registry-builder.steps.ts @@ -1,7 +1,7 @@ /** - * @libar-docs - * @libar-docs-implements TagRegistryBuilderTesting - * @libar-docs-uses RegistryBuilder, TagRegistry + * @architect + * @architect-implements TagRegistryBuilderTesting + * @architect-uses RegistryBuilder, TagRegistry * * Tag Registry Builder Step Definitions * diff --git a/tests/steps/utils/git-branch-diff.steps.ts b/tests/steps/utils/git-branch-diff.steps.ts index 298e5aae..9d03ce2d 100644 --- a/tests/steps/utils/git-branch-diff.steps.ts +++ b/tests/steps/utils/git-branch-diff.steps.ts @@ -1,7 +1,7 @@ /** - * @libar-docs - * @libar-docs-implements GitBranchDiffTesting - * @libar-docs-uses GitBranchDiff, GitHelpers + * @architect + * @architect-implements GitBranchDiffTesting + * @architect-uses GitBranchDiff, GitHelpers * * Git Branch Diff Step Definitions * diff --git a/tests/steps/validation/anti-patterns.steps.ts b/tests/steps/validation/anti-patterns.steps.ts index 5e782de0..745e0f8c 100644 --- a/tests/steps/validation/anti-patterns.steps.ts +++ b/tests/steps/validation/anti-patterns.steps.ts @@ -4,7 +4,7 @@ * BDD step definitions for testing anti-pattern detection functions * that enforce dual-source documentation architecture. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -98,7 +98,7 @@ function createMockScannedFile(tags: string[]): ScannedFile { directives: [ { directive: { - tags: tags as ReadonlyArray<`@libar-docs-${string}`>, + tags: tags as ReadonlyArray<`@architect-${string}`>, description: 'Test directive', examples: [], position: { startLine: 1, endLine: 10 }, @@ -207,7 +207,7 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { ({ Given, When, Then, And }, variables: { process_tag: string }) => { Given('a TypeScript file with process tag {string}', () => { state = initState(); - state.scannedFiles = [createMockScannedFile(['@libar-docs', variables.process_tag])]; + state.scannedFiles = [createMockScannedFile(['@architect', variables.process_tag])]; }); When('detecting process-in-code anti-patterns', () => { diff --git a/tests/steps/validation/codec-utils.steps.ts b/tests/steps/validation/codec-utils.steps.ts index de03dae9..51d7115e 100644 --- a/tests/steps/validation/codec-utils.steps.ts +++ b/tests/steps/validation/codec-utils.steps.ts @@ -1,7 +1,7 @@ /** - * @libar-docs - * @libar-docs-implements CodecUtilsTesting - * @libar-docs-uses CodecUtils + * @architect + * @architect-implements CodecUtilsTesting + * @architect-uses CodecUtils * * Codec Utils Step Definitions * diff --git a/tests/steps/validation/detect-changes.steps.ts b/tests/steps/validation/detect-changes.steps.ts index 27953f77..460871f2 100644 --- a/tests/steps/validation/detect-changes.steps.ts +++ b/tests/steps/validation/detect-changes.steps.ts @@ -4,7 +4,7 @@ * BDD step definitions for testing the detectDeliverableChanges function * that parses git diff output to identify added, removed, and modified deliverables. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/validation/fsm-validator.steps.ts b/tests/steps/validation/fsm-validator.steps.ts index 9f12e3cb..5fb36a90 100644 --- a/tests/steps/validation/fsm-validator.steps.ts +++ b/tests/steps/validation/fsm-validator.steps.ts @@ -4,7 +4,7 @@ * BDD step definitions for testing the Phase State Machine validation * functions that validate status values and transitions per PDR-005. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -276,9 +276,9 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { expect(state!.completionResult!.valid).toBe(true); }); - And('warnings include "missing @libar-docs-completed date"', () => { + And('warnings include "missing @architect-completed date"', () => { expect( - state!.completionResult!.warnings.some((w) => w.includes('@libar-docs-completed')) + state!.completionResult!.warnings.some((w) => w.includes('@architect-completed')) ).toBe(true); }); }); @@ -307,9 +307,9 @@ describeFeature(feature, ({ Rule, AfterEachScenario }) => { expect(state!.completionResult!.valid).toBe(true); }); - And('warnings include "missing @libar-docs-effort-actual"', () => { + And('warnings include "missing @architect-effort-actual"', () => { expect( - state!.completionResult!.warnings.some((w) => w.includes('@libar-docs-effort-actual')) + state!.completionResult!.warnings.some((w) => w.includes('@architect-effort-actual')) ).toBe(true); }); } diff --git a/tests/steps/validation/process-guard.steps.ts b/tests/steps/validation/process-guard.steps.ts index 4c9abc6e..b6c9e7f3 100644 --- a/tests/steps/validation/process-guard.steps.ts +++ b/tests/steps/validation/process-guard.steps.ts @@ -7,7 +7,7 @@ * Key insight: The decider is a pure function - tests create in-memory * ProcessState and ChangeDetection objects without any git operations. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; diff --git a/tests/steps/validation/status-transition-detection.steps.ts b/tests/steps/validation/status-transition-detection.steps.ts index dc443f38..0b004920 100644 --- a/tests/steps/validation/status-transition-detection.steps.ts +++ b/tests/steps/validation/status-transition-detection.steps.ts @@ -4,7 +4,7 @@ * BDD step definitions for testing the detectStatusTransitions function * that parses git diff output with docstring awareness. * - * @libar-docs + * @architect */ import { loadFeature, describeFeature } from '@amiceli/vitest-cucumber'; @@ -245,7 +245,7 @@ describeFeature(feature, ({ Background, Rule }) => { const file = 'specs/new.feature'; state!.files = [file]; state!.diff = `${createDiffHeader(file)} -+@libar-docs-status:active ++@architect-status:active +Feature: Test`; }); @@ -278,8 +278,8 @@ describeFeature(feature, ({ Background, Rule }) => { const file = 'specs/existing.feature'; state!.files = [file]; state!.diff = `${createModifiedDiffHeader(file)} --@libar-docs-status:roadmap -+@libar-docs-status:active +-@architect-status:roadmap ++@architect-status:active Feature: Test`; } ); @@ -312,8 +312,8 @@ describeFeature(feature, ({ Background, Rule }) => { const file = 'specs/unchanged.feature'; state!.files = [file]; state!.diff = `${createModifiedDiffHeader(file)} --@libar-docs-status:active -+@libar-docs-status:active +-@architect-status:active ++@architect-status:active Feature: Test`; } ); @@ -504,7 +504,7 @@ index 1234567..abcdefg 100644 --- a/${file} +++ b/${file} @@ -0,0 +5,10 @@ -+@libar-docs-status:active ++@architect-status:active +Feature: Test`; } ); @@ -536,7 +536,7 @@ index 1234567..abcdefg 100644 const file = 'docs-generated/patterns.md'; state!.files = [file]; state!.diff = `${createDiffHeader(file)} -+@libar-docs-status:completed`; ++@architect-status:completed`; }); When('detecting status transitions', () => { @@ -554,7 +554,7 @@ index 1234567..abcdefg 100644 const file = 'docs-living/roadmap.md'; state!.files = [file]; state!.diff = `${createDiffHeader(file)} -+@libar-docs-status:active`; ++@architect-status:active`; }); When('detecting status transitions', () => { diff --git a/tests/steps/validation/tag-registry-schemas.steps.ts b/tests/steps/validation/tag-registry-schemas.steps.ts index 9698b0d0..5a377b2f 100644 --- a/tests/steps/validation/tag-registry-schemas.steps.ts +++ b/tests/steps/validation/tag-registry-schemas.steps.ts @@ -1,7 +1,7 @@ /** - * @libar-docs - * @libar-docs-implements TagRegistrySchemasTesting - * @libar-docs-uses TagRegistrySchema + * @architect + * @architect-implements TagRegistrySchemasTesting + * @architect-uses TagRegistrySchema * * Tag Registry Schema Step Definitions * @@ -65,8 +65,8 @@ function createMinimalRegistry(overrides: Partial = {}): TagRegistr metadataTags: overrides.metadataTags ?? [], aggregationTags: overrides.aggregationTags ?? [], formatOptions: overrides.formatOptions ?? ['full', 'list', 'summary'], - tagPrefix: overrides.tagPrefix ?? '@libar-docs-', - fileOptInTag: overrides.fileOptInTag ?? '@libar-docs', + tagPrefix: overrides.tagPrefix ?? '@architect-', + fileOptInTag: overrides.fileOptInTag ?? '@architect', }; } @@ -130,8 +130,8 @@ describeFeature(feature, ({ Rule, Background, AfterEachScenario }) => { state!.registry = createDefaultTagRegistry(); }); - Then('the registry tag prefix should be "@libar-docs-"', () => { - expect(state!.registry!.tagPrefix).toBe('@libar-docs-'); + Then('the registry tag prefix should be "@architect-"', () => { + expect(state!.registry!.tagPrefix).toBe('@architect-'); }); }); } @@ -218,9 +218,9 @@ describeFeature(feature, ({ Rule, Background, AfterEachScenario }) => { }); RuleScenario('Merge replaces scalar fields when provided', ({ Given, When, Then }) => { - Given('a base registry with tag prefix "@libar-docs-"', () => { + Given('a base registry with tag prefix "@architect-"', () => { state!.baseRegistry = createMinimalRegistry({ - tagPrefix: '@libar-docs-', + tagPrefix: '@architect-', }); }); diff --git a/tests/steps/validation/workflow-config-schemas.steps.ts b/tests/steps/validation/workflow-config-schemas.steps.ts index 58be5c0a..92d80782 100644 --- a/tests/steps/validation/workflow-config-schemas.steps.ts +++ b/tests/steps/validation/workflow-config-schemas.steps.ts @@ -1,7 +1,7 @@ /** - * @libar-docs - * @libar-docs-implements WorkflowConfigSchemasTesting - * @libar-docs-uses WorkflowConfigSchema + * @architect + * @architect-implements WorkflowConfigSchemasTesting + * @architect-uses WorkflowConfigSchema * * Workflow Config Schema Step Definitions * diff --git a/tests/support/helpers/assertions.ts b/tests/support/helpers/assertions.ts index b437561b..b4355c9d 100644 --- a/tests/support/helpers/assertions.ts +++ b/tests/support/helpers/assertions.ts @@ -8,7 +8,7 @@ * - Scanner results * - Result monad validation * - * @libar-docs + * @architect */ import { expect } from 'vitest'; diff --git a/tests/support/helpers/ast-parser-state.ts b/tests/support/helpers/ast-parser-state.ts index 1ce77aeb..8477993c 100644 --- a/tests/support/helpers/ast-parser-state.ts +++ b/tests/support/helpers/ast-parser-state.ts @@ -4,7 +4,7 @@ * Shared state management, step handler functions, and imports for the split * ast-parser test files (exports, metadata, relationships-edges). * - * @libar-docs + * @architect */ import { expect } from 'vitest'; diff --git a/tests/support/helpers/cli-runner.ts b/tests/support/helpers/cli-runner.ts index 4690131d..b9dc03a6 100644 --- a/tests/support/helpers/cli-runner.ts +++ b/tests/support/helpers/cli-runner.ts @@ -4,7 +4,7 @@ * Provides utilities for executing CLI commands via subprocess * and capturing their output for assertion in tests. * - * @libar-docs + * @architect */ import { spawn } from 'node:child_process'; diff --git a/tests/support/helpers/design-review-state.ts b/tests/support/helpers/design-review-state.ts index d247360b..aaad2d54 100644 --- a/tests/support/helpers/design-review-state.ts +++ b/tests/support/helpers/design-review-state.ts @@ -4,8 +4,8 @@ * Provides test state management and fixture builders for testing * the SequenceIndex builder and DesignReviewCodec pipeline. * - * @libar-docs - * @libar-docs-uses SequenceIndex, DesignReviewCodec, MasterDataset + * @architect + * @architect-uses SequenceIndex, DesignReviewCodec, MasterDataset */ import type { BusinessRule } from '../../../src/validation-schemas/extracted-pattern.js'; @@ -152,7 +152,7 @@ export function generateDesignReview(state: DesignReviewState): void { const pattern = createTestPattern({ name: state.patternName || 'TestPattern', status: 'active', - filePath: 'delivery-process/specs/test-pattern.feature', + filePath: 'architect/specs/test-pattern.feature', rules: state.rules, sequenceOrchestrator: state.orchestrator, }); @@ -176,7 +176,7 @@ export function transformWithValidation(state: DesignReviewState): void { const pattern = createTestPattern({ name: state.patternName || 'TestPattern', status: 'active', - filePath: 'delivery-process/specs/test-pattern.feature', + filePath: 'architect/specs/test-pattern.feature', rules: state.rules, sequenceOrchestrator: state.orchestrator, }); @@ -202,7 +202,7 @@ export function resolveSequenceEntry( const pattern = createTestPattern({ name: state.patternName || 'TestPattern', status: 'active', - filePath: 'delivery-process/specs/test-pattern.feature', + filePath: 'architect/specs/test-pattern.feature', rules: state.rules, sequenceOrchestrator: state.orchestrator, }); diff --git a/tests/support/helpers/document-assertions.ts b/tests/support/helpers/document-assertions.ts index 43667738..87117d92 100644 --- a/tests/support/helpers/document-assertions.ts +++ b/tests/support/helpers/document-assertions.ts @@ -5,7 +5,7 @@ * universal renderer. These helpers enable expressive BDD-style * assertions on document structure and content. * - * @libar-docs + * @architect */ import { expect } from 'vitest'; diff --git a/tests/support/helpers/file-system.ts b/tests/support/helpers/file-system.ts index c961712d..b612a85b 100644 --- a/tests/support/helpers/file-system.ts +++ b/tests/support/helpers/file-system.ts @@ -4,7 +4,7 @@ * Provides utilities for managing temporary directories and files * during scanner and CLI tests. Ensures proper cleanup after each scenario. * - * @libar-docs + * @architect */ import * as fs from 'node:fs/promises'; @@ -150,7 +150,7 @@ export async function listFiles(dir: string): Promise { // ============================================================================= /** - * Create TypeScript source file content with @libar-docs directive. + * Create TypeScript source file content with @architect directive. * * @example * ```typescript @@ -192,42 +192,42 @@ export function createTsFileWithDirective(options: { // File-level opt-in if (includeFileOptIn) { - lines.push('/** @libar-docs */'); + lines.push('/** @architect */'); lines.push(''); } // Pattern directive lines.push('/**'); - lines.push(` * @libar-docs-${category}`); + lines.push(` * @architect-${category}`); if (patternName) { - lines.push(` * @libar-docs-pattern ${patternName}`); + lines.push(` * @architect-pattern ${patternName}`); } if (status) { - lines.push(` * @libar-docs-status ${status}`); + lines.push(` * @architect-status ${status}`); } for (const useCase of useCases) { - lines.push(` * @libar-docs-usecase "${useCase}"`); + lines.push(` * @architect-usecase "${useCase}"`); } for (const uses_ of uses) { - lines.push(` * @libar-docs-uses ${uses_}`); + lines.push(` * @architect-uses ${uses_}`); } for (const usedBy_ of usedBy) { - lines.push(` * @libar-docs-used-by ${usedBy_}`); + lines.push(` * @architect-used-by ${usedBy_}`); } if (archRole) { - lines.push(` * @libar-docs-arch-role ${archRole}`); + lines.push(` * @architect-arch-role ${archRole}`); } if (archContext) { - lines.push(` * @libar-docs-arch-context ${archContext}`); + lines.push(` * @architect-arch-context ${archContext}`); } if (archLayer) { - lines.push(` * @libar-docs-arch-layer ${archLayer}`); + lines.push(` * @architect-arch-layer ${archLayer}`); } lines.push(' *'); @@ -244,11 +244,11 @@ export function createTsFileWithDirective(options: { } /** - * Create a minimal TypeScript file without @libar-docs directive. + * Create a minimal TypeScript file without @architect directive. */ export function createTsFileWithoutDirective(): string { return `/** - * A regular TypeScript file without @libar-docs. + * A regular TypeScript file without @architect. */ export interface RegularType { value: string; @@ -257,7 +257,7 @@ export interface RegularType { } /** - * Create a Gherkin feature file with @libar-docs-* tags. + * Create a Gherkin feature file with @architect-* tags. * * @example * ```typescript @@ -292,12 +292,12 @@ export function createFeatureFile(options: { const lines: string[] = []; - // Process tags (using @libar-docs-* prefix per PDR-004) - lines.push(`@libar-docs-phase:${phase}`); - lines.push(`@libar-docs-status:${status}`); - lines.push(`@libar-docs-quarter:${quarter}`); - lines.push(`@libar-docs-effort:${effort}`); - lines.push(`@libar-docs-team:${team}`); + // Process tags (using @architect-* prefix per PDR-004) + lines.push(`@architect-phase:${phase}`); + lines.push(`@architect-status:${status}`); + lines.push(`@architect-quarter:${quarter}`); + lines.push(`@architect-effort:${effort}`); + lines.push(`@architect-team:${team}`); lines.push(`Feature: ${name}`); lines.push(` ${description}`); lines.push(''); diff --git a/tests/support/helpers/lint-rules-state.ts b/tests/support/helpers/lint-rules-state.ts index 92c8624b..cef6d99f 100644 --- a/tests/support/helpers/lint-rules-state.ts +++ b/tests/support/helpers/lint-rules-state.ts @@ -58,7 +58,7 @@ export function initState(): LintRulesScenarioState { export function createTestDirective(overrides: Partial = {}): DocDirective { return { - tags: [asDirectiveTag('@libar-docs-test')], + tags: [asDirectiveTag('@architect-test')], description: '', examples: [], position: { startLine: 1, endLine: 10 }, diff --git a/tests/support/helpers/mcp-state.ts b/tests/support/helpers/mcp-state.ts index ab86fb16..9a805cd5 100644 --- a/tests/support/helpers/mcp-state.ts +++ b/tests/support/helpers/mcp-state.ts @@ -3,8 +3,8 @@ * * Shared state and mock infrastructure for MCP server tests. * - * @libar-docs - * @libar-docs-uses MCPPipelineSession, ProcessStateAPI, TagRegistry + * @architect + * @architect-uses MCPPipelineSession, ProcessStateAPI, TagRegistry */ import type { PipelineSession, ParsedOptions } from '../../../src/mcp/index.js'; @@ -85,7 +85,7 @@ export function createTestPipelineSession(): PipelineSession { /** * Creates a PipelineSession with specific patterns for filter testing. - * Returns patterns with known status+phase combinations for dp_list filter verification. + * Returns patterns with known status+phase combinations for architect_list filter verification. */ export function createFilterTestSession(): PipelineSession { const patterns = [ @@ -110,7 +110,7 @@ export function createFilterTestSession(): PipelineSession { /** * Creates a PipelineSession with a pattern that has deliverables and dependencies. - * Used for dp_pattern enrichment tests. + * Used for architect_pattern enrichment tests. */ export function createRichPatternSession(): PipelineSession { const dep = createTestPattern({ diff --git a/tests/support/helpers/pr-changes-codec-state.ts b/tests/support/helpers/pr-changes-codec-state.ts index c1fb029e..bd81b1ab 100644 --- a/tests/support/helpers/pr-changes-codec-state.ts +++ b/tests/support/helpers/pr-changes-codec-state.ts @@ -3,7 +3,7 @@ * * Extracted from pr-changes-codec.steps.ts to support split test files. * - * @libar-docs + * @architect */ import type { RenderableDocument, TableBlock } from '../../../src/renderable/schema.js'; import type { MasterDataset } from '../../../src/validation-schemas/master-dataset.js'; diff --git a/tests/support/helpers/process-api-state.ts b/tests/support/helpers/process-api-state.ts index 1b8fe136..d299c7b6 100644 --- a/tests/support/helpers/process-api-state.ts +++ b/tests/support/helpers/process-api-state.ts @@ -4,7 +4,7 @@ * Extracted from process-api.steps.ts to be shared across * the split test files (core, subcommands, modifiers-rules). * - * @libar-docs + * @architect */ import { writeTempFile, createTsFileWithDirective, type TempDirContext } from './file-system.js'; @@ -98,12 +98,12 @@ export function createFeatureFilesWithRules(): Array<{ path: string; content: st { path: 'specs/validation-rules.feature', content: [ - '@libar-docs', - '@libar-docs-pattern:ValidationRulesTest', - '@libar-docs-status:completed', - '@libar-docs-unlock-reason:Split-from-original', - '@libar-docs-product-area:Validation', - '@libar-docs-phase:10', + '@architect', + '@architect-pattern:ValidationRulesTest', + '@architect-status:completed', + '@architect-unlock-reason:Split-from-original', + '@architect-product-area:Validation', + '@architect-phase:10', 'Feature: Validation Rules Test', '', ' Rule: Completed files require unlock', @@ -132,11 +132,11 @@ export function createFeatureFilesWithRules(): Array<{ path: string; content: st { path: 'specs/core-utils.feature', content: [ - '@libar-docs', - '@libar-docs-pattern:CoreUtilsTest', - '@libar-docs-status:completed', - '@libar-docs-product-area:CoreTypes', - '@libar-docs-phase:5', + '@architect', + '@architect-pattern:CoreUtilsTest', + '@architect-status:completed', + '@architect-product-area:CoreTypes', + '@architect-phase:5', 'Feature: Core Utils Test', '', ' Rule: Slugify produces URL-safe slugs', diff --git a/tests/support/setup.ts b/tests/support/setup.ts index ad0ed642..3175a678 100644 --- a/tests/support/setup.ts +++ b/tests/support/setup.ts @@ -4,7 +4,7 @@ * This module provides common setup utilities for BDD tests. * It handles test lifecycle hooks and global configuration. * - * @libar-docs + * @architect */ import { beforeEach } from 'vitest'; diff --git a/tests/support/world.ts b/tests/support/world.ts index 5b3b749a..3b439597 100644 --- a/tests/support/world.ts +++ b/tests/support/world.ts @@ -4,7 +4,7 @@ * This module defines shared types and interfaces used across all BDD step definitions. * It follows the vitest-cucumber pattern of module-level state that gets reset per scenario. * - * @libar-docs + * @architect */ import type { Result } from '../../src/types/result.js'; From 7fd3a3884c12927e2a578305a1c4ba3961870001 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Darko=20Mijic=CC=81?= Date: Sat, 14 Mar 2026 23:41:00 +0100 Subject: [PATCH 2/3] =?UTF-8?q?fix:=20polish=20rebrand=20=E2=80=94=20comme?= =?UTF-8?q?nts,=20silent=20failures,=20backward=20compat?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixes from multi-agent review of the rebranding PR: Comment accuracy: - Replace "delivery process" product references in JSDoc and help text with "project state", "workflow rules", "Architect" as appropriate - Fix @architect-usecase annotations in process-api CLI - Fix runtime string in reference codec (appears in generated docs) - Update docs-sources preambles with new CLI names - Fix test support comment headers and temp dir prefix Silent failure prevention: - Config loader warns when both architect.config.ts AND delivery-process.config.ts coexist (prevents editing wrong file) - Dataset cache key now includes legacy config file mtimes (prevents stale cache when editing legacy config) - Fix grammar: "a ArchitectProjectConfig" → "an ArchitectProjectConfig" Config path fix: - architect.config.ts: design-review outputDirectory was still 'delivery-process', changed to 'architect' --- AGENTS.md | 22 +++++------ CONTRIBUTING.md | 4 +- README.md | 4 +- architect.config.ts | 4 +- ...kflow-config-and-fsm-extensibility.feature | 2 +- .../data-api-platform-integration.feature | 2 +- docs-sources/process-guard.md | 2 +- docs-sources/validation-tools-guide.md | 38 +++++++++---------- docs/DOCS-GAP-ANALYSIS.md | 20 +++++----- docs/GHERKIN-PATTERNS.md | 2 +- docs/SESSION-GUIDES.md | 2 +- package.json | 6 +-- src/api/index.ts | 4 +- src/api/process-state.ts | 4 +- src/cli/dataset-cache.ts | 8 +++- src/cli/lint-process.ts | 4 +- src/cli/process-api.ts | 4 +- src/cli/version.ts | 2 +- src/config/config-loader.ts | 18 ++++++++- src/config/factory.ts | 10 ++--- src/config/regex-builders.ts | 2 +- src/config/types.ts | 2 +- src/extractor/shape-extractor.ts | 2 +- src/lint/process-guard/decider.ts | 2 +- src/lint/process-guard/index.ts | 2 +- src/renderable/codecs/index-codec.ts | 2 +- src/renderable/codecs/reference.ts | 2 +- src/scanner/gherkin-ast-parser.ts | 3 +- src/validation-schemas/tag-registry.ts | 2 +- tests/support/helpers/assertions.ts | 2 +- tests/support/helpers/file-system.ts | 4 +- tests/support/world.ts | 2 +- 32 files changed, 106 insertions(+), 83 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index b7467108..24cde0ee 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -24,12 +24,12 @@ This file helps future Codex sessions ramp up quickly in this repository. ## Onboarding Context (Tutorial WIP) -- External tutorial source: `/Users/darkomijic/dev-projects/delivery-process-tutorials/TUTORIAL-ARTICLE-v1.md` +- External tutorial source: `/Users/darkomijic/dev-projects/architect-tutorials/TUTORIAL-ARTICLE-v1.md` - Tutorial goal: bootstrap from blank project to full docs/query flow (`11 patterns`, `26 generated files` in demo scenario). - Treat tutorial outputs as illustrative; validate commands against current CLI behavior before codemods/docs changes. - Important known alignment points from tutorial review: - - `process-api overview` includes the Data API helper section in output (not always shown in article snippets). - - Current `generate-docs --list-generators` output does not include `product-area-docs`. + - `architect overview` includes the Data API helper section in output (not always shown in article snippets). + - Current `architect-generate --list-generators` output does not include `product-area-docs`. - `architect-generate` accepts both repeated `-g` flags and comma-separated generator lists. - Shape-derived entries can affect counts and `stubs` output (shape patterns appear as separate entries). - `arch context` groups only patterns carrying explicit `@architect-arch-context`. @@ -41,11 +41,11 @@ When guiding users in external repos, pick command style based on config format: - If the repo uses `architect.config.js` (or no config), package binaries are fine: ```bash -npx generate-docs --help +npx architect-generate --help npx architect --help -npx lint-patterns --help +npx architect-lint-patterns --help npx architect-guard --help -npx validate-patterns --help +npx architect-validate --help ``` - If the repo uses `architect.config.ts`, use `tsx`-based wrappers (or switch to `.js` config). @@ -123,8 +123,8 @@ pnpm test Process/quality checks: ```bash -pnpm lint:steps -pnpm lint-patterns +pnpm architect:lint-steps +pnpm architect:lint-patterns pnpm architect:guard pnpm validate:patterns pnpm validate:dod @@ -147,7 +147,7 @@ pnpm docs:all Rule: do not hand-edit generated artifacts when regeneration is the intended flow. -Current built-in generator list is discovered from CLI (`generate-docs --list-generators`). +Current built-in generator list is discovered from CLI (`architect-generate --list-generators`). Do not assume undocumented generator names are available without checking. ## Testing Rules (Important) @@ -184,7 +184,7 @@ There is currently no dedicated interactive onboarding command in this package. If implementing one, design for existing-repo adoption first: 1. Command shape - - Add a new bin command (example: `delivery-process-init`) so users can run `npx delivery-process-init`. + - Add a new bin command (example: `architect-init`) so users can run `npx architect-init`. 2. Wizard responsibilities - Detect package manager and module mode (`type: module`). - Scaffold `architect.config.ts` with chosen preset and discovered source globs. @@ -194,4 +194,4 @@ If implementing one, design for existing-repo adoption first: - Dry-run mode and explicit overwrite confirmations. - Never silently overwrite existing `architect.config.ts` or user scripts. 4. Success criteria - - User can run `process-api overview` and `generate-docs --list-generators` immediately after setup. + - User can run `architect overview` and `architect-generate --list-generators` immediately after setup. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 18730a18..a0654d58 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -12,8 +12,8 @@ We welcome contributions! This guide covers how to get started. ```bash # Fork the repo on GitHub, then: -git clone https://github.com//delivery-process.git -cd delivery-process +git clone https://github.com//architect.git +cd architect pnpm install pnpm build && pnpm test ``` diff --git a/README.md b/README.md index 81bb3d02..b276fb6c 100644 --- a/README.md +++ b/README.md @@ -55,7 +55,7 @@ export class UserAuthentication { ### 3. Generate Documentation ```bash -npx generate-docs -g patterns -i "src/**/*.ts" -o docs -f +npx architect-generate -g patterns -i "src/**/*.ts" -o docs -f ``` ### 4. Enforce Workflow (Pre-commit Hook) @@ -115,7 +115,7 @@ All output goes to [`docs-live/`](docs-live/INDEX.md) — 57+ auto-generated fil | Command | Purpose | Docs | | ------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------- | -| `architect-generate` | Generate documentation from annotated sources | `generate-docs --help` | +| `architect-generate` | Generate documentation from annotated sources | `architect-generate --help` | | `architect` | Query delivery state for AI coding sessions | [Process API Reference](docs-live/reference/PROCESS-API-REFERENCE.md) | | `architect-lint-patterns` | Validate annotation quality (missing tags, etc.) | [Validation Rules](docs-live/VALIDATION-RULES.md) | | `architect-guard` | Validate delivery workflow FSM transitions | [Process Guard Reference](docs-live/reference/PROCESS-GUARD-REFERENCE.md) | diff --git a/architect.config.ts b/architect.config.ts index 82b68f91..abb0f131 100644 --- a/architect.config.ts +++ b/architect.config.ts @@ -1,5 +1,5 @@ /** - * Delivery-process package configuration. + * Architect package configuration. * * Unified config replacing repeated CLI globs across 15+ package.json scripts. * Uses @architect- prefix with simplified 3-category taxonomy. @@ -275,7 +275,7 @@ export default defineConfig({ outputDirectory: 'docs-live', }, 'design-review': { - outputDirectory: 'delivery-process', + outputDirectory: 'architect', }, }, codecOptions: { diff --git a/architect/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature b/architect/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature index 930807b5..4d78dbee 100644 --- a/architect/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature +++ b/architect/ideations/2026-02-15-workflow-config-and-fsm-extensibility.feature @@ -94,7 +94,7 @@ Feature: Workflow Configuration, Process Instance, and FSM Extensibility Rule: Three projects with different workflow requirements | Context | Workflow Needs | Config Complexity | - | This package (delivery-process) | Full 6-phase, 298 patterns | Uses itself as POC | + | This package (architect) | Full 6-phase, 298 patterns | Uses itself as POC | | Monorepo (libar-platform) | Full 6-phase, multi-package | Primary consumer | | Future adopters (open-source) | Minimal or custom phases | Must work with zero config | diff --git a/architect/specs/data-api-platform-integration.feature b/architect/specs/data-api-platform-integration.feature index 6fed359a..7a58165c 100644 --- a/architect/specs/data-api-platform-integration.feature +++ b/architect/specs/data-api-platform-integration.feature @@ -70,7 +70,7 @@ Feature: Data API Platform Integration - MCP Server and Monorepo Support // .mcp.json or claude_desktop_config.json { "mcpServers": { - "delivery-process": { + "architect": { "command": "npx", "args": ["tsx", "src/mcp/server.ts", "--input", "src/**/*.ts", ...] } diff --git a/docs-sources/process-guard.md b/docs-sources/process-guard.md index b3d3292a..2d0bf746 100644 --- a/docs-sources/process-guard.md +++ b/docs-sources/process-guard.md @@ -32,7 +32,7 @@ ## CLI Usage ```bash -lint-process [options] +architect-guard [options] ``` ### Modes diff --git a/docs-sources/validation-tools-guide.md b/docs-sources/validation-tools-guide.md index cdc4dea6..ca7540fa 100644 --- a/docs-sources/validation-tools-guide.md +++ b/docs-sources/validation-tools-guide.md @@ -2,16 +2,16 @@ ```text Need to check annotation quality? - Yes -> lint-patterns + Yes -> architect-lint-patterns Need to check vitest-cucumber compatibility? - Yes -> lint-steps + Yes -> architect-lint-steps Need FSM workflow validation? - Yes -> lint-process + Yes -> architect-guard Need cross-source or DoD validation? - Yes -> validate-patterns + Yes -> architect-validate Running pre-commit hook? architect-guard --staged (default) @@ -28,13 +28,13 @@ Running pre-commit hook? --- -## lint-patterns +## architect-lint-patterns Validates `@-*` annotation quality in TypeScript files. ```bash -npx lint-patterns -i "src/**/*.ts" -npx lint-patterns -i "src/**/*.ts" --strict # CI +npx architect-lint-patterns -i "src/**/*.ts" +npx architect-lint-patterns -i "src/**/*.ts" --strict # CI ``` ### CLI Flags @@ -64,7 +64,7 @@ npx lint-patterns -i "src/**/*.ts" --strict # CI --- -## lint-steps +## architect-lint-steps Static analyzer for vitest-cucumber feature/step compatibility. Catches mismatches that cause cryptic runtime failures. @@ -112,7 +112,7 @@ pnpm lint:steps --strict # CI --- -## lint-process +## architect-guard FSM validation for delivery workflow. Enforces status transitions and protection levels. @@ -132,12 +132,12 @@ For detailed rules, escape hatches, and error fixes, see the [Process Guard Refe --- -## validate-patterns +## architect-validate Cross-source validator combining multiple checks. ```bash -npx validate-patterns \ +npx architect-validate \ -i "src/**/*.ts" \ -F "specs/**/*.feature" \ --dod \ @@ -194,12 +194,12 @@ For patterns with `completed` status, checks: ```json { "scripts": { - "lint:patterns": "lint-patterns -i 'src/**/*.ts'", - "lint:steps": "lint-steps", - "lint:steps:ci": "lint-steps --strict", + "lint:patterns": "architect-lint-patterns -i 'src/**/*.ts'", + "lint:steps": "architect-lint-steps", + "lint:steps:ci": "architect-lint-steps --strict", "lint:process": "architect-guard --staged", "lint:process:ci": "architect-guard --all --strict", - "validate:all": "validate-patterns -i 'src/**/*.ts' -F 'specs/**/*.feature' --dod --anti-patterns" + "validate:all": "architect-validate -i 'src/**/*.ts' -F 'specs/**/*.feature' --dod --anti-patterns" } } ``` @@ -214,20 +214,20 @@ npx architect-guard --staged ```yaml - name: Lint annotations - run: npx lint-patterns -i "src/**/*.ts" --strict + run: npx architect-lint-patterns -i "src/**/*.ts" --strict - name: Lint steps - run: npx lint-steps --strict + run: npx architect-lint-steps --strict - name: Validate patterns - run: npx validate-patterns -i "src/**/*.ts" -F "specs/**/*.feature" --dod --anti-patterns + run: npx architect-validate -i "src/**/*.ts" -F "specs/**/*.feature" --dod --anti-patterns ``` --- ## Exit Codes -| Code | lint-patterns / lint-steps / lint-process | validate-patterns | +| Code | architect-lint-patterns / architect-lint-steps / architect-guard | architect-validate | | ---- | -------------------------------------------- | ----------------------------------- | | `0` | No errors (warnings allowed unless --strict) | No issues found | | `1` | Errors found (or warnings with --strict) | Errors found | diff --git a/docs/DOCS-GAP-ANALYSIS.md b/docs/DOCS-GAP-ANALYSIS.md index 1664c8b1..9ac968eb 100644 --- a/docs/DOCS-GAP-ANALYSIS.md +++ b/docs/DOCS-GAP-ANALYSIS.md @@ -275,7 +275,7 @@ sync-content.mjs | Section | Directory | Source | Collapsed | | ---------------------- | -------------- | ------------------------------------------ | --------- | -| Tutorial | tutorial/ | delivery-process-tutorials repo | No | +| Tutorial | tutorial/ | architect-tutorials repo | No | | Guides | guides/ | docs/ manual (5 files) | No | | Reference | reference/ | docs/ manual (5 files) | No | | Product Areas | product-areas/ | docs-live/product-areas/ | No | @@ -475,7 +475,7 @@ the sync script should be updated to read from `docs-live/` instead of `docs/`: **Scope:** libar-dev-website repo **Effort:** Small (1 session) **Spec alignment:** Consequence of DocsLiveConsolidation (Phase 37, completed). -No new delivery-process spec needed -- this is a website-repo fix. +No new architect spec needed -- this is a website-repo fix. Update `sync-content.mjs` and `content-manifest.mjs` to: @@ -492,7 +492,7 @@ Update `sync-content.mjs` and `content-manifest.mjs` to: ### WP-2: Enhance Generated Index (P1) **Type:** Design + Implementation -**Scope:** delivery-process repo +**Scope:** architect repo **Effort:** Small (1-2 sessions) **Spec alignment:** Maps to DocsConsolidationStrategy Phase 6 (Index navigation update, pending). Update the existing deliverable status when implementing. @@ -510,7 +510,7 @@ to generate audience-appropriate navigation. ### WP-3: Add Architecture Generator to docs:all (P1) **Type:** Implementation session -**Scope:** delivery-process repo +**Scope:** architect repo **Effort:** Small (1 session) **Spec alignment:** Extends Phase 4 (Architecture decomposition, complete). Phase 4 decomposed the manual ARCHITECTURE.md; this adds the generated Mermaid equivalent. @@ -522,7 +522,7 @@ that partially replace the manual ARCHITECTURE.md data flow diagrams. ### WP-4: Add Changelog Generator to docs:all (P2) **Type:** Implementation session -**Scope:** delivery-process repo +**Scope:** architect repo **Effort:** Small (1 session) **Spec alignment:** New work, not covered by DocsConsolidationStrategy. Consider adding as a new deliverable if a spec is created. @@ -533,7 +533,7 @@ New content for the website (no manual equivalent to replace). ### WP-5: Create Error Guide Codec (P2) **Type:** Design + Implementation -**Scope:** delivery-process repo +**Scope:** architect repo **Effort:** Medium (2-3 sessions) **Spec alignment:** Maps to DocsConsolidationStrategy Phase 3 (Process Guard consolidation, pending). The spec says "enhanced ValidationRulesCodec" -- design @@ -557,7 +557,7 @@ This replaces the manual PROCESS-GUARD.md "Error Messages and Fixes" section. ### WP-6: Create CLI Recipe Codec (P2) **Type:** Design + Implementation -**Scope:** delivery-process repo +**Scope:** architect repo **Effort:** Medium (2-3 sessions) **Spec alignment:** Extends ProcessApiHybridGeneration (Phase 43, completed). Phase 43 generated reference tables from CLI schema; this adds recipe/guide content. The manual @@ -580,7 +580,7 @@ This replaces manual PROCESS-API.md "Common Recipes" and "Session Workflow Comma ### WP-7: Create Procedural Guide Codec (P3) **Type:** Design + Implementation -**Scope:** delivery-process repo +**Scope:** architect repo **Effort:** Large (3-5 sessions) **Spec alignment:** Maps to DocsConsolidationStrategy Phase 41 (GHERKIN-PATTERNS.md restructure, pending) and Phase 39 (Session workflow module generation, pending -- @@ -612,7 +612,7 @@ GHERKIN-PATTERNS.md (366 lines of authoring guidance) have no generation source. ### WP-8: Decide Methodology Page Disposition (P3) **Type:** Design session -**Scope:** delivery-process repo +**Scope:** architect repo **Effort:** Small (1 session) **Spec alignment:** DocsConsolidationStrategy explicitly says "Keep: philosophy and core thesis" for METHODOLOGY.md. The master spec already decided this stays manual. @@ -711,7 +711,7 @@ manual maintenance burden while preserving irreducibly editorial content. ## 10.5. Spec Coverage Status -Maps each WP to its delivery-process spec, design status, and code stubs. +Maps each WP to its architect spec, design status, and code stubs. | WP | Pattern | Spec Status | Design Status | Stubs | | ---- | -------------------------- | ------------ | -------------------------------------------- | ------- | diff --git a/docs/GHERKIN-PATTERNS.md b/docs/GHERKIN-PATTERNS.md index f7b7f8fc..4fff5992 100644 --- a/docs/GHERKIN-PATTERNS.md +++ b/docs/GHERKIN-PATTERNS.md @@ -2,7 +2,7 @@ > **Deprecated:** This document is superseded by the auto-generated [Gherkin Authoring Guide](../docs-live/reference/GHERKIN-AUTHORING-GUIDE.md). This file is preserved for reference only. Examples below may be stale and should not be used as templates — refer to the auto-generated guide for current patterns. -Practical patterns for writing Gherkin specs that work with `delivery-process` generators. +Practical patterns for writing Gherkin specs that work with Architect generators. --- diff --git a/docs/SESSION-GUIDES.md b/docs/SESSION-GUIDES.md index 65a69063..5ee651e5 100644 --- a/docs/SESSION-GUIDES.md +++ b/docs/SESSION-GUIDES.md @@ -86,7 +86,7 @@ pnpm architect:query -- list --status roadmap --names-only # Available patt - Transition to `active` - Ask "Ready to implement?" -### Example: delivery-process dogfood +### Example: Architect dogfood See [`tests/features/validation/fsm-validator.feature`](../tests/features/validation/fsm-validator.feature) for a complete roadmap spec with Rules, ScenarioOutlines, and proper tagging. diff --git a/package.json b/package.json index 6dc746a1..413f470d 100644 --- a/package.json +++ b/package.json @@ -175,12 +175,12 @@ "license": "(MIT AND BUSL-1.1)", "repository": { "type": "git", - "url": "git+https://github.com/libar-dev/delivery-process.git" + "url": "git+https://github.com/libar-dev/architect.git" }, "bugs": { - "url": "https://github.com/libar-dev/delivery-process/issues" + "url": "https://github.com/libar-dev/architect/issues" }, - "homepage": "https://github.com/libar-dev/delivery-process#readme", + "homepage": "https://github.com/libar-dev/architect#readme", "engines": { "node": ">=18.0.0" }, diff --git a/src/api/index.ts b/src/api/index.ts index 8cad8779..a646b7c0 100644 --- a/src/api/index.ts +++ b/src/api/index.ts @@ -7,11 +7,11 @@ * ## API Module - Programmatic Process State Interface * * Central export for the Process State API, providing a TypeScript - * interface for querying delivery process state. + * interface for querying project state. * * ### When to Use * - * - When building tools that need programmatic access to delivery process state + * - When building tools that need programmatic access to project state * - When integrating with Claude Code for real-time process queries * - When building CI/CD pipelines that validate delivery workflow * diff --git a/src/api/process-state.ts b/src/api/process-state.ts index c6cbb8f7..10726bdc 100644 --- a/src/api/process-state.ts +++ b/src/api/process-state.ts @@ -11,7 +11,7 @@ * * ## Process State API - Programmatic Query Interface * - * TypeScript interface for querying delivery process state. + * TypeScript interface for querying project state. * Designed for Claude Code integration and programmatic access. * * ### When to Use @@ -82,7 +82,7 @@ import type { // ============================================================================= /** - * Programmatic API for querying delivery process state + * Programmatic API for querying project state */ export interface ProcessStateAPI { // ───────────────────────────────────────────────────────────────────────── diff --git a/src/cli/dataset-cache.ts b/src/cli/dataset-cache.ts index 77c9480c..6c2622f4 100644 --- a/src/cli/dataset-cache.ts +++ b/src/cli/dataset-cache.ts @@ -108,7 +108,13 @@ export async function computeCacheKey(opts: PipelineOptions): Promise { } // Also include config file mtime if it exists (.ts or .js) - for (const configName of ['architect.config.ts', 'architect.config.js']) { + // Include legacy names too — config-loader supports them with deprecation warnings + for (const configName of [ + 'architect.config.ts', + 'architect.config.js', + 'delivery-process.config.ts', + 'delivery-process.config.js', + ]) { const configPath = path.join(baseDir, configName); try { const configStat = await fsp.stat(configPath); diff --git a/src/cli/lint-process.ts b/src/cli/lint-process.ts index 8d092929..df30b3fc 100644 --- a/src/cli/lint-process.ts +++ b/src/cli/lint-process.ts @@ -11,7 +11,7 @@ * * ## LintProcessCLI - Process Guard Linter CLI * - * Validates git changes against delivery process rules. + * Validates git changes against workflow rules. * Enforces protection levels, status transitions, and session scope. * * ### When to Use @@ -139,7 +139,7 @@ export function parseArgs(argv: string[] = process.argv.slice(2)): ProcessGuardC */ export function printHelp(): void { console.log(` -architect-guard - Validate changes against delivery process rules +architect-guard - Validate changes against workflow rules Usage: architect-guard [options] [files...] diff --git a/src/cli/process-api.ts b/src/cli/process-api.ts index b31d244c..015b42af 100644 --- a/src/cli/process-api.ts +++ b/src/cli/process-api.ts @@ -10,7 +10,7 @@ * @architect-arch-layer application * @architect-uses ProcessStateAPI, MasterDataset, PipelineFactory, RulesQueryModule, PatternSummarizerImpl, FuzzyMatcherImpl, OutputPipelineImpl * @architect-used-by npm scripts, Claude Code sessions - * @architect-usecase "When querying delivery process state from CLI" + * @architect-usecase "When querying project state from CLI" * @architect-usecase "When Claude Code needs real-time delivery state queries" * * ## architect - CLI Query Interface to ProcessStateAPI @@ -389,7 +389,7 @@ function showHelp(): void { const sessions = formatHelpOptions(CLI_SCHEMA.sessionOptions); console.log(` -architect - Query delivery process state from annotated sources +architect - Query project state from annotated sources Use this instead of reading generated markdown or launching explore agents. Targeted queries use 5-10x less context than file reads. diff --git a/src/cli/version.ts b/src/cli/version.ts index 8c9ef4e3..94e42454 100644 --- a/src/cli/version.ts +++ b/src/cli/version.ts @@ -64,7 +64,7 @@ export function getPackageName(): string { /** * Print version information and exit * - * @param cliName - Name of the CLI command (e.g., "generate-docs") + * @param cliName - Name of the CLI command (e.g., "architect-generate") */ export function printVersionAndExit(cliName: string): never { console.log(`${cliName} (${getPackageName()}) v${getPackageVersion()}`); diff --git a/src/config/config-loader.ts b/src/config/config-loader.ts index 0f1012f5..2e6a5fe3 100644 --- a/src/config/config-loader.ts +++ b/src/config/config-loader.ts @@ -150,12 +150,28 @@ export async function findConfigFile(startDir: string): Promise { // Check for TypeScript config first const tsConfigPath = path.join(currentDir, CONFIG_FILE_NAME); if (await fileExists(tsConfigPath)) { + // Warn if legacy config also exists — user should clean up + const legacyTsPath = path.join(currentDir, LEGACY_CONFIG_FILE_NAME); + if (await fileExists(legacyTsPath)) { + console.error( + `Warning: Both '${CONFIG_FILE_NAME}' and '${LEGACY_CONFIG_FILE_NAME}' exist in ${currentDir}. ` + + `Using '${CONFIG_FILE_NAME}'. Delete '${LEGACY_CONFIG_FILE_NAME}' to silence this warning.` + ); + } return tsConfigPath; } // Check for JavaScript config (pre-compiled) const jsConfigPath = path.join(currentDir, CONFIG_FILE_NAME_JS); if (await fileExists(jsConfigPath)) { + // Warn if legacy config also exists — user should clean up + const legacyJsPath = path.join(currentDir, LEGACY_CONFIG_FILE_NAME_JS); + if (await fileExists(legacyJsPath)) { + console.error( + `Warning: Both '${CONFIG_FILE_NAME_JS}' and '${LEGACY_CONFIG_FILE_NAME_JS}' exist in ${currentDir}. ` + + `Using '${CONFIG_FILE_NAME_JS}'. Delete '${LEGACY_CONFIG_FILE_NAME_JS}' to silence this warning.` + ); + } return jsConfigPath; } @@ -424,7 +440,7 @@ export async function loadProjectConfig(baseDir: string): Promise> = { question: 'How do I query process state?', covers: 'Process state API, stubs, context assembly, CLI', intro: - 'The Data API provides direct terminal access to delivery process state. ' + + 'The Data API provides direct terminal access to project state. ' + 'It replaces reading generated markdown or launching explore agents — targeted queries ' + 'use 5-10x less context. The `context` command assembles curated bundles tailored to ' + 'session type (planning, design, implement).', diff --git a/src/scanner/gherkin-ast-parser.ts b/src/scanner/gherkin-ast-parser.ts index dc301d00..83d710d4 100644 --- a/src/scanner/gherkin-ast-parser.ts +++ b/src/scanner/gherkin-ast-parser.ts @@ -596,7 +596,8 @@ export function extractPatternTags(tags: readonly string[]): { if ( normalized !== 'acceptance-criteria' && !normalized.startsWith('happy-path') && - normalized !== 'libar-docs' + normalized !== 'libar-docs' && + normalized !== 'architect' ) { const existing = metadata['categories'] as string[] | undefined; metadata['categories'] = [...(existing ?? []), normalized]; diff --git a/src/validation-schemas/tag-registry.ts b/src/validation-schemas/tag-registry.ts index 413d4821..cd9063be 100644 --- a/src/validation-schemas/tag-registry.ts +++ b/src/validation-schemas/tag-registry.ts @@ -13,7 +13,7 @@ * * - Validating tag registry configuration at runtime * - Merging custom registry overrides with default registry - * - Creating delivery process instances with custom categories + * - Creating Architect instances with custom categories */ import { z } from 'zod'; diff --git a/tests/support/helpers/assertions.ts b/tests/support/helpers/assertions.ts index b4355c9d..90acc5f9 100644 --- a/tests/support/helpers/assertions.ts +++ b/tests/support/helpers/assertions.ts @@ -1,5 +1,5 @@ /** - * BDD Assertion Helpers for delivery-process Tests + * BDD Assertion Helpers for Architect Tests * * Custom assertion utilities that work with vitest-cucumber step definitions. * These helpers provide domain-specific assertions for: diff --git a/tests/support/helpers/file-system.ts b/tests/support/helpers/file-system.ts index b612a85b..5f838664 100644 --- a/tests/support/helpers/file-system.ts +++ b/tests/support/helpers/file-system.ts @@ -29,7 +29,7 @@ export interface TempDirContext { * Options for creating a temporary directory. */ export interface TempDirOptions { - /** Prefix for the temp directory name (default: "delivery-process-test-") */ + /** Prefix for the temp directory name (default: "architect-test-") */ prefix?: string; /** Whether to keep the directory after cleanup (for debugging) */ keepOnCleanup?: boolean; @@ -54,7 +54,7 @@ export interface TempDirOptions { * ``` */ export async function createTempDir(options: TempDirOptions = {}): Promise { - const { prefix = 'delivery-process-test-', keepOnCleanup = false } = options; + const { prefix = 'architect-test-', keepOnCleanup = false } = options; const tempDir = await fs.mkdtemp(path.join(os.tmpdir(), prefix)); diff --git a/tests/support/world.ts b/tests/support/world.ts index 3b439597..cfdc4ff8 100644 --- a/tests/support/world.ts +++ b/tests/support/world.ts @@ -1,5 +1,5 @@ /** - * BDD Test World - Shared Types for delivery-process Tests + * BDD Test World - Shared Types for Architect Tests * * This module defines shared types and interfaces used across all BDD step definitions. * It follows the vitest-cucumber pattern of module-level state that gets reset per scenario. From 901820061327a30a463e8fcaeedeba47a7614d38 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Darko=20Mijic=CC=81?= Date: Sat, 14 Mar 2026 23:44:40 +0100 Subject: [PATCH 3/3] fix: revert GitHub URLs to current repo name The repo hasn't been renamed on GitHub yet (happens at 1.0.0 GA). Keep package.json, README, and CONTRIBUTING URLs pointing to libar-dev/delivery-process until the GitHub rename is done. --- CONTRIBUTING.md | 2 +- README.md | 2 +- package.json | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a0654d58..e687d243 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -69,7 +69,7 @@ These run automatically — no manual setup needed after `pnpm install`. ## Reporting Issues -- Use [GitHub Issues](https://github.com/libar-dev/architect/issues) +- Use [GitHub Issues](https://github.com/libar-dev/delivery-process/issues) - For security vulnerabilities, see [SECURITY.md](SECURITY.md) ## Code of Conduct diff --git a/README.md b/README.md index b276fb6c..bece013c 100644 --- a/README.md +++ b/README.md @@ -5,7 +5,7 @@ Turn TypeScript annotations and Gherkin specs into a **structured, queryable delivery state** — living documentation, architecture graphs, and FSM-enforced workflows that AI agents consume without hallucinating. [![npm version](https://img.shields.io/npm/v/@libar-dev/architect.svg)](https://www.npmjs.com/package/@libar-dev/architect) -[![Build Status](https://github.com/libar-dev/architect/workflows/CI/badge.svg)](https://github.com/libar-dev/architect/actions) +[![Build Status](https://github.com/libar-dev/delivery-process/workflows/CI/badge.svg)](https://github.com/libar-dev/delivery-process/actions) [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT) [![Node.js Version](https://img.shields.io/node/v/@libar-dev/architect.svg)](https://nodejs.org/) diff --git a/package.json b/package.json index 413f470d..6dc746a1 100644 --- a/package.json +++ b/package.json @@ -175,12 +175,12 @@ "license": "(MIT AND BUSL-1.1)", "repository": { "type": "git", - "url": "git+https://github.com/libar-dev/architect.git" + "url": "git+https://github.com/libar-dev/delivery-process.git" }, "bugs": { - "url": "https://github.com/libar-dev/architect/issues" + "url": "https://github.com/libar-dev/delivery-process/issues" }, - "homepage": "https://github.com/libar-dev/architect#readme", + "homepage": "https://github.com/libar-dev/delivery-process#readme", "engines": { "node": ">=18.0.0" },