{"id":"174090b1-289b-4e69-a4d5-c4f7f534a623","entityType":"agent","slug":"clawhub-mbmd-pdlc","name":"Pdlc","canonicalUrl":"https://www.xpersona.co/agent/clawhub-mbmd-pdlc","canonicalPath":"/agent/clawhub-mbmd-pdlc","generatedAt":"2026-10-11T07:36:28.460Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T04:11:01.573Z","emptyReason":null},"description":"AIFLC PDLC Family — 11 injectable workflow packages that guide AI coding agents through professional software delivery: idea evaluation → project initiation... Skill: Pdlc Owner: mbmd Summary: AIFLC PDLC Family — 11 injectable workflow packages that guide AI coding agents through professional software delivery: idea evaluation → project initiation... Tags: latest:1.0.0 Version history: v1.0.0 | 2026-07-07T16:51:06.102Z | auto - Initial release of the AIPDLC skill, offering 11 modular, injectable workflow packages for AI-assisted professional software delivery. - Covers the","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.2K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s177yte0b83dzbtys81qb8x7zh8a30wb:pdlc","sourceUrl":"https://clawhub.ai/mbmd/pdlc","homepage":"https://clawhub.ai/mbmd/skills/pdlc","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/mbmd/pdlc","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/mbmd/skills/pdlc","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"AIFLC PDLC Family — 11 injectable workflow packages that guide AI coding agents through professional software delivery: idea evaluation → project initiation... "},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T04:11:01.573Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T04:11:01.573Z","emptyReason":null},"stars":null,"forks":null,"downloads":1164,"packageName":null,"latestVersion":"1.0.0","tractionLabel":"1.2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T04:11:01.558Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T04:11:01.573Z","lastCrawledAt":"2026-10-11T04:11:01.558Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T04:11:01.558Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.0","createdAt":"2026-07-07T16:51:06.102Z","changelog":"- Initial release of the AIPDLC skill, offering 11 modular, injectable workflow packages for AI-assisted professional software delivery. - Covers the complete Product Development Life Cycle: from idea evaluation and initiation to architecture, workspace generation, compliance, and testing. - Each package acts as a domain expert (e.g., PMO advisor, architect, UX designer, DevOps, QA lead). - Designed for human-in-the-loop approval at every stage and is highly platform-agnostic. - Compatible with major AI coding platforms including Kiro, Amazon Q Developer, Cursor, Claude Code, Cline, and partially with GitHub Copilot. - Packages are chain-aware but fully functional as standalone workflows.","fileCount":896,"zipByteSize":2848479}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s177yte0b83dzbtys81qb8x7zh8a30wb:pdlc","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-mbmd-pdlc/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-mbmd-pdlc/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-mbmd-pdlc/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-mbmd-pdlc/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-mbmd-pdlc/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-mbmd-pdlc/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T07:36:28.457Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-mbmd-pdlc/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-mbmd-pdlc/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-mbmd-pdlc/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-mbmd-pdlc/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T04:11:01.573Z","emptyReason":null},"readme":"Skill: Pdlc\n\nOwner: mbmd\n\nSummary: AIFLC PDLC Family — 11 injectable workflow packages that guide AI coding agents through professional software delivery: idea evaluation → project initiation...\n\nTags: latest:1.0.0\n\nVersion history:\n\nv1.0.0 | 2026-07-07T16:51:06.102Z | auto\n\n- Initial release of the AIPDLC skill, offering 11 modular, injectable workflow packages for AI-assisted professional software delivery.\n- Covers the complete Product Development Life Cycle: from idea evaluation and initiation to architecture, workspace generation, compliance, and testing.\n- Each package acts as a domain expert (e.g., PMO advisor, architect, UX designer, DevOps, QA lead).\n- Designed for human-in-the-loop approval at every stage and is highly platform-agnostic.\n- Compatible with major AI coding platforms including Kiro, Amazon Q Developer, Cursor, Claude Code, Cline, and partially with GitHub Copilot.\n- Packages are chain-aware but fully functional as standalone workflows.\n\nArchive index:\n\nArchive v1.0.0: 896 files, 2848479 bytes\n\nFiles: ai-adlc/ai-adlc-rule-details/assembly/agent-installation.md (2985b), ai-adlc/ai-adlc-rule-details/assembly/package-assembly.md (16819b), ai-adlc/ai-adlc-rule-details/common/content-validation.md (10250b), ai-adlc/ai-adlc-rule-details/common/diagram-standards.md (12360b), ai-adlc/ai-adlc-rule-details/common/process-overview.md (13451b), ai-adlc/ai-adlc-rule-details/common/question-format-guide.md (9632b), ai-adlc/ai-adlc-rule-details/common/session-continuity.md (10464b), ai-adlc/ai-adlc-rule-details/common/test-mode.md (8786b), ai-adlc/ai-adlc-rule-details/common/welcome-message.md (4965b), ai-adlc/ai-adlc-rule-details/data-schema/adlc-data.schema.json (6382b), ai-adlc/ai-adlc-rule-details/data-schema/SCHEMA_README.md (1696b), ai-adlc/ai-adlc-rule-details/data-schema/SOURCE_MAP.md (7646b), ai-adlc/ai-adlc-rule-details/decisions/multi-tenancy.md (15158b), ai-adlc/ai-adlc-rule-details/decisions/security-identity.md (17324b), ai-adlc/ai-adlc-rule-details/decisions/technology-stack.md (12331b), ai-adlc/ai-adlc-rule-details/decomposition/container-design.md (14761b), ai-adlc/ai-adlc-rule-details/decomposition/system-context.md (12850b), ai-adlc/ai-adlc-rule-details/design/api-architecture.md (17793b), ai-adlc/ai-adlc-rule-details/design/component-design.md (17916b), ai-adlc/ai-adlc-rule-details/design/data-architecture.md (15569b), ai-adlc/ai-adlc-rule-details/design/integration-infrastructure.md (29049b), ai-adlc/ai-adlc-rule-details/drift-intake/intake-digest.md (8429b), ai-adlc/ai-adlc-rule-details/extensions/bff-pattern/bff-pattern.md (13461b), ai-adlc/ai-adlc-rule-details/extensions/bff-pattern/bff-pattern.opt-in.md (1486b), ai-adlc/ai-adlc-rule-details/extensions/ddd-tactical/ddd-tactical.md (14633b), ai-adlc/ai-adlc-rule-details/extensions/ddd-tactical/ddd-tactical.opt-in.md (1403b), ai-adlc/ai-adlc-rule-details/extensions/event-sourcing-cqrs/event-sourcing-cqrs.md (15712b), ai-adlc/ai-adlc-rule-details/extensions/event-sourcing-cqrs/event-sourcing-cqrs.opt-in.md (1699b), ai-adlc/ai-adlc-rule-details/extensions/feature-flags/feature-flags.md (15704b), ai-adlc/ai-adlc-rule-details/extensions/feature-flags/feature-flags.opt-in.md (1730b), ai-adlc/ai-adlc-rule-details/extensions/microservices/microservices.md (15473b), ai-adlc/ai-adlc-rule-details/extensions/microservices/microservices.opt-in.md (1392b), ai-adlc/ai-adlc-rule-details/extensions/README.md (8572b), ai-adlc/ai-adlc-rule-details/extensions/resilience-patterns/resilience-patterns.md (15935b), ai-adlc/ai-adlc-rule-details/extensions/resilience-patterns/resilience-patterns.opt-in.md (1597b), ai-adlc/ai-adlc-rule-details/foundation/architecture-vision.md (16936b), ai-adlc/ai-adlc-rule-details/foundation/requirements-ingestion.md (18654b), ai-adlc/ai-adlc-rule-details/foundation/workspace-detection.md (16503b), ai-adlc/ai-adlc-rule-details/templates/adr-template.md (1755b), ai-adlc/ai-adlc-rule-details/templates/agents/agent-guide.md (5213b), ai-adlc/ai-adlc-rule-details/templates/agents/architecture-decision-agent.md (11327b), ai-adlc/ai-adlc-rule-details/templates/agents/shortcut-rules-block.md (2745b), ai-adlc/ai-adlc-rule-details/templates/api-architecture.md (2214b), ai-adlc/ai-adlc-rule-details/templates/architecture-dashboard-template.md (7262b), ai-adlc/ai-adlc-rule-details/templates/architecture-vision.md (1724b), ai-adlc/ai-adlc-rule-details/templates/architecture-workbook.md (1312b), ai-adlc/ai-adlc-rule-details/templates/brownfield-strategy-adr.md (11551b), ai-adlc/ai-adlc-rule-details/templates/component-design.md (2051b), ai-adlc/ai-adlc-rule-details/templates/container-diagram.md (1693b), ai-adlc/ai-adlc-rule-details/templates/data-architecture.md (1988b), ai-adlc/ai-adlc-rule-details/templates/integration-architecture.md (2426b), ai-adlc/ai-adlc-rule-details/templates/management-framework.md (10767b), ai-adlc/ai-adlc-rule-details/templates/multi-tenancy.md (1485b), ai-adlc/ai-adlc-rule-details/templates/security-architecture.md (2049b), ai-adlc/ai-adlc-rule-details/templates/system-context.md (1625b), ai-adlc/ai-adlc-rule-details/templates/technology-stack.md (2306b), ai-adlc/ai-adlc-rules/core-workflow.md (23834b), ai-adlc/LICENSE (572b), ai-adlc/NOTICE (1015b), ai-adlc/README.md (15717b), ai-adlc/ROADMAP.md (5765b), ai-adlc/setup/INSTALL.md (5703b), ai-adlc/setup/TEST_MODE_USER_GUIDE.md (13829b), ai-adlc/USER_GUIDE.md (10882b), ai-adlc/WHITEPAPER.md (6762b), ai-dfe/ai-dfe-rule-details/common/process-overview.md (2905b), ai-dfe/ai-dfe-rule-details/common/session-continuity.md (1972b), ai-dfe/ai-dfe-rule-details/configure/demand-discovery.md (4559b), ai-dfe/ai-dfe-rule-details/configure/family-discovery.md (3217b), ai-dfe/ai-dfe-rule-details/configure/package-discovery.md (2060b), ai-dfe/ai-dfe-rule-details/data-schema/dfe-data.schema.json (2597b), ai-dfe/ai-dfe-rule-details/data-schema/SCHEMA_README.md (1631b), ai-dfe/ai-dfe-rule-details/data-schema/SOURCE_MAP.md (2091b), ai-dfe/ai-dfe-rule-details/govern/cleanup.md (1399b), ai-dfe/ai-dfe-rule-details/govern/freshness.md (1159b), ai-dfe/ai-dfe-rule-details/govern/history.md (1555b), ai-dfe/ai-dfe-rule-details/govern/validation.md (3658b), ai-dfe/ai-dfe-rule-details/operate/cross-family.md (1741b), ai-dfe/ai-dfe-rule-details/operate/cross-project.md (1462b), ai-dfe/ai-dfe-rule-details/operate/distribute.md (1604b) (+496 more)\n\nFile v1.0.0:ai-adlc/ai-adlc-rule-details/extensions/README.md\n\n# AI-ADLC Extensions — How They Work\r\n\r\n## Overview\r\n\r\nExtensions are optional rule sets that add specialized architectural pattern guidance on top of the core AI-ADLC workflow. They activate via user opt-in during the workflow — only when your system needs a specific pattern.\r\n\r\n---\r\n\r\n## The Pattern\r\n\r\nEach extension has **two files**:\r\n\r\n```\r\nextensions/{name}/\r\n├── {name}.opt-in.md ← Lightweight prompt (always scanned at workflow start)\r\n└── {name}.md ← Full rules (loaded ONLY if user opts in)\r\n```\r\n\r\n| File | Size | Loaded When | Purpose |\r\n|------|:----:|-------------|---------|\r\n| `*.opt-in.md` | Small | Always (at workflow start) | Presents the opt-in question to the user |\r\n| `*.md` (rules) | Large | Only if user says \"Yes\" | Provides detailed design rules, verification criteria, and templates |\r\n\r\n---\r\n\r\n## The Flow\r\n\r\n```\r\nWorkflow Start\r\n │\r\n ▼\r\n[Scan extensions/ folder — load ONLY *.opt-in.md files]\r\n │\r\n ▼ (During relevant stage — Stage 5, 6, or 12)\r\n │\r\n[Present opt-in questions to user]\r\n │\r\n ├── User says \"Yes\" ──► Load {name}.md (full rules)\r\n │ └──► Enforce in subsequent stages\r\n │ └──► Verify compliance at stage completion\r\n │\r\n └── User says \"No\" ──► Never load full rules\r\n └──► Zero overhead; workflow proceeds normally\r\n```\r\n\r\n---\r\n\r\n## Example Walkthrough: DDD Tactical Patterns\r\n\r\n**Step 1 — Workflow Start:**\r\nAI scans `extensions/` directory. Finds `ddd-tactical/ddd-tactical.opt-in.md`. Reads it (lightweight — just a question prompt and applicability criteria).\r\n\r\n**Step 2 — During Stage 12 (Component Design):**\r\nThe workflow presents the opt-in question:\r\n\r\n> \"Would you like to apply DDD Tactical Patterns?\r\n> This adds: Aggregate design rules, Domain Events catalog, Anti-Corruption Layers, Value Objects.\r\n> (a) Yes (b) No\"\r\n\r\n**Step 3a — User says Yes:**\r\n- AI loads `ddd-tactical/ddd-tactical.md` (the full rules file)\r\n- Those rules become **enforced constraints** for the current and remaining stages\r\n- Example rule: \"Every aggregate must define its consistency boundary explicitly\"\r\n- At stage completion, the AI verifies compliance and reports findings\r\n- Non-compliance is a blocking finding — stage cannot complete until resolved\r\n\r\n**Step 3b — User says No:**\r\n- `ddd-tactical.md` is NEVER loaded into context\r\n- No context/token budget consumed\r\n- Workflow proceeds with standard component design from core rules\r\n- No enforcement, no compliance check for DDD patterns\r\n\r\n---\r\n\r\n## Why This Design?\r\n\r\n| Benefit | Explanation |\r\n|---------|-------------|\r\n| **Context-efficient** | Only load heavy rule files when actually needed — saves AI context budget |\r\n| **Non-intrusive** | Core workflow works perfectly without any extensions activated |\r\n| **User-controlled** | User decides which advanced patterns to apply — never forced |\r\n| **Additive** | Extensions ADD rules on top of core workflow — never replace or conflict with core |\r\n| **Blocking when active** | Once opted in, extension rules are hard constraints — not optional suggestions |\r\n| **Composable** | Multiple extensions can be active simultaneously (DDD + Microservices + Resilience) |\r\n\r\n---\r\n\r\n## When Are Opt-In Questions Presented?\r\n\r\nExtensions are presented at the stage where their pattern becomes relevant:\r\n\r\n| Extension | Presented During | Why |\r\n|-----------|-----------------|-----|\r\n| Microservices | Stage 5 (Container Design) | Service decomposition is decided here |\r\n| BFF Pattern | Stage 5 (Container Design) | BFF is a container-level decision |\r\n| Resilience Patterns | Stage 5 or 11 (Integration/Infrastructure) | Resilience applies to distributed communication |\r\n| DDD Tactical | Stage 12 (Component Design) | DDD patterns apply to internal module structure |\r\n| Event Sourcing / CQRS | Stage 9 (Data Architecture) | Fundamentally changes data model approach |\r\n| Feature Flags | Stage 6 (Technology Stack) or Stage 12 | Architectural decision about delivery mechanism |\r\n\r\n---\r\n\r\n## What a Full Rules File Contains\r\n\r\nWhen activated, the rules file provides:\r\n\r\n1. **Activation point** — Which stage(s) the rules apply to\r\n2. **Rules** — Numbered, specific, verifiable constraints (e.g., \"DDD-01: Aggregate Boundary Definition\")\r\n3. **Verification criteria** — Checklist that must pass before stage can complete\r\n4. **ADR triggers** — Which decisions within the extension produce ADRs\r\n5. **Templates** — Any additional document templates the extension requires\r\n6. **Anti-patterns** — What NOT to do when applying this pattern\r\n\r\n### Example Rule Structure:\r\n\r\n```markdown\r\n### Rule {PREFIX}-{NN}: {Title}\r\n\r\n**Statement:** {What must be true — clear, testable}\r\n\r\n**Verification:**\r\n- [ ] {Check 1}\r\n- [ ] {Check 2}\r\n\r\n**Anti-Pattern:** {What to avoid}\r\n\r\n**ADR Trigger:** {Yes/No — does this rule generate an ADR?}\r\n```\r\n\r\n---\r\n\r\n## Enforcement Model\r\n\r\nOnce an extension is activated:\r\n\r\n| Behavior | Description |\r\n|----------|-------------|\r\n| **Rules are blocking** | Stage cannot complete if extension rules are violated |\r\n| **Compliance summary** | At each stage completion, extension compliance is reported |\r\n| **N/A is acceptable** | If a rule doesn't apply to the current stage, mark as N/A (not a violation) |\r\n| **Non-compliance = fix first** | If a rule IS applicable and not met → must be resolved before proceeding |\r\n| **Logged in state** | Enabled extensions are tracked in `adlc-state.md` |\r\n\r\n---\r\n\r\n## Multiple Extensions Active\r\n\r\nExtensions compose — they don't conflict:\r\n\r\n```\r\nActive Extensions:\r\n ✅ DDD Tactical (Stage 12 rules)\r\n ✅ Microservices (Stage 5, 11 rules)\r\n ✅ Resilience Patterns (Stage 11 rules)\r\n\r\nAt Stage 11 completion:\r\n - Core workflow checks: ✅ All pass\r\n - Microservices extension checks: ✅ Service mesh defined, distributed tracing designed\r\n - Resilience extension checks: ✅ Circuit breakers on all inter-service calls\r\n - DDD extension checks: N/A (applies to Stage 12, not 11)\r\n```\r\n\r\n---\r\n\r\n## Creating Your Own Extension\r\n\r\nTo create a custom extension:\r\n\r\n1. Create folder: `extensions/{your-pattern-name}/`\r\n2. Create opt-in file: `{your-pattern-name}.opt-in.md`\r\n - Include: when it applies, what it adds, the opt-in question\r\n3. Create rules file: `{your-pattern-name}.md`\r\n - Include: activation point, numbered rules, verification criteria, anti-patterns\r\n4. Keep it general — no project-specific content\r\n5. Rules should be verifiable (yes/no pass criteria)\r\n\r\n### Naming Convention\r\n\r\n- Folder name: `kebab-case` (e.g., `event-sourcing-cqrs`)\r\n- Opt-in file: `{folder-name}.opt-in.md`\r\n- Rules file: `{folder-name}.md`\r\n- Rule IDs: `{PREFIX}-{NN}` (e.g., `DDD-01`, `MS-03`, `RES-05`)\r\n\r\n---\r\n\r\n## Extension Status (v1.1)\r\n\r\nAll six high-priority extensions are **complete and enforceable**:\r\n\r\n| Extension | Rules File | Status |\r\n|-----------|-----------|:------:|\r\n| `ddd-tactical/` | `ddd-tactical.md` | ✅ Complete |\r\n| `microservices/` | `microservices.md` | ✅ Complete |\r\n| `bff-pattern/` | `bff-pattern.md` | ✅ Complete |\r\n| `event-sourcing-cqrs/` | `event-sourcing-cqrs.md` | ✅ Complete |\r\n| `resilience-patterns/` | `resilience-patterns.md` | ✅ Complete |\r\n| `feature-flags/` | `feature-flags.md` | ✅ Complete |\r\n\r\n**Behavior when user opts in:**\r\n- Full rules file is loaded\r\n- Structured enforcement is active (numbered rules, checklists, blocking verification)\r\n- ADR triggers produce formal Architecture Decision Records\r\n- Stage cannot complete if extension rules are violated\r\n\r\n---\r\n\r\n## FAQ\r\n\r\n| Question | Answer |\r\n|----------|--------|\r\n| Are extensions loaded automatically? | No — only opt-in prompts are scanned; full rules require explicit \"Yes\" |\r\n| What if I say yes but later want to disable? | Tell the AI: \"Disable {extension} extension\" — it updates state and stops enforcing |\r\n| Can I activate an extension mid-workflow? | Yes — say \"Enable {extension}\" at any point; rules apply from that point forward |\r\n| Do extensions add stages? | No — they add RULES to existing stages, not new stages |\r\n| Can extensions conflict with each other? | Designed not to. If conflict detected, AI flags it for user resolution |\r\n| Can I use AI-ADLC without any extensions? | Yes — core workflow is 100% functional standalone |\r\n| Who maintains extensions? | Community-contributed or self-authored; follow the structure above |\n\nFile v1.0.0:ai-adlc/README.md\n\n# AI-ADLC (AI-Driven Architecture Design Life Cycle)\r\n\r\n[![License: Apache 2.0](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](./LICENSE)\r\n\r\n**Version:** 1.1.0\r\n**Created By:** Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\r\n**Inspired By:** [awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows) (MIT-0)\r\n**License:** Apache 2.0 with Attribution Addendum — See `LICENSE` and `NOTICE`\r\n\r\n---\r\n\r\n## The AI-* PDLC Family\r\n\r\nAI-ADLC is part of **AIFLC** (AI Full Life Cycle) — the AI-* PDLC Family of injectable workflow packages.\r\n\r\n```\r\n╔════════════════ PORTFOLIO LAYER · scope = MANY projects ════════════════╗\r\n\r\n (optional)\r\n AI-ILC ⇢ AI-PILC ⇢ AI-PPM\r\n Decide it Initiate it Govern it (portfolio of N projects)\r\n\r\n╚═════════════════════════════════╤═══════════════════════════════════════╝\r\n │\r\n AI-FLO Route it — package-to-package\r\n │ flow on the edge between layers\r\n╔════════════════ PROJECT LAYER · scope = ONE project ════════════════════╗\r\n\r\n AI-POLC ──► AI-UXD ──► AI-ADLC ──► AI-DWG ──► AI-DLC v1 (build) ¹\r\n Own it Design UX Design it Prepare it ▲\r\n │\r\n AI-POLC ⇄ AI-DLC v1 (back-and-forth)┘\r\n AI-DLC v1 ⇢ AI-UXD+AI-POLC (feedback)\r\n\r\n AI-GCE + AI-TGE ──── alongside AI-DLC v1 (continuous quality) ────►\r\n Guard it Test it\r\n\r\n╚═════════════════════════════════════════════════════════════════════════╝\r\n ¹ AI-DLC v1 = Amazon's open-source build lifecycle (not ours; we feed it).\r\n```\r\n\r\n| Layer | Package | Type | Input | Output |\r\n|-------|---------|------|-------|--------|\r\n| Portfolio | **AI-ILC** ² | Interactive workflow (lifecycle) | Raw idea | Approved Idea Brief / Feature Brief |\r\n| Portfolio | **AI-PILC** | Interactive workflow (lifecycle) | Raw requirement | Project Initiation Package (PIP) |\r\n| Portfolio | **AI-PPM** ³ | Adaptive portfolio engine | Multiple PIPs + Approved Idea Briefs | Portfolio register + cross-project prioritization & governance |\r\n| Edge | **AI-FLO** ³ | Router / orchestration engine | Any package output marker | Routing decision + handoff to next package/layer |\r\n| Project | **AI-POLC** ³ | Interactive workflow (lifecycle) | PIP | Product Backlog Package (PBP) |\r\n| Project | **AI-UXD** ³ | Interactive workflow (lifecycle) | PIP + PBP | UX Design Package (UXP): personas/journeys, IA, user flows, design system + tokens, accessibility baseline |\r\n| Project | **AI-ADLC** | Interactive workflow (lifecycle) | PIP + PBP + UXP | Architecture Package (AP) |\r\n| Project | **AI-DWG** | One-time generator | AP + PBP + UXP | Ready-to-code development workspace (DW) |\r\n| Project | **AI-GCE** | Adaptive governance engine | DW (AI-DWG output) | Compliance enforcement layer |\r\n| Project | **AI-TGE** | Test governance engine | DW / build artifacts | Test governance & quality layer |\r\n| Project | **AI-DLC v1** ¹ | Interactive workflow (lifecycle) | DW + GCE + User Stories (from AI-POLC) | Working Software |\r\n\r\n> ¹ **AI-DLC v1** ([awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows)) is NOT our product. Our chain produces the workspace AI-DLC v1 consumes.\r\n> ² **AI-ILC** is an **optional pre-stage** (the funnel before the funnel). The chain still works without it for users who start at AI-PILC. `⇢` denotes the optional link.\r\n> ³ All packages in this table are **built**. AI-PPM (portfolio engine), AI-FLO (router), AI-POLC (product ownership lifecycle), and AI-UXD (UX design lifecycle) were the last four — completed June 2026. Within the Project layer, **AI-POLC, AI-UXD, and AI-ADLC run sequentially** (POLC→UXD→ADLC) — each feeds the next, culminating at AI-DWG which receives all three outputs (AP + PBP + UXP). **AI-GCE and AI-TGE run alongside AI-DLC v1** as continuous quality engines; **AI-POLC ⇄ AI-DLC v1** exchange backlog/acceptance throughout delivery; and **AI-DLC v1 runtime feedback flows back to both AI-UXD and AI-POLC**. Feedback loops (ADLC→POLC cost/risk, ADLC→UXD constraints) provide iterative refinement without changing the forward sequence.\r\n\r\n> **AI-DFE** ([Data Fabric Engine](../ai-dfe/)) is a family-scoped **companion** — it gathers data from all packages and distributes structured JSON for dashboards and status roll-ups. It runs alongside the chain rather than as a linear step, so it is not shown as a chain row above.\r\n\r\n---\r\n\r\n## What is AI-ADLC?\r\n\r\nAI-ADLC is an injectable workflow that guides an AI assistant (acting as CTO/Chief Architect) and a human user through the complete process of designing a solution architecture — from receiving project requirements to delivering a professional, development-ready Architecture Package.\r\n\r\nIt is general-purpose, reusable, and contains zero project-specific content. Drop it into any workspace, point it at requirements, and it walks you through 5 phases and 13 stages of structured architecture design.\r\n\r\n---\r\n\r\n## Key Features\r\n\r\n| Feature | Description |\r\n|---------|-------------|\r\n| **CTO Perspective** | AI acts as an experienced Chief Architect — pragmatic, team-aware, constraint-respectful |\r\n| **Adaptive Intake** | Handles full PIP, raw PRD, verbal description, or brownfield extension |\r\n| **ADR-Driven** | Every major decision produces a formal Architecture Decision Record |\r\n| **C4 Model** | Progressive decomposition: System Context → Containers → Components |\r\n| **Constraint-Aware** | Never recommends outside stated boundaries |\r\n| **Resumable** | State file enables multi-session architecture work |\r\n| **Platform-Agnostic** | Works with Kiro, Q Developer, Cursor, Cline, Claude Code, Copilot |\r\n\r\n---\r\n\r\n## What It Produces\r\n\r\nA complete Architecture Package containing:\r\n\r\n- Architecture Vision & Principles\r\n- System Context Diagram (C4 Level 1)\r\n- Container Diagram (C4 Level 2)\r\n- Technology Stack Document (with ADRs)\r\n- Multi-Tenancy Architecture (if applicable)\r\n- Security & Identity Architecture\r\n- Data Architecture & Schema Strategy\r\n- API Architecture & Contracts\r\n- Integration Architecture\r\n- Infrastructure & Deployment Architecture\r\n- Component Design (C4 Level 3)\r\n- Architecture Decision Records (ADR-001, ADR-002, ...)\r\n- Architecture Workbook\r\n- Package README (summary and reading guide)\r\n\r\n---\r\n\r\n## The Five Phases\r\n\r\n```\r\n🔵 FOUNDATION → Load context, assess complexity, define vision & principles\r\n🟠 DECOMPOSITION → Define system boundaries, containers (C4 L1 + L2)\r\n🟡 DECISIONS → Select technology, isolation patterns, security model\r\n🟢 DESIGN → Detail data, API, integrations, infrastructure, components (C4 L3)\r\n🚀 ASSEMBLY → Consolidate, cross-check, produce final package\r\n```\r\n\r\n---\r\n\r\n## Activation\r\n\r\n**Explicit key:** type `_ADLC_` in any prompt to activate AI-ADLC unambiguously — even when other AI-* packages share the workspace. The status key `_ACTIVE_` reports which package is currently active. A package switch never happens without your explicit key or confirmation, and any switch is announced on the first line of the response (`Active package: AI-ADLC`). See [`../TRIGGER_KEYS_REFERENCE.md`](../TRIGGER_KEYS_REFERENCE.md) for the full family key table.\r\n\r\n---\r\n\r\n## Installation\r\n\r\n1. Download or clone this repository\r\n2. The package contains two key directories:\r\n - `ai-adlc-rules/` — the core workflow (always loaded by the AI)\r\n - `ai-adlc-rule-details/` — stage details, extensions, and templates (loaded on demand)\r\n3. Follow the platform-specific instructions in [setup/INSTALL.md](./setup/INSTALL.md)\r\n\r\n---\r\n\r\n## Output Directory Structure\r\n\r\nAI-ADLC outputs into the standard multi-project layout. Architecture artifacts land in `architecture/` within the project folder:\r\n\r\n```\r\npdlc-ws/projects/\r\n├── PROJECTS.md ← workspace registry\r\n└── PRJ-{ABBREV}-{slug}/ ← one project\r\n ├── management_framework/ ← shared governance spine\r\n └── architecture/ ← AI-ADLC output\r\n ├── adlc-state.md ← progress marker\r\n ├── architecture-vision.md\r\n ├── system-context.md\r\n ├── container-diagram.md\r\n ├── technology-stack.md\r\n ├── security-architecture.md\r\n ├── data-architecture.md\r\n ├── api-architecture.md\r\n ├── integration-architecture.md\r\n ├── component-design.md\r\n ├── architecture-workbook.md\r\n ├── ADR-001.md … ADR-NNN.md\r\n └── AP_README.md\r\n```\r\n\r\n> The `projects/` structure is always-on — solo, single-project, and multi-project alike. See `OUTPUT_AND_STATE_CONTRACT.md` for full details.\r\n\r\n---\r\n\r\n## Usage\r\n\r\n1. Open your workspace with the AI assistant active\r\n2. Start a chat:\r\n ```\r\n Using AI-ADLC, design the architecture for this system: [provide source]\r\n ```\r\n3. The workflow activates and guides you through progressive design\r\n4. Approve each stage's output at gates\r\n5. All artifacts are produced in your configured output folder\r\n\r\n---\r\n\r\n## File Structure\r\n\r\n```\r\nai-adlc/\r\n├── README.md\r\n├── LICENSE\r\n├── ROADMAP.md\r\n├── ai-adlc-rules/\r\n│ └── core-workflow.md\r\n└── ai-adlc-rule-details/\r\n ├── common/\r\n │ ├── process-overview.md\r\n │ ├── session-continuity.md\r\n │ ├── question-format-guide.md\r\n │ ├── content-validation.md\r\n │ ├── diagram-standards.md\r\n │ └── welcome-message.md\r\n ├── foundation/\r\n │ ├── workspace-detection.md\r\n │ ├── requirements-ingestion.md\r\n │ └── architecture-vision.md\r\n ├── decomposition/\r\n │ ├── system-context.md\r\n │ └── container-design.md\r\n ├── decisions/\r\n │ ├── technology-stack.md\r\n │ ├── multi-tenancy.md\r\n │ └── security-identity.md\r\n ├── design/\r\n │ ├── data-architecture.md\r\n │ ├── api-architecture.md\r\n │ ├── integration-infrastructure.md\r\n │ └── component-design.md\r\n ├── assembly/\r\n │ └── package-assembly.md\r\n ├── extensions/\r\n │ ├── README.md\r\n │ ├── ddd-tactical/\r\n │ │ ├── ddd-tactical.opt-in.md\r\n │ │ └── ddd-tactical.md\r\n │ ├── microservices/\r\n │ │ ├── microservices.opt-in.md\r\n │ │ └── microservices.md\r\n │ ├── bff-pattern/\r\n │ │ ├── bff-pattern.opt-in.md\r\n │ │ └── bff-pattern.md\r\n │ ├── event-sourcing-cqrs/\r\n │ │ ├── event-sourcing-cqrs.opt-in.md\r\n │ │ └── event-sourcing-cqrs.md\r\n │ ├── resilience-patterns/\r\n │ │ ├── resilience-patterns.opt-in.md\r\n │ │ └── resilience-patterns.md\r\n │ └── feature-flags/\r\n │ ├── feature-flags.opt-in.md\r\n │ └── feature-flags.md\r\n └── templates/\r\n ├── adr-template.md\r\n ├── architecture-vision.md\r\n ├── system-context.md\r\n ├── container-diagram.md\r\n ├── technology-stack.md\r\n ├── security-architecture.md\r\n ├── data-architecture.md\r\n ├── api-architecture.md\r\n ├── integration-architecture.md\r\n ├── component-design.md\r\n ├── multi-tenancy.md\r\n └── architecture-workbook.md\r\n```\r\n\r\n---\r\n\r\n## Tenets\r\n\r\n1. **CTO pragmatism** — Proven patterns over novel experiments; team-aware recommendations\r\n2. **Decision transparency** — Every major choice has a recorded ADR with alternatives analysis\r\n3. **Progressive detail** — C4 L1 → L2 → L3; never detail internals before boundaries are set\r\n4. **Constraint-first** — Never recommend outside stated boundaries, no matter how \"better\" it seems\r\n5. **Adaptive** — Scale rigor to complexity; don't over-architect simple systems\r\n6. **Resumable** — Multi-session work with full state preservation\r\n7. **Agnostic** — Works with any IDE, agent, or model\r\n\r\n---\r\n\r\n## Extensions (v1.1 — Delivered)\r\n\r\nAI-ADLC supports an extension system for advanced architectural patterns. Extensions activate via opt-in during the workflow when your system needs them. Once activated, extension rules are blocking constraints — enforced and verified at stage completion.\r\n\r\n### Available Extensions (v1.1 — Complete)\r\n\r\n| Extension | Pattern | Rules | When Needed |\r\n|-----------|---------|:-----:|-------------|\r\n| `ddd-tactical/` | DDD Tactical Patterns | DDD-01 → DDD-12 | Complex domain logic with aggregates, domain events, ACLs |\r\n| `microservices/` | Microservices Deep-Dive | MS-01 → MS-12 | Service mesh, distributed tracing, saga patterns |\r\n| `bff-pattern/` | Backend-for-Frontend | BFF-01 → BFF-10 | Multiple client types needing different API shapes |\r\n| `event-sourcing-cqrs/` | Event Sourcing + CQRS | ES-01 → ES-12 | Full audit trail, temporal queries, event-driven state |\r\n| `resilience-patterns/` | Resilience Catalog | RES-01 → RES-12 | Circuit breaker, bulkhead, graceful degradation |\r\n| `feature-flags/` | Feature Flags & Progressive Delivery | FF-01 → FF-11 | Controlled rollout, A/B testing, kill switches |\r\n\r\nEach extension provides: numbered rules with verification criteria, anti-patterns, ADR triggers, stage-completion checklists, and reusable templates.\r\n\r\n### Future Extensions (see ROADMAP.md)\r\n\r\nServerless, AI/ML Integration, Micro-Frontends, GraphQL Federation, Multi-Region, Zero Trust, Kubernetes-Native, Edge Computing, Data Mesh, Chaos Engineering, and more.\r\n\r\n---\r\n\r\n## Author\r\n\r\nCreated by **Maheri** — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\r\n\r\nDesigned from real-world CTO architecture practice, combining structured design methodology with AI-driven interactive workflows.\r\n\r\n---\r\n\r\n## License\r\n\r\n**Apache License 2.0 with Attribution Addendum**\r\n\r\n- **Free to use:** Personal, commercial, educational, and organizational use — all permitted\r\n- **Modify and distribute:** Create derivative works, redistribute, sublicense — all permitted\r\n- **Attribution required:** Any distributed product substantially based on this work must include:\r\n\r\n> *\"Built on AIFLC by Mohammad Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\"*\r\n\r\n- **No warranty:** Provided \"AS IS\" without warranties of any kind\r\n\r\nSee `LICENSE` and `NOTICE` in this directory for full terms.\r\n\r\n**Copyright:** © 2026 Mohammad Maheri\r\n\r\n> **Note:** AI-DLC v1 (Development Life Cycle) is NOT part of the AI-* Family — it is a separate AWS product ([awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows)) licensed under MIT-0.\r\n\r\n---\r\n\r\n*Part of [AIFLC](../README.md) — the AI-* PDLC Family*\n\nFile v1.0.0:ai-dfe/README.md\n\n# AI-DFE — AI-Driven Data Fabric\r\n\r\n[![License: Apache 2.0](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](./LICENSE)\r\n\r\n**Version:** 1.0.0\r\n**Created By:** Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\r\n**License:** Apache 2.0 with Attribution\r\n\r\n---\r\n\r\n## What Is AI-DFE?\r\n\r\nAI-DFE is the data layer of the AI-* PDLC Family. It gathers the scattered markdown outputs every package produces, shapes them into structured JSON per consumer needs, and distributes them to one read-point — so dashboards, extensions, and reports get clean, machine-readable data without ever knowing where the raw files live.\r\n\r\n**In one sentence:** AI-DFE turns the family's scattered, human-readable outputs into a single governed, machine-readable data surface — gather, shape, distribute.\r\n\r\n**Tagline:** *Fabric it.*\r\n\r\n---\r\n\r\n## Family Position\r\n\r\nAI-DFE is part of **AIFLC** (AI Full Life Cycle) and the **AI-* PDLC Family**. Like AI-FLO, it lives in **every family** as a continuous adaptive engine — but where FLO routes decisions, DFE fabrics data. It owns one folder, `pdlc-ws/data/`, and is its sole writer.\r\n\r\n```\r\n╔════════════════ PORTFOLIO LAYER · scope = MANY projects ════════════════╗\r\n\r\n (optional)\r\n AI-ILC ⇢ AI-PILC ⇢ AI-PPM\r\n Decide it Initiate it Govern it (portfolio of N projects)\r\n\r\n╚═════════════════════════════════╤═══════════════════════════════════════╝\r\n │\r\n AI-FLO Route it — package-to-package\r\n │ flow on the edge between layers\r\n╔════════════════ PROJECT LAYER · scope = ONE project ════════════════════╗\r\n\r\n AI-POLC ──► AI-UXD ──► AI-ADLC ──► AI-DWG ──► AI-DLC v1 (build) ¹\r\n Own it Design UX Design it Prepare it ▲\r\n │\r\n AI-POLC ⇄ AI-DLC v1 (back-and-forth)┘\r\n AI-DLC v1 ⇢ AI-UXD+AI-POLC (feedback)\r\n\r\n AI-GCE + AI-TGE ──── alongside AI-DLC v1 (continuous quality) ────►\r\n Guard it Test it\r\n\r\n╚═════════════════════════════════════════════════════════════════════════╝\r\n ¹ AI-DLC v1 = Amazon's open-source build lifecycle (not ours; we feed it).\r\n```\r\n\r\n| Layer | Package | Type | Input | Output |\r\n|-------|---------|------|-------|--------|\r\n| Portfolio | **AI-ILC** ² | Interactive workflow (lifecycle) | Raw idea | Approved Idea Brief / Feature Brief |\r\n| Portfolio | **AI-PILC** | Interactive workflow (lifecycle) | Raw requirement | Project Initiation Package (PIP) |\r\n| Portfolio | **AI-PPM** ³ | Adaptive portfolio engine | Multiple PIPs + Approved Idea Briefs | Portfolio register + cross-project prioritization & governance |\r\n| Edge | **AI-FLO** ³ | Router / orchestration engine | Any package output marker | Routing decision + handoff to next package/layer |\r\n| Project | **AI-POLC** ³ | Interactive workflow (lifecycle) | PIP | Product Backlog Package (PBP) |\r\n| Project | **AI-UXD** ³ | Interactive workflow (lifecycle) | PIP + PBP | UX Design Package (UXP): personas/journeys, IA, user flows, design system + tokens, accessibility baseline |\r\n| Project | **AI-ADLC** | Interactive workflow (lifecycle) | PIP + PBP + UXP | Architecture Package (AP) |\r\n| Project | **AI-DWG** | One-time generator | AP + PBP + UXP | Ready-to-code development workspace (DW) |\r\n| Project | **AI-GCE** | Adaptive governance engine | DW (AI-DWG output) | Compliance enforcement layer |\r\n| Project | **AI-TGE** | Test governance engine | DW / build artifacts | Test governance & quality layer |\r\n| Project | **AI-DLC v1** ¹ | Interactive workflow (lifecycle) | DW + GCE + User Stories (from AI-POLC) | Working Software |\r\n\r\n> ¹ **AI-DLC v1** ([awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows)) is NOT our product. Our chain produces the workspace AI-DLC v1 consumes.\r\n> ² **AI-ILC** is an **optional pre-stage** (the funnel before the funnel). The chain still works without it for users who start at AI-PILC. `⇢` denotes the optional link.\r\n> ³ All packages in this table are **built**. AI-PPM (portfolio engine), AI-FLO (router), AI-POLC (product ownership lifecycle), and AI-UXD (UX design lifecycle) were the last four — completed June 2026. Within the Project layer, **AI-POLC, AI-UXD, and AI-ADLC run sequentially** (POLC→UXD→ADLC) — each feeds the next, culminating at AI-DWG which receives all three outputs (AP + PBP + UXP). **AI-GCE and AI-TGE run alongside AI-DLC v1** as continuous quality engines; **AI-POLC ⇄ AI-DLC v1** exchange backlog/acceptance throughout delivery; and **AI-DLC v1 runtime feedback flows back to both AI-UXD and AI-POLC**. Feedback loops (ADLC→POLC cost/risk, ADLC→UXD constraints) provide iterative refinement without changing the forward sequence.\r\n\r\n> **Note on AI-DFE's table row:** AI-DFE is a continuous data-fabric engine that operates *alongside* the whole family (like AI-FLO, it is not a chain link). Its formal row is added to the canonical family table during family-governance integration; the diagram and table above are reproduced verbatim from the family canonical (`FAMILY_TABLE_MAP.md`) and are never improvised.\r\n\r\n---\r\n\r\n## Features\r\n\r\n- **3 phases** — Configure (discover) → Operate (gather, shape, distribute, monitor) → Govern (validate, freshness, history, cleanup)\r\n- **Two-layer pipeline** — sources → per-package JSON (Layer 1) → demand-shaped consumer output (Layer 2)\r\n- **Single-writer territory** — DFE is the sole owner and sole writer of `pdlc-ws/data/`\r\n- **Discover-once, monitor-continuously** — reads each package's interface once, then only checks timestamps\r\n- **Consumer decoupling** — consumers declare a DEMAND; they never touch raw source files\r\n- **REGISTRY.json discovery** — every consumer reads ONE fixed path to find all its data\r\n- **Schema-first** — every data file validates against a JSON Schema (per-package + DFE-owned aggregations)\r\n- **Historical snapshots** — millisecond-timestamped history with retention + cleanup\r\n- **Graceful degradation** — a missing source becomes a `null` field, never an error\r\n- **Multi-family ready** — single-active master mode for operating several families' data from one seat (deferred until a 2nd family exists)\r\n- **`DAT__` operations trigger** — gather/shape/distribute/discover/aggregate/cleanup/master\r\n- **`DHC__` data-fabric health check** — bootstrap readiness check (\"can DFE operate in this workspace?\"); the data-layer analogue of AI-FLO's `FHC__`. Run it first. Read-only.\r\n- **`DFA__` data-fabric integrity agent** — standalone integrity pass, 18 checks across 5 categories (schema / registry / manifest / freshness / territory); the data-layer analogue of AI-FLO's `FIA__`. Reports, never writes.\r\n- **Hook-free governance** — convention + sole-writer ownership + agent, no IDE hooks\r\n\r\n---\r\n\r\n## Activation\r\n\r\n**Explicit key:** type `_DFE_` in any prompt to activate AI-DFE unambiguously — even when other AI-* packages share the workspace. The status key `_ACTIVE_` reports which package is currently active. A package switch never happens without your explicit key or confirmation, and any switch is announced on the first line of the response (`Active package: AI-DFE`). See [`../TRIGGER_KEYS_REFERENCE.md`](../TRIGGER_KEYS_REFERENCE.md) for the full family key table.\r\n\r\n**Operations:** `DAT__` runs data operations (e.g. `DAT__ all`, `DAT__ pdlc/pilc`, `DAT__ status`). **Quality:** `DFA__` runs the data-fabric quality agent (report-only).\r\n\r\n---\r\n\r\n## Installation\r\n\r\nSee `setup/INSTALL.md` for full multi-platform installation instructions.\r\n\r\n**Quick start (Kiro):**\r\n1. Copy `ai-dfe-rules/` and `ai-dfe-rule-details/` into the uniform home `.aiflc/pdlc/`\r\n2. Copy `session-orchestrator.md` into `.kiro/steering/` (the only always-loaded file; it `Read`s the core on demand)\r\n3. The installer bootstraps an empty `pdlc-ws/data/`; run `DAT__ all` to populate it.\r\n\r\n---\r\n\r\n## Usage\r\n\r\n1. Open a workspace where AI-* packages have produced output\r\n2. Start a chat and run the data trigger:\r\n ```\r\n DAT__ all\r\n ```\r\n3. AI-DFE gathers data from every installed package, shapes it per consumer demands, and distributes structured JSON to `{family}-ws/data/`\r\n4. Use `DAT__ full` for a complete-set pass with a readiness report, `DAT__ status` for a staleness check, or `DFA__` for a report-only quality assessment\r\n5. Consumers (e.g. the dashboard) read the data via `REGISTRY.json`\r\n\r\n## File Structure\r\n\r\n```\r\nai-dfe/\r\n├── README.md ← This file\r\n├── LICENSE · NOTICE ← Apache 2.0 + Attribution\r\n├── PLAN.md · CONCEPTUAL_MAP.md ← rationale + navigation\r\n├── USER_GUIDE.md · WHITEPAPER.md ← walkthrough + design narrative\r\n├── ai-dfe-rules/\r\n│ └── core-engine.md ← Master orchestration (THE spec) + § Gate Contract\r\n├── ai-dfe-rule-details/\r\n│ ├── common/ ← process-overview, session-continuity\r\n│ ├── configure/ ← Phase 1: family / package / demand discovery\r\n│ ├── operate/ ← Phase 2: gather, shape, distribute, monitor, cross-project, cross-family\r\n│ ├── govern/ ← Phase 3: validation, freshness, history, cleanup\r\n│ ├── data-schema/ ← DFE's own data interface (reports on itself)\r\n│ └── templates/ ← dfe-state, DATA_INTERFACES, SOURCE_MAP, demand, data-samples/, agents/\r\n└── setup/\r\n └── INSTALL.md ← multi-platform install\r\n```\r\n\r\n---\r\n\r\n## Tenets\r\n\r\n1. **Generated, not hand-edited** — everything in `data/` is tool-produced.\r\n2. **Single-writer** — only DFE writes to `data/`; any consumer may read.\r\n3. **Schema-first** — no data file without a schema.\r\n4. **Consumers are decoupled** — they declare a DEMAND and read the registry; they never reach into source files.\r\n5. **Family-scoped** — each family owns its own `data/`; cross-family exchange reads the neighbour's data, never mixes.\r\n6. **Graceful degradation** — incomplete is allowed; broken is not.\r\n\r\n---\r\n\r\n## License\r\n\r\n**Apache License 2.0 with Attribution Addendum**\r\n\r\n- **Free to use:** Personal, commercial, educational, and organizational use — all permitted\r\n- **Modify and distribute:** Create derivative works, redistribute, sublicense — all permitted\r\n- **Attribution required:** Any distributed product substantially based on this work must include:\r\n\r\n> *\"Built on AIFLC by Mohammad Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\"*\r\n\r\n- **No warranty:** Provided \"AS IS\" without warranties of any kind\r\n\r\nSee `LICENSE` and `NOTICE` in this directory for full terms.\r\n\r\n**Copyright:** © 2026 Mohammad Maheri\r\n\r\n> **Note:** AI-DLC v1 (Development Life Cycle) is NOT part of the AI-* Family — it is a separate AWS product ([awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows)) licensed under MIT-0.\r\n\r\n---\r\n\r\n## Author\r\n\r\n**Maheri** — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\r\n\r\nAI-DFE is part of **AIFLC** (AI Full Life Cycle), a family of injectable AI workflow packages. Built on AIFLC by Mohammad Maheri.\n\nFile v1.0.0:ai-dwg/ai-dwg-rule-details/templates/examples/README.md\n\n\r\n---\r\ngeneratedBy: AI-DWG\r\ngeneratedVersion: \"{version}\"\r\nsource: \"AI-ADLC AP (tech patterns) + AI-UXD UXP (UI component patterns)\"\r\ngeneratedOn: \"{generation-date}\"\r\nownership: hybrid\r\n---\r\n# Template: examples/ Directory (SKELETON)\r\n\r\n**Generate IF:** At least one peer input is present (any valid input set).\r\n**Cluster:** Cross-cluster (tech patterns from ADLC, UI patterns from UXD)\r\n**Purpose:** Provide AI-DLC v1 and developers with copy-paste starter patterns that demonstrate the correct way to implement common code patterns in this workspace. Seeded from architecture decisions (ADLC) and design system components (UXD).\r\n\r\n## Directory Structure\r\n\r\n```\r\n{workspace-root}/examples/\r\n├── README.md ← This file (index + usage guide)\r\n├── api-endpoint.{ext} ← IF ADLC: REST endpoint boilerplate\r\n├── database-query.{ext} ← IF ADLC: Query pattern (ORM/raw)\r\n├── service-layer.{ext} ← IF ADLC: Service/use-case pattern\r\n├── error-handling.{ext} ← IF ADLC: Error pattern\r\n├── test-unit.{ext} ← IF ADLC: Unit test pattern\r\n├── test-integration.{ext} ← IF ADLC: Integration test pattern\r\n└── ui-component.{ext} ← IF UXD: Component using design system tokens\r\n```\r\n\r\n## Template: examples/README.md\r\n\r\n```markdown\r\n\r\n\r\n# Code Examples\r\n\r\nStarter patterns demonstrating the correct implementation approach for this workspace. These examples are **prescriptive** — they show the ONE correct way, not alternatives.\r\n\r\n## How to Use\r\n\r\n1. Find the pattern closest to what you're building\r\n2. Copy the file as a starting point\r\n3. Replace placeholders with your implementation\r\n4. Follow the inline comments for guidance\r\n\r\n## Available Patterns\r\n\r\n| Pattern | File | Source | When to Use |\r\n|---------|------|--------|-------------|\r\n| API Endpoint | `api-endpoint.{ext}` | AP: API Architecture + Tech Stack | New REST/GraphQL endpoint |\r\n| Database Query | `database-query.{ext}` | AP: Data Architecture + Tech Stack | New data access method |\r\n| Service Layer | `service-layer.{ext}` | AP: Component Design patterns | New business logic unit |\r\n| Error Handling | `error-handling.{ext}` | AP: Error patterns + API standards | Custom error scenarios |\r\n| Unit Test | `test-unit.{ext}` | AP: Testing strategy + Tech Stack | New unit under test |\r\n| Integration Test | `test-integration.{ext}` | AP: Testing strategy | New integration scenario |\r\n| UI Component | `ui-component.{ext}` | UXP: Design System + Component Inventory | New frontend component |\r\n\r\n## Rules\r\n\r\n- MUST follow these patterns — don't invent new approaches\r\n- MUST use the project's design tokens (see `design-system.md`) for UI components\r\n- MUST follow naming conventions (see `naming-conventions.md`)\r\n- Patterns are kept in sync with steering files during reconciliation\r\n```\r\n\r\n## Template: examples/ui-component.{ext} (UXD-Seeded)\r\n\r\n**Generate IF:** `uxd-state.md` present.\r\n**Extension:** Determined by AP Technology Stack (`.tsx`, `.vue`, `.svelte`, etc.)\r\n\r\n```markdown\r\n\r\n```\r\n\r\n```{ext}\r\n/**\r\n * Example: UI Component using Design System tokens\r\n * \r\n * This pattern demonstrates:\r\n * - Using design tokens (NEVER hardcode values)\r\n * - Following component structure from design-system.md\r\n * - Implementing all required states (loading, error, empty)\r\n * - Accessibility compliance (keyboard nav, ARIA, focus)\r\n * - Responsive behavior\r\n *\r\n * Source: AI-UXD Component Inventory → DS-CMP-NN\r\n * Tokens: See rules/design-system.md\r\n */\r\n\r\n// Token usage — ALWAYS reference tokens, NEVER hardcode\r\n// color: var(--color-primary) ← DS-COL-01\r\n// spacing: var(--space-md) ← DS-SPC-04\r\n// font: var(--font-family-primary) ← DS-TYP-01\r\n// shadow: var(--shadow-sm) ← DS-ELEV-01\r\n// duration: var(--duration-normal) ← DS-MOT-02\r\n\r\n// Component states — ALL MUST be handled:\r\n// - default: normal rendering\r\n// - loading: show skeleton (DS-INT-01)\r\n// - empty: show illustration + message + CTA (DS-INT-02)\r\n// - error: show error message with retry (DS-INT-03)\r\n// - disabled: reduced opacity, no interaction\r\n\r\n// Accessibility requirements (DS-A11Y):\r\n// - Keyboard navigable (tab + enter/space)\r\n// - ARIA labels for non-text content\r\n// - Focus visible (3:1 contrast min)\r\n// - Motion respects prefers-reduced-motion\r\n// - Touch target ≥44×44px\r\n\r\n// {Framework-specific implementation pattern here}\r\n// Placeholder — filled from AP Technology Stack at generation time\r\n```\r\n\r\n## Template: examples/api-endpoint.{ext} (ADLC-Seeded)\r\n\r\n**Generate IF:** `adlc-state.md` present.\r\n**Extension:** Determined by AP Technology Stack.\r\n\r\n```{ext}\r\n/**\r\n * Example: API Endpoint following workspace standards\r\n *\r\n * This pattern demonstrates:\r\n * - URL naming (kebab-case per api-standards.md)\r\n * - Request validation\r\n * - Error response format (per api-standards.md)\r\n * - Authentication/authorization check\r\n * - Response envelope format\r\n *\r\n * Source: AI-ADLC API Architecture + Security Architecture\r\n */\r\n\r\n// {Framework-specific implementation pattern here}\r\n// Placeholder — filled from AP Technology Stack at generation time\r\n```\r\n\r\n## Filling Instructions\r\n\r\n| Example File | Primary Source | Key Rules to Follow |\r\n|---|---|---|\r\n| `api-endpoint` | AP API Architecture + Technology Stack | `api-standards.md` rules |\r\n| `database-query` | AP Data Architecture + Technology Stack | `database-rules.md` rules |\r\n| `service-layer` | AP Component Design + Technology Stack | `module-structure.md` rules |\r\n| `error-handling` | AP Error patterns + API standards | `error-handling.md` rules |\r\n| `test-unit` | AP Testing strategy + Technology Stack | `testing-strategy.md` rules |\r\n| `test-integration` | AP Testing strategy + Technology Stack | `testing-strategy.md` rules |\r\n| `ui-component` | UXP Design System + Component Inventory | `design-system.md` + `frontend-standards.md` |\r\n\r\n### Key Principles\r\n\r\n1. **Examples are prescriptive.** They show THE correct approach — not one of several alternatives.\r\n2. **Technology-specific.** File extensions and patterns match the actual tech stack. Generic fallback only for unlisted stacks.\r\n3. **Token-first for UI.** The `ui-component` example MUST demonstrate token usage, not hardcoded values.\r\n4. **Reconciliation-aware.** Examples update when architecture changes (Mode 2).\r\n5. **Not runnable as-is.** They're patterns/templates, not complete applications. Commented placeholders for project-specific values.\n\nFile v1.0.0:ai-dwg/README.md\n\n# AI-DWG — AI-Driven Workspace Generator\r\n\r\n[![License: Apache 2.0](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](./LICENSE)\r\n\r\n**Version:** 1.0.0\r\n\r\n**Transform architecture into a ready-to-code development workspace.**\r\n\r\n---\r\n\r\n## What It Does\r\n\r\nAI-DWG composes a complete development workspace from one or more design-time peer inputs — Architecture Package (from AI-ADLC), Product Backlog Package (from AI-POLC), and/or UX Design Package (from AI-UXD). Any non-empty combination is valid; none is privileged. It generates Kiro steering files, project instructions, repository structure, configuration files, and operational documents — scoped to the input clusters actually present.\r\n\r\n**Input:** Any non-empty subset of {Architecture Package (AI-ADLC), Product Backlog Package (AI-POLC), UX Design Package (AI-UXD)} — all structured markdown documents. At least one is required; the more you provide, the richer the workspace.\r\n**Output:** Ready-to-code workspace with governance, structure, and rules\r\n\r\n---\r\n\r\n## The AI-* PDLC Family\r\n\r\nAI-DWG is part of **AIFLC** (AI Full Life Cycle) — the AI-* PDLC Family of injectable workflow packages.\r\n\r\n```\r\n╔════════════════ PORTFOLIO LAYER · scope = MANY projects ════════════════╗\r\n\r\n (optional)\r\n AI-ILC ⇢ AI-PILC ⇢ AI-PPM\r\n Decide it Initiate it Govern it (portfolio of N projects)\r\n\r\n╚═════════════════════════════════╤═══════════════════════════════════════╝\r\n │\r\n AI-FLO Route it — package-to-package\r\n │ flow on the edge between layers\r\n╔════════════════ PROJECT LAYER · scope = ONE project ════════════════════╗\r\n\r\n AI-POLC ──► AI-UXD ──► AI-ADLC ──► AI-DWG ──► AI-DLC v1 (build) ¹\r\n Own it Design UX Design it Prepare it ▲\r\n │\r\n AI-POLC ⇄ AI-DLC v1 (back-and-forth)┘\r\n AI-DLC v1 ⇢ AI-UXD+AI-POLC (feedback)\r\n\r\n AI-GCE + AI-TGE ──── alongside AI-DLC v1 (continuous quality) ────►\r\n Guard it Test it\r\n\r\n╚═════════════════════════════════════════════════════════════════════════╝\r\n ¹ AI-DLC v1 = Amazon's open-source build lifecycle (not ours; we feed it).\r\n```\r\n\r\n| Layer | Package | Type | Input | Output |\r\n|-------|---------|------|-------|--------|\r\n| Portfolio | **AI-ILC** ² | Interactive workflow (lifecycle) | Raw idea | Approved Idea Brief / Feature Brief |\r\n| Portfolio | **AI-PILC** | Interactive workflow (lifecycle) | Raw requirement | Project Initiation Package (PIP) |\r\n| Portfolio | **AI-PPM** ³ | Adaptive portfolio engine | Multiple PIPs + Approved Idea Briefs | Portfolio register + cross-project prioritization & governance |\r\n| Edge | **AI-FLO** ³ | Router / orchestration engine | Any package output marker | Routing decision + handoff to next package/layer |\r\n| Project | **AI-POLC** ³ | Interactive workflow (lifecycle) | PIP | Product Backlog Package (PBP) |\r\n| Project | **AI-UXD** ³ | Interactive workflow (lifecycle) | PIP + PBP | UX Design Package (UXP): personas/journeys, IA, user flows, design system + tokens, accessibility baseline |\r\n| Project | **AI-ADLC** | Interactive workflow (lifecycle) | PIP + PBP + UXP | Architecture Package (AP) |\r\n| Project | **AI-DWG** | One-time generator | AP + PBP + UXP | Ready-to-code development workspace (DW) |\r\n| Project | **AI-GCE** | Adaptive governance engine | DW (AI-DWG output) | Compliance enforcement layer |\r\n| Project | **AI-TGE** | Test governance engine | DW / build artifacts | Test governance & quality layer |\r\n| Project | **AI-DLC v1** ¹ | Interactive workflow (lifecycle) | DW + GCE + User Stories (from AI-POLC) | Working Software |\r\n\r\n> ¹ **AI-DLC v1** ([awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows)) is NOT our product. Our chain produces the workspace AI-DLC v1 consumes.\r\n> ² **AI-ILC** is an **optional pre-stage** (the funnel before the funnel). The chain still works without it for users who start at AI-PILC. `⇢` denotes the optional link.\r\n> ³ All packages in this table are **built**. AI-PPM (portfolio engine), AI-FLO (router), AI-POLC (product ownership lifecycle), and AI-UXD (UX design lifecycle) were the last four — completed June 2026. Within the Project layer, **AI-POLC, AI-UXD, and AI-ADLC run sequentially** (POLC→UXD→ADLC) — each feeds the next, culminating at AI-DWG which receives all three outputs (AP + PBP + UXP). **AI-GCE and AI-TGE run alongside AI-DLC v1** as continuous quality engines; **AI-POLC ⇄ AI-DLC v1** exchange backlog/acceptance throughout delivery; and **AI-DLC v1 runtime feedback flows back to both AI-UXD and AI-POLC**. Feedback loops (ADLC→POLC cost/risk, ADLC→UXD constraints) provide iterative refinement without changing the forward sequence.\r\n\r\n> **AI-DFE** ([Data Fabric Engine](../ai-dfe/)) is a family-scoped **companion** — it gathers data from all packages and distributes structured JSON for dashboards and status roll-ups. It runs alongside the chain rather than as a linear step, so it is not shown as a chain row above.\r\n\r\n---\r\n\r\n## Features\r\n\r\n- **Full Generation** — one-shot workspace creation from architecture docs\r\n- **Delta Reconciliation** — incremental updates when architecture changes\r\n- **Extension-Aware** — detects AI-ADLC v1.1 extensions (DDD, Microservices, BFF, Event Sourcing, Resilience, Feature Flags)\r\n- **Conditional Generation** — only produces steering files justified by the architecture\r\n- **Provenance Tracking** — every generated rule traces to its AP source\r\n- **Non-Destructive Updates** — reconciliation preserves team customizations\r\n- **Technology-Adaptive** — generates stack-appropriate configs (Node, Python, .NET, Java, Generic)\r\n- **Prescriptive Output** — steering files say \"MUST/MUST NOT\", not \"should/consider\"\r\n\r\n---\r\n\r\n## What It Generates\r\n\r\n| Category | Files |\r\n|----------|:-----:|\r\n| Steering files (always) | 19 |\r\n| Steering files (conditional) | Up to 8 |\r\n| Operational documents | 6 |\r\n| Planning templates | 3 |\r\n| Config files | 5 |\r\n| Source structure | Per C4 L3 modules |\r\n\r\n---\r\n\r\n## Output Directory Structure\r\n\r\nAI-DWG generates a self-contained dev workspace within the project folder. It reads peer inputs (AP, PBP, UXP) from the same project and outputs a workspace meant to be opened separately in its own IDE:\r\n\r\n```\r\npdlc-ws/projects/\r\n├── PROJECTS.md ← workspace registry\r\n└── PRJ-{ABBREV}-{slug}/ ← one project\r\n ├── management_framework/ ← shared governance spine\r\n ├── pip/ ← AI-PILC output (read by DWG)\r\n ├── architecture/ ← AI-ADLC output (read by DWG)\r\n ├── ux/ ← AI-UXD output (read by DWG)\r\n ├── backlog/ ← AI-POLC output (read by DWG)\r\n │\r\n └── {slug}-workspace/ ← AI-DWG output (dev workspace)\r\n ├── rules/ ← generated steering files\r\n ├── .kiro/hooks/ ← AI-GCE governs here\r\n ├── management_framework/ ← spine carried forward\r\n ├── src/ ← code structure per C4 L3\r\n ├── tests/ ← test structure\r\n └── configs … ← CI/CD, linting, etc.\r\n```\r\n\r\n> The dev workspace is opened **separately** in its own IDE instance. AI-GCE and AI-TGE operate inside it. The `projects/` structure is always-on — see `OUTPUT_AND_STATE_CONTRACT.md`.\r\n\r\n---\r\n\r\n## Activation\r\n\r\n**Explicit key:** type `_DWG_` in any prompt to activate AI-DWG unambiguously — even when other AI-* packages share the workspace. The status key `_ACTIVE_` reports which package is currently active. A package switch never happens without your explicit key or confirmation, and any switch is announced on the first line of the response (`Active package: AI-DWG`). See [`../TRIGGER_KEYS_REFERENCE.md`](../TRIGGER_KEYS_REFERENCE.md) for the full family key table.\r\n\r\n---\r\n\r\n## Installation\r\n\r\nSee [setup/INSTALL.md](./setup/INSTALL.md)\r\n\r\n---\r\n\r\n## Usage\r\n\r\n```\r\n# First time\r\nUsing #ai-dwg-rules, generate the development workspace from my architecture package.\r\n\r\n# After architecture changes\r\nUsing #ai-dwg-rules, reconcile the workspace — {what changed}.\r\n```\r\n\r\n---\r\n\r\n## File Structure\r\n\r\n```\r\nai-dwg/\r\n├── README.md ← You are here\r\n├── LICENSE ← Apache 2.0 + Attribution\r\n├── PLAN.md ← Design plan\r\n├── ai-dwg-rules/\r\n│ └── core-generator.md ← Master generation logic\r\n├── ai-dwg-rule-details/\r\n│ ├── common/ ← Process overview, AP reading guide, validation\r\n│ ├── mapping/ ← 36 transformation rule files\r\n│ ├── reconciliation/ ← Diff, merge, provenance, signaling\r\n│ └── templates/ ← Output file templates (48 files)\r\n└── setup/\r\n └── INSTALL.md ← Installation instructions\r\n```\r\n\r\n---\r\n\r\n## Tenets\r\n\r\n1. **AP is the source of truth** — every rule traces to architecture\r\n2. **Prescriptive over descriptive** — \"MUST\" not \"should\"\r\n3. **Day-1 productivity** — developers start contributing immediately\r\n4. **Non-destructive reconciliation** — team work is never lost\r\n5. **Conditional generation** — no bloat; only what architecture justifies\r\n6. **Detection by marker** — works regardless of folder structure\r\n7. **Standalone capable** — works with or without the full AI-* chain\r\n\r\n---\r\n\r\n## Compatibility\r\n\r\n- AI-ADLC v1.0 (core workflow)\r\n- AI-ADLC v1.1 (6 extensions)\r\n- Standalone Architecture Package (any structured markdown)\r\n\r\n---\r\n\r\n## Author\r\n\r\n**Created By:** Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\r\n**Inspired By:** [awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows) (MIT-0)\r\n\r\n---\r\n\r\n## License\r\n\r\n**Apache License 2.0 with Attribution Addendum**\r\n\r\n- **Free to use:** Personal, commercial, educational, and organizational use — all permitted\r\n- **Modify and distribute:** Create derivative works, redistribute, sublicense — all permitted\r\n- **Attribution required:** Any distributed product substantially based on this work must include:\r\n\r\n> *\"Built on AIFLC by Mohammad Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\"*\r\n\r\n- **No warranty:** Provided \"AS IS\" without warranties of any kind\r\n\r\nSee [LICENSE](./LICENSE) and [NOTICE](./NOTICE) in this directory for full terms.\r\n\r\n**Copyright:** © 2026 Mohammad Maheri\r\n\r\n---\r\n\r\n*Part of [AIFLC](../README.md) — the AI-* PDLC Family*\n\nFile v1.0.0:ai-flo/README.md\n\n# AI-FLO — AI-Driven Flow Orchestrator\r\n\r\n[![License: Apache 2.0](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](./LICENSE)\r\n\r\n**Version:** 1.0.0\r\n**Created By:** Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\r\n**License:** Apache 2.0 with Attribution\r\n\r\n---\r\n\r\n## What Is AI-FLO?\r\n\r\nAI-FLO is the nervous system of the AI-* PDLC Family. It routes decisions down from the Portfolio layer, relays status up from the Project layer, and maintains awareness of where every project is in the chain at all times.\r\n\r\n**In one sentence:** AI-FLO turns the AI-* PDLC Family from a collection of independent packages into a coordinated pipeline — tracking positions, dispatching projects, detecting conflicts, and ensuring nothing falls between the cracks.\r\n\r\n---\r\n\r\n## Family Position\r\n\r\nAI-FLO is part of **AIFLC** (AI Full Life Cycle). It sits on the **edge** between the Portfolio layer and Project layer in the AI-* PDLC Family:\r\n\r\n```\r\n╔════════════════ PORTFOLIO LAYER · scope = MANY projects ════════════════╗\r\n\r\n (optional)\r\n AI-ILC ⇢ AI-PILC ⇢ AI-PPM\r\n Decide it Initiate it Govern it (portfolio of N projects)\r\n\r\n╚═════════════════════════════════╤═══════════════════════════════════════╝\r\n │\r\n AI-FLO Route it — package-to-package\r\n │ flow on the edge between layers\r\n╔════════════════ PROJECT LAYER · scope = ONE project ════════════════════╗\r\n\r\n AI-POLC ──► AI-UXD ──► AI-ADLC ──► AI-DWG ──► AI-DLC v1 (build) ¹\r\n Own it Design UX Design it Prepare it ▲\r\n │\r\n AI-POLC ⇄ AI-DLC v1 (back-and-forth)┘\r\n AI-DLC v1 ⇢ AI-UXD+AI-POLC (feedback)\r\n\r\n AI-GCE + AI-TGE ──── alongside AI-DLC v1 (continuous quality) ────►\r\n Guard it Test it\r\n\r\n╚═════════════════════════════════════════════════════════════════════════╝\r\n ¹ AI-DLC v1 = Amazon's open-source build lifecycle (not ours; we feed it).\r\n```\r\n\r\n| Layer | Package | Type | Input | Output |\r\n|-------|---------|------|-------|--------|\r\n| Portfolio | **AI-ILC** ² | Interactive workflow (lifecycle) | Raw idea | Approved Idea Brief / Feature Brief |\r\n| Portfolio | **AI-PILC** | Interactive workflow (lifecycle) | Raw requirement | Project Initiation Package (PIP) |\r\n| Portfolio | **AI-PPM** ³ | Adaptive portfolio engine | Multiple PIPs + Approved Idea Briefs | Portfolio register + cross-project prioritization & governance |\r\n| Edge | **AI-FLO** ³ | Router / orchestration engine | Any package output marker | Routing decision + handoff to next package/layer |\r\n| Project | **AI-POLC** ³ | Interactive workflow (lifecycle) | PIP | Product Backlog Package (PBP) |\r\n| Project | **AI-UXD** ³ | Interactive workflow (lifecycle) | PIP + PBP | UX Design Package (UXP): personas/journeys, IA, user flows, design system + tokens, accessibility baseline |\r\n| Project | **AI-ADLC** | Interactive workflow (lifecycle) | PIP + PBP + UXP | Architecture Package (AP) |\r\n| Project | **AI-DWG** | One-time generator | AP + PBP + UXP | Ready-to-code development workspace (DW) |\r\n| Project | **AI-GCE** | Adaptive governance engine | DW (AI-DWG output) | Compliance enforcement layer |\r\n| Project | **AI-TGE** | Test governance engine | DW / build artifacts | Test governance & quality layer |\r\n| Project | **AI-DLC v1** ¹ | Interactive workflow (lifecycle) | DW + GCE + User Stories (from AI-POLC) | Working Software |\r\n\r\n> ¹ **AI-DLC v1** ([awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows)) is NOT our product. Our chain produces the workspace AI-DLC v1 consumes.\r\n> ² **AI-ILC** is an **optional pre-stage** (the funnel before the funnel). The chain still works without it for users who start at AI-PILC. `⇢` denotes the optional link.\r\n> ³ All packages in this table are **built**. AI-PPM (portfolio engine), AI-FLO (router), AI-POLC (product ownership lifecycle), and AI-UXD (UX design lifecycle) were the last four — completed June 2026. Within the Project layer, **AI-POLC, AI-UXD, and AI-ADLC run sequentially** (POLC→UXD→ADLC) — each feeds the next, culminating at AI-DWG which receives all three outputs (AP + PBP + UXP). **AI-GCE and AI-TGE run alongside AI-DLC v1** as continuous quality engines; **AI-POLC ⇄ AI-DLC v1** exchange backlog/acceptance throughout delivery; and **AI-DLC v1 runtime feedback flows back to both AI-UXD and AI-POLC**. Feedback loops (ADLC→POLC cost/risk, ADLC→UXD constraints) provide iterative refinement without changing the forward sequence.\r\n\r\n> **AI-DFE** ([Data Fabric Engine](../ai-dfe/)) is a family-scoped **companion** — it gathers data from all packages and distributes structured JSON for dashboards and status roll-ups. It runs alongside the chain rather than as a linear step, so it is not shown as a chain row above.\r\n\r\n---\r\n\r\n## Features\r\n\r\n- **3 phases, 10 stages** — Configure → Route → Monitor\r\n- **Cross-layer dispatch** — carry AI-PPM's authorization down to Project-layer packages\r\n- **Upward roll-up relay** — compile project status and surface to portfolio level\r\n- **Sequential routing** — carry routing decisions through the Project-layer sequence (POLC → UXD → ADLC → DWG) and validate readiness at convergence (AP+PBP+UXP → DWG)\r\n- **Flow state tracking** — know where every project is at all times (`flo-state.md`)\r\n- **Routing table** — static canonical default + per-project profiles + runtime toggles\r\n- **Conflict detection (flag-and-hold)** — detect bidirectional signal collisions; never silently resolve\r\n- **6 conflict types** — signal collision, contention, profile contradiction, stale signal, deadlock, authority conflict\r\n- **Anti-deadlock guarantee** — every hold has a timeout with deterministic fallback; operator can always force-through\r\n- **Flow exceptions** — block, cancel, rework, skip, escalate with full audit trail\r\n- **Route override + toggle** — operator can deviate from canonical chain at any time (logged)\r\n- **3 workspace topology modes** — co-located (1:1), hub-and-spoke (1:N), fully distributed (1:N remote)\r\n- **Hybrid interaction model** — Dashboard (read state) + Command (execute actions) + Alert (proactive notifications)\r\n- **Routing log** — append-only audit trail of every routing event\r\n- **Governance spine contribution** — FLO-D- decisions, FLO-I- issues (routine hops stay in log only)\r\n- **FIA__ governance agent** — on-demand integrity validation (17 checks across 5 categories)\r\n- **Graceful degradation** — without FLO, same-layer packages still work via direct marker detection\r\n- **Advisory model** — records decisions for human action; does not auto-execute package sessions (v1.0)\r\n\r\n---\r\n\r\n## Activation\r\n\r\n**Explicit key:** type `_FLO_` in any prompt to activate AI-FLO unambiguously — even when other AI-* packages share the workspace. The status key `_ACTIVE_` reports which package is currently active. A package switch never happens without your explicit key or confirmation, and any switch is announced on the first line of the response (`Active package: AI-FLO`). See [`../TRIGGER_KEYS_REFERENCE.md`](../TRIGGER_KEYS_REFERENCE.md) for the full family key table.\r\n\r\n---\r\n\r\n## Installation\r\n\r\nSee `setup/INSTALL.md` for full multi-platform installation instructions.\r\n\r\n**Quick start (Kiro):**\r\n1. Copy `ai-flo-rules/` and `ai-flo-rule-details/` into the uniform home `.aiflc/pdlc/`\r\n2. Copy `session-orchestrator.md` into `.kiro/steering/` (the only always-loaded file; it `Read`s the core on demand)\r\n3. Start a session — AI-FLO activates when you request routing operations\r\n\r\n---\r\n\r\n## Usage\r\n\r\n1. Open a workspace where AI-* packages are installed\r\n2. Start a chat and say:\r\n ```\r\n Using AI-FLO, what should I do next?\r\n ```\r\n3. AI-FLO reads the current workflow state markers and tells you which package to activate next (and flags pending handoffs or conflicts)\r\n4. It routes decisions and relays status between packages — it never produces package artifacts itself\r\n\r\n## File Structure\r\n\r\n```\r\nai-flo/\r\n├── README.md ← This file\r\n├── LICENSE ← Apache 2.0 + Attribution\r\n├── PLAN.md ← Design rationale + decisions\r\n├── ai-flo-rules/\r\n│ └── core-engine.md ← Master orchestration (THE spec)\r\n├── ai-flo-rule-details/\r\n│ ├── common/ ← Cross-cutting (5 files)\r\n│ ├── configure/ ← Phase 1 stages (3 files)\r\n│ ├── route/ ← Phase 2 stages (4 files)\r\n│ ├── monitor/ ← Phase 3 stages (3 files)\r\n│ └── templates/ ← Output templates (9 files)\r\n│ └── agents/ ← Governance agent (2 files)\r\n└── setup/\r\n └── INSTALL.md ← Platform setup guide\r\n```\r\n\r\n---\r\n\r\n## Tenets\r\n\r\n1. **Advisory, not autonomous** — records decisions for human action; never auto-executes\r\n2. **Carry, don't decide** — PPM decides; operator overrides; FLO routes\r\n3. **Log everything** — every hop, override, toggle, conflict is recorded\r\n4. **Flag, never suppress** — conflicts always surface; FLO never silently picks a winner\r\n5. **Canonical default, governed deviation** — family chain is default; deviations are explicit and auditable\r\n6. **Topology-aware** — adapts to co-located, hub-and-spoke, or fully-distributed workspaces\r\n7. **Additive, not blocking** — without FLO, the family still works; FLO adds coordination, never becomes a single point of failure\r\n\r\n---\r\n\r\n## Output (What You Get)\r\n\r\nWhen AI-FLO is active:\r\n\r\n```\r\n{workspace}/flow-orchestration/\r\n├── flo-state.md (marker + flow state)\r\n├── routing-table.md (active routes + profiles)\r\n├── routing-log.md (append-only audit trail)\r\n├── dispatch-records/ (one per dispatched project)\r\n├── readiness-checks/ (fan-in evaluations)\r\n├── conflict-alerts/ (flag-and-hold reports)\r\n└── roll-up-reports/ (periodic status for PPM)\r\n```\r\n\r\n---\r\n\r\n## Author\r\n\r\n**Mohammad Maheri** — Process designer specializing in injectable AI workflow packages.\r\n\r\nAI-FLO was designed to complete the AI-* Family's architecture: turning a collection of independent packages into a coordinated system where work flows between layers as naturally as data flows through a pipeline.\r\n\r\n---\r\n\r\n*v1.0.0 | 2026-06-12*\r\n\r\n---\r\n\r\n## License\r\n\r\n**Apache License 2.0 with Attribution Addendum**\r\n\r\n- **Free to use:** Personal, commercial, educational, and organizational use — all permitted\r\n- **Modify and distribute:** Create derivative works, redistribute, sublicense — all permitted\r\n- **Attribution required:** Any distributed product substantially based on this work must include:\r\n\r\n> *\"Built on AIFLC by Mohammad Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\"*\r\n\r\n- **No warranty:** Provided \"AS IS\" without warranties of any kind\r\n\r\nSee `LICENSE` and `NOTICE` in this directory for full terms.\r\n\r\n**Copyright:** © 2026 Mohammad Maheri\r\n\r\n---\r\n\r\n*Part of [AIFLC](../README.md) — the AI-* PDLC Family*\n\nFile v1.0.0:ai-gce/README.md\n\n# AI-GCE — AI-Driven Governance & Compliance Engine\r\n\r\n[![License: Apache 2.0](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](./LICENSE)\r\n\r\n**Created By:** Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\r\n**Inspired By:** [awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows) (MIT-0)\r\n**Version:** 1.0.0\r\n\r\n---\r\n\r\n## What Is AI-GCE?\r\n\r\nA **full project governance engine** that reads an AI-DWG development workspace and derives a tailored compliance enforcement layer — rules, hooks, agents, and logging infrastructure specific to that project's architecture, technology, team structure, and methodology.\r\n\r\n**Not just architecture compliance.** AI-GCE enforces team topology, role segregation, session discipline, sprint governance, PR process, CI/CD gates, DevOps standards, and change management — all derived automatically from the workspace.\r\n\r\n---\r\n\r\n## The AI-* PDLC Family\r\n\r\nAI-GCE is part of **AIFLC** (AI Full Life Cycle) — the AI-* PDLC Family of injectable workflow packages.\r\n\r\n```\r\n╔════════════════ PORTFOLIO LAYER · scope = MANY projects ════════════════╗\r\n\r\n (optional)\r\n AI-ILC ⇢ AI-PILC ⇢ AI-PPM\r\n Decide it Initiate it Govern it (portfolio of N projects)\r\n\r\n╚═════════════════════════════════╤═══════════════════════════════════════╝\r\n │\r\n AI-FLO Route it — package-to-package\r\n │ flow on the edge between layers\r\n╔════════════════ PROJECT LAYER · scope = ONE project ════════════════════╗\r\n\r\n AI-POLC ──► AI-UXD ──► AI-ADLC ──► AI-DWG ──► AI-DLC v1 (build) ¹\r\n Own it Design UX Design it Prepare it ▲\r\n │\r\n AI-POLC ⇄ AI-DLC v1 (back-and-forth)┘\r\n AI-DLC v1 ⇢ AI-UXD+AI-POLC (feedback)\r\n\r\n AI-GCE + AI-TGE ──── alongside AI-DLC v1 (continuous quality) ────►\r\n Guard it Test it\r\n\r\n╚═════════════════════════════════════════════════════════════════════════╝\r\n ¹ AI-DLC v1 = Amazon's open-source build lifecycle (not ours; we feed it).\r\n```\r\n\r\n| Layer | Package | Type | Input | Output |\r\n|-------|---------|------|-------|--------|\r\n| Portfolio | **AI-ILC** ² | Interactive workflow (lifecycle) | Raw idea | Approved Idea Brief / Feature Brief |\r\n| Portfolio | **AI-PILC** | Interactive workflow (lifecycle) | Raw requirement | Project Initiation Package (PIP) |\r\n| Portfolio | **AI-PPM** ³ | Adaptive portfolio engine | Multiple PIPs + Approved Idea Briefs | Portfolio register + cross-project prioritization & governance |\r\n| Edge | **AI-FLO** ³ | Router / orchestration engine | Any package output marker | Routing decision + handoff to next package/layer |\r\n| Project | **AI-POLC** ³ | Interactive workflow (lifecycle) | PIP | Product Backlog Package (PBP) |\r\n| Project | **AI-UXD** ³ | Interactive workflow (lifecycle) | PIP + PBP | UX Design Package (UXP): personas/journeys, IA, user flows, design system + tokens, accessibility baseline |\r\n| Project | **AI-ADLC** | Interactive workflow (lifecycle) | PIP + PBP + UXP | Architecture Package (AP) |\r\n| Project | **AI-DWG** | One-time generator | AP + PBP + UXP | Ready-to-code development workspace (DW) |\r\n| Project | **AI-GCE** | Adaptive governance engine | DW (AI-DWG output) | Compliance enforcement layer |\r\n| Project | **AI-TGE** | Test governance engine | DW / build artifacts | Test governance & quality layer |\r\n| Project | **AI-DLC v1** ¹ | Interactive workflow (lifecycle) | DW + GCE + User Stories (from AI-POLC) | Working Software |\r\n\r\n> ¹ **AI-DLC v1** ([awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows)) is NOT our product. Our chain produces the workspace AI-DLC v1 consumes.\r\n> ² **AI-ILC** is an **optional pre-stage** (the funnel before the funnel). The chain still works without it for users who start at AI-PILC. `⇢` denotes the optional link.\r\n> ³ All packages in this table are **built**. AI-PPM (portfolio engine), AI-FLO (router), AI-POLC (product ownership lifecycle), and AI-UXD (UX design lifecycle) were the last four — completed June 2026. Within the Project layer, **AI-POLC, AI-UXD, and AI-ADLC run sequentially** (POLC→UXD→ADLC) — each feeds the next, culminating at AI-DWG which receives all three outputs (AP + PBP + UXP). **AI-GCE and AI-TGE run alongside AI-DLC v1** as continuous quality engines; **AI-POLC ⇄ AI-DLC v1** exchange backlog/acceptance throughout delivery; and **AI-DLC v1 runtime feedback flows back to both AI-UXD and AI-POLC**. Feedback loops (ADLC→POLC cost/risk, ADLC→UXD constraints) provide iterative refinement without changing the forward sequence.\r\n\r\n> **AI-DFE** ([Data Fabric Engine](../ai-dfe/)) is a family-scoped **companion** — it gathers data from all packages and distributes structured JSON for dashboards and status roll-ups. It runs alongside the chain rather than as a linear step, so it is not shown as a chain row above.\r\n\r\n---\r\n\r\n## Key Features\r\n\r\n- **Zero configuration** — reads the workspace; derives everything from steering files\r\n- **Two-source derivation** — built-in methodology baseline + steering-enriched project specifics\r\n- **Four operating modes** — Full Generation, Re-Derivation, Brownfield Adoption, Tier Activation\r\n- **Three-tier progressive compliance** — Day 0 (60-70%) → Sprint 2+ (80-90%) → Pre-Release (92%+)\r\n- **Dual enforcement model** — 9 hooks (automatic, real-time) + 6 process agents (manual, milestone-triggered)\r\n- **Hook debounce strategy** — security-critical on fileEdited; advisory on agentStop\r\n- **Process agent shortcuts** — `SDC__`, `SGV__`, `CRV__`, `SQC__`, `CMG__`, `DOD__` invoke governance at milestones\r\n- **Agent Process Guide** — generated user manual documents when to call, consequences of skipping, recovery procedures\r\n- **Phase-aware enforcement** — rules only fire when applicable to current project phase\r\n- **Silent when passing** — no output unless something is wrong\r\n- **Technology-specific** — hooks use actual file patterns derived from tech-stack.md\r\n- **Brownfield first-class** — baseline existing violations, enforce new code from day 1\r\n- **Full audit trail** — every hook writes JSONL compliance events; Git-committed evidence\r\n- **Package territory segregation** — three-layer isolation prevents hooks from firing on AI-* family infrastructure files (pattern scoping + runtime preamble + territory registry)\r\n\r\n---\r\n\r\n## How to Use\r\n\r\n### Quick Start\r\n\r\nIn a workspace that has `rules/` populated (by AI-DWG):\r\n\r\n```\r\nUsing AI-GCE, generate the compliance engine for this workspace\r\n```\r\n\r\nAI-GCE asks 1-2 questions, then generates everything in one pass.\r\n\r\n### Four Modes\r\n\r\n| Say This | Mode Triggered |\r\n|----------|:-------------:|\r\n| \"Generate compliance engine\" | Mode 1: Full Generation |\r\n| \"Steering changed — re-derive\" | Mode 2: Re-Derivation |\r\n| \"Brownfield adoption\" / \"Baseline scan\" | Mode 3: Brownfield |\r\n| \"Activate next compliance tier\" | Mode 4: Tier Activation |\r\n\r\n---\r\n\r\n## What It Produces\r\n\r\nInstalled into the development workspace:\r\n\r\n```\r\n.governance/hooks/ ← 9 always-generated + up to 6 conditional enforcement hooks (JSON)\r\n.governance/agents/ ← 6 process/audit governance agents (milestone-triggered)\r\n.compliance-state.json ← Tier tracking + readiness criteria\r\nmanagement_framework/dashboards/compliance-dashboard.md ← Visual compliance overview (Dashboard Framework Convention)\r\n.governance/\r\n├── COMPLIANCE_README.md ← Developer-facing guide\r\n├── AGENT-GUIDE.md ← Process agent user manual (when to call, consequences)\r\n├── AGENT_REGISTRY.md ← Single-source agent lookup\r\n├── rules/ ← 18+ always rules + conditionals\r\n├── agents/ ← Audit agent + init agent specs (legacy location)\r\n└── compliance-log/ ← JSONL schema + workflows\r\n```\r\n\r\n**Enforcement model:** Hooks handle real-time code enforcement (automatic, on file save or session end). Agents handle governance milestones (manual, user-triggered at process boundaries). See `.governance/AGENT-GUIDE.md` for when to call each agent.\r\n\r\n---\r\n\r\n## Standalone Usage\r\n\r\nAI-GCE works on **any workspace** that has `rules/` files — it does NOT require AI-DWG to have generated those files. You can:\r\n\r\n- Create steering files manually and run AI-GCE against them\r\n- Use AI-GCE on an existing project that already has its own steering setup\r\n- Run AI-GCE without any predecessor package installed\r\n\r\nEven if your workspace has minimal or no steering files, the **built-in baseline** provides universal governance rules (author ≠ approver, no direct-push to main, spec before code, session discipline, etc.) that apply to any project. Steering files enrich and specialize — their absence doesn't block.\r\n\r\n**Graceful degradation (OR-input):** AI-GCE never blocks on missing steering. It degrades gracefully from full-enriched enforcement (every steering file produces tailored rules) to baseline-only governance (universal rules from the built-in set). Start wherever you are — bring what you have.\r\n\r\n---\r\n\r\n## Platform Capabilities\r\n\r\nAI-GCE generates the same rules, hooks, and agents on every platform. But **hook execution and agent triggers are Kiro-specific** — they depend on Kiro's event system (`fileEdited`, `agentStop`, `preToolUse`).\r\n\r\n| What You Get | Kiro | Claude Code / Cursor / Cline / Others |\r\n|--------------|:----:|:-------------------------------------:|\r\n| `.governance/rules/*.md` (readable rules) | ✅ | ✅ |\r\n| Hook JSON files generated | ✅ | ✅ (generated but inert) |\r\n| Agent files generated | ✅ | ✅ (generated but inert) |\r\n| **Hooks auto-fire on events** | ✅ | ❌ |\r\n| **Agent shortcuts (`SDC__`, etc.)** | ✅ | ❌ |\r\n| **Compliance logging (automatic)** | ✅ | ❌ (manual) |\r\n\r\n**On non-Kiro platforms:** Governance rules are fully available as documentation. The AI reads and follows them if instructed — but enforcement is advisory rather than automatic. Teams can bridge the gap via CI/CD checks or periodic manual audits.\r\n\r\nFor the full cross-platform matrix, see `PLATFORM_CAPABILITIES.md`.\r\n\r\n---\r\n\r\n## Activation\r\n\r\n**Explicit key:** type `_GCE_` in any prompt to activate AI-GCE unambiguously — even when other AI-* packages share the workspace. The status key `_ACTIVE_` reports which package is currently active. A package switch never happens without your explicit key or confirmation, and any switch is announced on the first line of the response (`Active package: AI-GCE`). See [`../TRIGGER_KEYS_REFERENCE.md`](../TRIGGER_KEYS_REFERENCE.md) for the full family key table.\r\n\r\n---\r\n\r\n## Installation\r\n\r\nSee `setup/INSTALL.md` for platform-specific installation instructions.\r\n\r\n---\r\n\r\n## Package Structure\r\n\r\n```\r\nai-gce/\r\n├── README.md ← This file\r\n├── LICENSE ← Apache 2.0 + Attribution\r\n├── PLAN.md ← Design rationale + gap analysis\r\n├── ai-gce-rules/\r\n│ └── core-generator.md ← Master derivation logic (4 modes)\r\n├── ai-gce-rule-details/\r\n│ ├── common/ ← Cross-cutting docs (5 files)\r\n│ ├── generators/ ← Derivation logic per rule category (24 files, incl. agents-from-steering)\r\n│ ├── re-derivation/ ← Incremental update logic (3 files)\r\n│ └── templates/ ← Hook, agent, and log templates\r\n│ ├── hooks/ ← 9 hook JSON templates + enforcement guide\r\n│ ├── agents/ ← 8 agent templates + agent-guide + agent-registry\r\n│ └── compliance-log/ ← Schema + workflows + dashboard template\r\n└── setup/\r\n └── INSTALL.md\r\n```\r\n\r\n---\r\n\r\n## Tenets\r\n\r\n1. **Derive, don't configure.** The workspace already has the answers — read them.\r\n2. **Governance is broader than architecture.** Roles, sessions, sprints, PRs, DevOps — all enforced.\r\n3. **Progressive, not big-bang.** Three tiers. Teams adopt at their pace.\r\n4. **Silent when compliant.** Noise kills adoption. Only speak when wrong.\r\n5. **Every action logged.** Audit trail is non-negotiable. Every hook writes.\r\n6. **Brownfield is normal.** Most projects have existing code. Baseline and improve.\r\n7. **Rules are enforceable.** MUST/NEVER, not \"consider.\" Binary pass/fail.\r\n8. **Customizations survive.** Team additions marked `` persist through re-derivation.\r\n\r\n---\r\n\r\n## Author\r\n\r\n**Maheri** — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\r\n\r\nAI-GCE is part of the AI-* injectable package family. Inspired by [awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows) (MIT-0 license).\r\n\r\n---\r\n\r\n## License\r\n\r\n**Apache License 2.0 with Attribution Addendum**\r\n\r\n- **Free to use:** Personal, commercial, educational, and organizational use — all permitted\r\n- **Modify and distribute:** Create derivative works, redistribute, sublicense — all permitted\r\n- **Attribution required:** Any distributed product substantially based on this work must include:\r\n\r\n> *\"Built on AIFLC by Mohammad Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\"*\r\n\r\n- **No warranty:** Provided \"AS IS\" without warranties of any kind\r\n\r\nSee [LICENSE](./LICENSE) and [NOTICE](./NOTICE) in this directory for full terms.\r\n\r\n**Copyright:** © 2026 Mohammad Maheri\r\n\r\n---\r\n\r\n*Part of [AIFLC](../README.md) — the AI-* PDLC Family*\n\nFile v1.0.0:ai-adlc/ai-adlc-rule-details/assembly/agent-installation.md\n\n\r\n# Post-Workflow: Agent Installation\r\n\r\n## Phase: 🚀 ASSEMBLY (post-workflow)\r\n## Execution: ALWAYS — automatic, no user interaction\r\n\r\n---\r\n\r\n## Purpose\r\n\r\nAfter the Architecture Package (AP) workflow completes — or at any point during AI-ADLC execution — install the AI-ADLC governance agent into the destination workspace. This step is **automatic**: it requires no user interaction and runs independently of any sibling package.\r\n\r\nThe agent installed is the **architecture-decision-agent** (`ADLC-AG-01`), and the install activates the `ADA__` shortcut for post-AP architecture-quality validation.\r\n\r\n---\r\n\r\n## What Gets Installed\r\n\r\n| Artifact | Destination | Action |\r\n|----------|-------------|--------|\r\n| `architecture-decision-agent.md` | `.kiro/agents/` | Copy from `templates/agents/` |\r\n| Shortcut rules block | `.kiro/steering/workspace-rules.md` | Append `` block (or replace if exists) |\r\n| Agent registry entries | `.governance/AGENT_REGISTRY.md` | Create file if absent; append AI-ADLC entries if exists |\r\n| Agent guide section | `.governance/AGENT-GUIDE.md` | Create file if absent; append AI-ADLC section if exists |\r\n\r\n---\r\n\r\n## Installation Logic\r\n\r\n1. **Agent file:** Copy `templates/agents/architecture-decision-agent.md` to `.kiro/agents/architecture-decision-agent.md`. Populate `{version}` with the current AI-ADLC version and `{ISO-date}` with today's date.\r\n\r\n2. **Shortcut block:** Check `.kiro/steering/workspace-rules.md` for the `` marker:\r\n - If found → replace the block (between BEGIN and END markers)\r\n - If not found → append the block from `templates/agents/shortcut-rules-block.md`\r\n\r\n3. **Agent registry:** Check for `.governance/AGENT_REGISTRY.md`:\r\n - If absent → create with header + AI-ADLC entry (ADLC-AG-01)\r\n - If exists → append AI-ADLC entry using the next available `ADLC-AG-{NN}` ID\r\n - Entry: `| ADLC-AG-01 | architecture-decision-agent | Process | ADA__ | 1 | AI-ADLC | Active | {date} |`\r\n\r\n4. **Agent guide:** Check for `.governance/AGENT-GUIDE.md`:\r\n - If absent → create with header + AI-ADLC section from `templates/agents/agent-guide.md`\r\n - If exists → append AI-ADLC section (between `` markers)\r\n\r\n---\r\n\r\n## Self-Sufficiency Rule (AGENT_GOVERNANCE_CONTRACT §5)\r\n\r\nAI-ADLC installs its own agent independently. There is **no dependency** on AI-GCE or AI-PILC being present. If other packages run later, they will detect and preserve the AI-ADLC entries via marker-based ownership.\r\n\r\n---\r\n\r\n## Post-Install Confirmation\r\n\r\n```\r\n🤖 AI-ADLC Governance Agent Installed\r\n • Agent: architecture-decision-agent (ADLC-AG-01)\r\n • Shortcut: ADA__ (active immediately)\r\n • Call ADA__ after AP completion to validate architecture quality.\r\n```\n\nFile v1.0.0:ai-adlc/ai-adlc-rule-details/assembly/package-assembly.md\n\n\r\n# Architecture Package Assembly\r\n\r\n## Stage: 13 of 13\r\n## Phase: 🚀 ASSEMBLY\r\n## Execution: ALWAYS (Final Stage)\r\n\r\n---\r\n\r\n## Purpose\r\n\r\nConsolidate all architecture deliverables into a complete, cross-referenced, quality-checked Architecture Package (AP). Verify consistency across all documents and ADRs, identify unresolved questions, and produce a package README that serves as the table of contents and reading guide.\r\n\r\n---\r\n\r\n## Depth Adaptation\r\n\r\n| Depth | Assembly Behavior |\r\n|-------|------------------|\r\n| **Minimal** | Inventory check. Brief consistency scan. Package README with TOC and reading order. Quality score. |\r\n| **Standard** | Full cross-reference integrity check (containers ↔ tech stack ↔ ADRs ↔ security). Completeness audit. Open questions summary. Package README with full narrative. Quality score with per-category breakdown. |\r\n| **Comprehensive** | Deep consistency audit with explicit verification per document pair. Traceability matrix (requirement → principle → decision → ADR). Gap analysis against requirements. Executive architecture summary. Package README with detailed reading guide and decision map. Quality score with recommendations for future iterations. |\r\n\r\n---\r\n\r\n## Step-by-Step Execution\r\n\r\n### Step 1: Inventory All Artifacts\r\n\r\nScan the output directory and compile a complete inventory:\r\n\r\n```markdown\r\n## Package Inventory\r\n\r\n### Architecture Documents\r\n\r\n| # | Document | Stage | File Path | Status |\r\n|---|----------|:-----:|-----------|:------:|\r\n| 1 | Architecture Vision & Principles | 3 | {path} | ✅ Complete |\r\n| 2 | System Context (C4 L1) | 4 | {path} | ✅ Complete |\r\n| 3 | Container Diagram (C4 L2) | 5 | {path} | ✅ Complete |\r\n| 4 | Technology Stack | 6 | {path} | ✅ Complete |\r\n| 5 | Multi-Tenancy Architecture | 7 | {path} | ✅ / ⏭️ Skipped |\r\n| 6 | Security & Identity Architecture | 8 | {path} | ✅ Complete |\r\n| 7 | Data Architecture | 9 | {path} | ✅ Complete |\r\n| 8 | API Architecture | 10 | {path} | ✅ Complete |\r\n| 9 | Integration Architecture | 11 | {path} | ✅ Complete |\r\n| 10 | Infrastructure & Deployment | 11 | {path} | ✅ Complete |\r\n| 11 | Component Design (C4 L3) | 12 | {path} | ✅ Complete |\r\n\r\n### Architecture Decision Records\r\n\r\n| ADR # | Title | Status | Stage |\r\n|:-----:|-------|:------:|:-----:|\r\n| ADR-001 | {title} | Accepted | {n} |\r\n| ADR-002 | {title} | Accepted | {n} |\r\n| ... | ... | ... | ... |\r\n\r\n### Supporting Documents\r\n\r\n| Document | Path | Purpose |\r\n|----------|------|---------|\r\n| Architecture Workbook | {path} | Decision backlog, open questions, discussion notes |\r\n| adlc-state.md | {path} | Workflow state and progress |\r\n| ADR-000 Template | {path} | Template for future ADRs |\r\n```\r\n\r\n---\r\n\r\n### Step 2: Cross-Reference Integrity Check\r\n\r\nVerify consistency across ALL documents:\r\n\r\n| Check | Documents Involved | What to Verify |\r\n|-------|-------------------|---------------|\r\n| **System name** | All documents | Same name everywhere |\r\n| **Container names** | C4 L2, Tech Stack, Component Design, Infrastructure | Exact name match |\r\n| **Technology labels** | C4 L2, Tech Stack ADRs, Infrastructure, Component Design | Same tech in all references |\r\n| **External systems** | C4 L1, Integration Architecture | Every L1 external has integration pattern defined |\r\n| **Actors** | C4 L1, Security (auth methods), API (consumers) | All actors have auth path and API access defined |\r\n| **Entities** | Data Architecture, Component Design | Every entity has owning module; every module has entities listed |\r\n| **Modules** | Component Design, API Architecture | Every API endpoint maps to a module |\r\n| **Principles** | Vision, all subsequent documents | No recommendation contradicts a principle |\r\n| **Constraints** | Vision, all subsequent documents | No design choice violates a constraint |\r\n| **ADR decisions** | ADR files, parent documents | ADR summary in parent matches full ADR content |\r\n| **Security patterns** | Security doc, API doc, Multi-tenancy doc | Auth/authz consistently applied |\r\n| **Tenant scoping** | Multi-tenancy, Data, API, Component Design | Consistent isolation at all layers |\r\n\r\n**If inconsistency found:**\r\n1. Identify which document is authoritative (latest stage's decision wins)\r\n2. Flag to user: \"Inconsistency: {doc A} says X, {doc B} says Y\"\r\n3. Update the incorrect document\r\n4. Note correction in Architecture Workbook\r\n\r\n---\r\n\r\n### Step 3: Completeness Audit\r\n\r\n```markdown\r\n## Completeness Audit\r\n\r\n### Document Coverage\r\n\r\n| Check | Expected | Actual | Gap? |\r\n|-------|:--------:|:------:|:----:|\r\n| Architecture documents | {10-11} | {n} | {Any missing?} |\r\n| ADRs for major decisions | {5-10 typical} | {n} | {Any undocumented decisions?} |\r\n| C4 diagrams (L1 + L2 + L3) | 3 minimum | {n} | {Missing levels?} |\r\n| All containers have technology | 100% | {%} | {Any still TBD?} |\r\n| All externals have integration pattern | 100% | {%} | {Undesigned integrations?} |\r\n| All modules have entity ownership | 100% | {%} | {Orphan entities?} |\r\n\r\n### Principle Coverage\r\n\r\n| Principle | Addressed In | Verified? |\r\n|-----------|-------------|:---------:|\r\n| P1: {name} | {Which documents apply it} | {✅ / ⚠️} |\r\n| P2: {name} | {Documents} | {✅ / ⚠️} |\r\n\r\n### Open Questions (from Workbook)\r\n\r\n| # | Question | Status | Impact if Unresolved |\r\n|---|----------|:------:|---------------------|\r\n| 1 | {question} | {Resolved / Open / Deferred} | {What breaks or is unclear} |\r\n```\r\n\r\n---\r\n\r\n### Step 4: ADR Register Validation\r\n\r\n```markdown\r\n## ADR Validation\r\n\r\n| Check | Result |\r\n|-------|--------|\r\n| Sequential numbering (no gaps) | {✅ / ❌ — which missing?} |\r\n| All have \"Accepted\" or \"Proposed\" status | {✅ / ❌ — which stuck?} |\r\n| All cross-referenced in parent document | {✅ / ❌ — which orphaned?} |\r\n| No conflicting ADRs | {✅ / ❌ — which conflict?} |\r\n| Options actually evaluated (not rubber-stamp) | {✅ / ⚠️ — which lack alternatives?} |\r\n| Consequences documented | {✅ / ❌ — which missing consequences?} |\r\n```\r\n\r\n---\r\n\r\n### Step 5: Diagram Consistency\r\n\r\n```markdown\r\n## Diagram Integrity\r\n\r\n| Check | Result |\r\n|-------|--------|\r\n| C4 L2 containers ⊆ C4 L1 system boundary | {✅ / ❌} |\r\n| C4 L3 components ⊆ C4 L2 container | {✅ / ❌} |\r\n| Technology labels on L2 match Tech Stack doc | {✅ / ❌} |\r\n| External system names match across L1, Integration doc | {✅ / ❌} |\r\n| Actor names match across L1, Security, API docs | {✅ / ❌} |\r\n| All relationships labeled (verb + protocol) | {✅ / ❌} |\r\n| No orphan nodes in any diagram | {✅ / ❌} |\r\n```\r\n\r\n---\r\n\r\n### Step 6: Package Quality Score\r\n\r\n| Dimension | Score (1-5) | Criteria |\r\n|-----------|:-----------:|----------|\r\n| **Completeness** | {n} | All expected documents present; all stages covered |\r\n| **Consistency** | {n} | Cross-references match; no contradictions; terminology stable |\r\n| **Clarity** | {n} | Documents readable by target audience (developers + tech leads) |\r\n| **Actionability** | {n} | Development team can start building from these docs |\r\n| **Traceability** | {n} | Requirements → principles → decisions → design traceable |\r\n\r\n**Overall Package Quality: {sum}/25**\r\n\r\n| Score | Rating |\r\n|:-----:|--------|\r\n| 22-25 | 🟢 Excellent — ready for development handoff |\r\n| 18-21 | 🟡 Good — minor gaps; team can start with caveats |\r\n| 13-17 | 🟠 Adequate — notable gaps; supplement with verbal guidance |\r\n| 5-12 | 🔴 Incomplete — significant work needed |\r\n\r\n---\r\n\r\n### Step 7: Produce Architecture Package README\r\n\r\n```markdown\r\n# Architecture Package — {system_name}\r\n\r\n## Overview\r\n\r\n| Field | Value |\r\n|-------|-------|\r\n| System | {system_name} |\r\n| Architecture Style | {Modular Monolith / Microservices / etc.} |\r\n| Primary Technology | {Backend: X, Frontend: Y, DB: Z} |\r\n| Deployment | {Docker Compose / K8s / etc.} on {cloud / on-prem} |\r\n| Scale Target | {users, tenants, transactions} |\r\n| Multi-Tenant | {Yes — model / No} |\r\n| ADRs | {n} decisions recorded |\r\n| Package Quality | {score}/25 — {rating} |\r\n| Date Produced | {date} |\r\n| Produced Via | AI-ADLC v1.0.0 |\r\n\r\n---\r\n\r\n## Reading Order (Recommended)\r\n\r\n| Order | Document | What You'll Learn |\r\n|:-----:|----------|------------------|\r\n| 1 | Architecture Vision | Principles, constraints, quality priorities |\r\n| 2 | System Context (C4 L1) | Who uses the system; what it connects to |\r\n| 3 | Container Diagram (C4 L2) | Major deployable units and their relationships |\r\n| 4 | Technology Stack | What technology was chosen for each container and why |\r\n| 5 | Multi-Tenancy (if applicable) | How tenant isolation works at every layer |\r\n| 6 | Security & Identity | How auth, authz, encryption, and audit work |\r\n| 7 | Data Architecture | Schema strategy, entities, storage layers |\r\n| 8 | API Architecture | API conventions, versioning, error handling |\r\n| 9 | Integration & Infrastructure | External system connections; deployment topology |\r\n| 10 | Component Design (C4 L3) | Internal module structure; dependency rules |\r\n| — | ADRs | Deep-dive on specific decisions (reference as needed) |\r\n\r\n---\r\n\r\n## Architecture at a Glance\r\n\r\n{2-3 paragraph executive summary of the architecture — what it is, how it's structured, what makes it distinctive}\r\n\r\n---\r\n\r\n## Key Architectural Decisions (Top {n})\r\n\r\n| ADR | Decision | Impact |\r\n|:---:|----------|--------|\r\n| ADR-001 | {title} | {1-line impact} |\r\n| ADR-002 | {title} | {1-line impact} |\r\n| ... | ... | ... |\r\n\r\n---\r\n\r\n## Principles (Quick Reference)\r\n\r\n| ID | Principle | One-Liner |\r\n|:--:|-----------|-----------|\r\n| P1 | {name} | {statement} |\r\n| P2 | {name} | {statement} |\r\n| ... | ... | ... |\r\n\r\n---\r\n\r\n## Constraints (Quick Reference)\r\n\r\n| # | Constraint | Impact |\r\n|---|-----------|--------|\r\n| C1 | {constraint} | {impact} |\r\n| ... | ... | ... |\r\n\r\n---\r\n\r\n## Open Items / Future Decisions\r\n\r\n| # | Item | Context | When to Decide |\r\n|---|------|---------|:--------------:|\r\n| 1 | {open question or deferred decision} | {why it's open} | {Phase/milestone} |\r\n\r\n---\r\n\r\n## For Development Team\r\n\r\nThis package is the architectural blueprint. When starting development:\r\n1. Read documents in the recommended order above\r\n2. Reference ADRs when you encounter \"why was X chosen?\"\r\n3. Follow the principles — they constrain your implementation choices\r\n4. Respect the constraints — they are non-negotiable\r\n5. Module boundaries (C4 L3) define code organization\r\n6. API conventions (Stage 10) define your endpoint implementation\r\n\r\n---\r\n\r\n*Architecture Package produced: {date}*\r\n*Methodology: AI-ADLC v1.0.0*\r\n*Status: Ready for development team onboarding*\r\n```\r\n\r\n---\r\n\r\n### Step 8: Finalize Workbook\r\n\r\nUpdate Architecture Workbook:\r\n- Mark all resolved questions as \"✅ Resolved\"\r\n- List remaining open questions clearly\r\n- Add final session log entry\r\n- Close decision backlog (mark remaining items as \"Deferred to development\")\r\n\r\n---\r\n\r\n### Step 9: Update State File\r\n\r\n```markdown\r\n## Final State Update\r\n\r\n- Stage 13: ✅ Done\r\n- Status: Complete\r\n- Last Updated: {timestamp}\r\n- Package Quality: {score}/25\r\n- Total ADRs: {n}\r\n- Open Questions: {n} (carried into development)\r\n```\r\n\r\n---\r\n\r\n### Step 9b: Emit Feasibility / Cost-Risk Signal to AI-POLC (Architecture→Product cost loop)\r\n\r\nAI-POLC and AI-ADLC are same-layer peers, so this is a **direct downstream signal recorded in `adlc-state.md`** (no AI-FLO; AI-POLC reads it at its workspace-detection). This closes the real-world **Architecture → Product cost/risk re-prioritization loop**: architecture's feasibility verdict reshapes product prioritization (\"that epic is 3× the cost — reorder the roadmap\").\r\n\r\n**Produce relative bands, NEVER dollar estimates.** The signal is advisory effort/complexity bands + technical-risk flags, mapped to the product's epics/areas where identifiable:\r\n\r\n```markdown\r\n## Downstream Signals\r\n\r\n| Signal | Status |\r\n|--------|--------|\r\n| cost-risk-notes | available |\r\n\r\n### Feasibility / Cost-Risk (for AI-POLC re-prioritization)\r\n\r\n| Epic / Area | Effort Band | Technical Risk | Driver (why) |\r\n|-------------|:-----------:|:--------------:|--------------|\r\n| {epic or functional area} | {S / M / L / XL} | {🟢 low / 🟡 med / 🔴 high} | {e.g., \"new integration + multi-tenant isolation\", \"depends on unproven pattern\", \"high coupling to legacy\"} |\r\n\r\n> Bands are **relative complexity/effort**, derived from component count, integration complexity, NFR difficulty, and pattern novelty — not cost figures. Advisory input to WSJF Job Duration / value-effort scoring. AI-POLC consumes via `adlc-state.md` and applies the \"AP feasibility/cost-risk update\" re-prioritization trigger.\r\n```\r\n\r\nMap bands to the product areas/epics when the AP can be aligned to them; otherwise emit per architecture area and let AI-POLC associate. **Standalone-safe:** if no AI-POLC is present, the signal is simply recorded and unused. If the architecture changes later (reconciliation), refresh this table so POLC can re-score.\r\n\r\n---\r\n\r\n### Step 10: Present Final Summary\r\n\r\n```\r\n🎉 AI-ADLC WORKFLOW COMPLETE\r\n\r\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\r\n\r\n📦 Architecture Package for \"{system_name}\" is ready.\r\n\r\n📊 Package Summary:\r\n • Documents produced: {n}\r\n • ADRs recorded: {n}\r\n • C4 diagrams: {n} (L1 + L2 + L3)\r\n • Stages completed: {n}/13\r\n • Principles defined: {n}\r\n • Constraints documented: {n}\r\n • Open questions: {n} (for development phase)\r\n • Package quality: {score}/25 — {rating}\r\n\r\n📁 Package location: {output_root}/\r\n📋 Package README: {readme_path}\r\n📐 ADR folder: {adr_path}/ ({n} records)\r\n\r\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\r\n\r\n📌 Next Steps:\r\n 1. Review package with Technical Lead and senior developers\r\n 2. Resolve {n} open questions during first design sprint\r\n 3. Run AI-DWG to generate the development workspace from this Architecture Package\r\n 4. Begin AI-DLC v1 construction phase using this architecture as input\r\n 5. ADR register continues to grow during development (new decisions arise)\r\n\r\n🔀 **Chain Navigation (what's next in the AI-* Family):**\r\n • Sequential next: **AI-DWG** (`_DWG_`) — Development Workspace Generation\r\n • Or ask AI-FLO: type `_FLO_` for routing guidance based on your project state\r\n • Dashboard data: type `DAT__ pdlc/adlc` to update the family dashboard\r\n\r\n⚠️ **IMPORTANT: Start the next package (AI-DWG) in a NEW session.**\r\n Each AI-* package loads a full workflow into context;\r\n a fresh session keeps it fast and focused.\r\n\r\nThe architecture is ready for development team onboarding.\r\n\r\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\r\n```\r\n\r\n---\r\n\r\n## Edge Cases\r\n\r\n| Situation | Response |\r\n|-----------|----------|\r\n| Some stages were skipped | Note in README; explain why; assess if package is still viable |\r\n| ADRs have \"Proposed\" status (not accepted) | Flag as open decisions; recommend resolving before development start |\r\n| Contradictions found during assembly | Resolve with user before finalizing; never ship contradictory docs |\r\n| User stopped early | Produce partial package; clearly state what's missing and impact |\r\n| Architecture evolved during workflow (early decisions revised) | Verify all downstream docs updated; cross-reference check is critical |\r\n\r\n---\r\n\r\n## Output File\r\n\r\nSave to:\r\n- Numbered: `{output_root}/ARCHITECTURE_PACKAGE_README.md`\r\n- Phase folders: `{output_root}/ARCHITECTURE_PACKAGE_README.md`\r\n\r\n---\r\n\r\n## Assembly Quality Checklist\r\n\r\n| Check | Pass Criteria |\r\n|-------|---------------|\r\n| All documents present | Every stage produced its expected output |\r\n| Cross-references valid | Names, technologies, entities consistent across docs |\r\n| ADRs complete | All registered, properly formatted, cross-referenced |\r\n| Diagrams consistent | C4 levels align; technology labels match |\r\n| Principles respected | No document contradicts the Vision |\r\n| Constraints honored | No design violates constraints |\r\n| Open items tracked | Unresolved questions explicitly listed with context |\r\n| README navigable | A new reader can find their way through the package |\r\n| Actionable | A development team can start building from this package |\n\nFile v1.0.0:ai-adlc/ai-adlc-rule-details/common/content-validation.md\n\n\n# Content Validation\r\n\r\n## Purpose\r\n\r\nBefore creating or saving ANY architecture document, the AI MUST validate its content against the rules in this document. Architecture documents have additional quality requirements beyond standard document formatting — they must be technically consistent, constraint-compliant, and diagrammatically correct.\r\n\r\n---\r\n\r\n## Validation Checklist (Apply to Every Architecture Document)\r\n\r\n### 1. Document Metadata\r\n\r\nEvery architecture document MUST include:\r\n\r\n- [ ] Document title (H1 heading)\r\n- [ ] Document status (Draft / Review / Approved)\r\n- [ ] Version number\r\n- [ ] Date\r\n- [ ] Author role (e.g., \"CTO\", \"Architecture Lead\")\r\n- [ ] System/project name\r\n\r\n**Format:**\r\n```markdown\r\n# {Document Title}\r\n\r\n**Document Status:** {Draft / Review / Approved}\r\n**Version:** {n.n}\r\n**Date:** {YYYY-MM-DD}\r\n**Author:** {Role}\r\n```\r\n\r\n---\r\n\r\n### 2. Architectural Consistency Checks\r\n\r\nBefore saving any document, verify it is consistent with:\r\n\r\n| Check Against | What to Verify |\r\n|---------------|---------------|\r\n| Architecture Principles (Stage 3) | No recommendation contradicts a defined principle |\r\n| Constraints (Stage 3) | No technology or pattern violates a constraint |\r\n| System Context (Stage 4) | External systems referenced exist in C4 L1 |\r\n| Container list (Stage 5) | Containers referenced match those defined in C4 L2 |\r\n| Technology Stack (Stage 6) | Technologies mentioned match the selected stack |\r\n| ADRs | Decisions in documents match accepted ADR decisions |\r\n| Previous documents | No contradictions with earlier approved artifacts |\r\n\r\n**If inconsistency found:**\r\n1. Flag to user: \"This recommendation conflicts with {Principle Pn / Constraint Cn / ADR-nnn}. Should I adjust?\"\r\n2. Do NOT save until resolved\r\n3. If user overrides a principle → log in Architecture Workbook as a principle revision candidate\r\n\r\n---\r\n\r\n### 3. Constraint Compliance Gate\r\n\r\nCRITICAL: Every architectural recommendation MUST pass a constraint check:\r\n\r\n```\r\nFor each recommendation:\r\n For each constraint in state file:\r\n Does this recommendation violate this constraint?\r\n If YES → DO NOT RECOMMEND. Find an alternative that complies.\r\n If MAYBE → Flag to user with explanation.\r\n If NO → Proceed.\r\n```\r\n\r\n**Common constraint violations to catch:**\r\n- Recommending a cloud-managed service when \"on-premises only\" is a constraint\r\n- Recommending a commercial/proprietary tool when \"open-source only\" is a constraint\r\n- Recommending a pattern that can't meet stated performance targets\r\n- Recommending a technology the team doesn't have skills for (without acknowledging the gap)\r\n\r\n---\r\n\r\n### 4. Diagram Validation\r\n\r\nArchitecture documents heavily use diagrams. All diagrams must be validated.\r\n\r\n#### C4 Diagrams (Mermaid)\r\n\r\n```markdown\r\n```mermaid\r\nC4Context\r\n title {System Name} — System Context\r\n Person(user, \"User\", \"Description\")\r\n System(sys, \"System\", \"Description\")\r\n System_Ext(ext, \"External\", \"Description\")\r\n Rel(user, sys, \"Uses\", \"HTTPS\")\r\n```​\r\n```\r\n\r\n**C4 validation rules:**\r\n- [ ] Every Person/System has a description\r\n- [ ] Every Relationship has a label and protocol/technology\r\n- [ ] System names match those defined in earlier C4 levels\r\n- [ ] No orphan nodes (everything has at least one relationship)\r\n- [ ] Title matches the document context\r\n- [ ] Boundary boxes used for grouping where appropriate\r\n\r\n#### ASCII Diagrams (Alternative)\r\n\r\n```\r\n┌──────────────────┐ ┌──────────────────┐\r\n│ Component A │────────►│ Component B │\r\n│ (NestJS API) │ REST │ (PostgreSQL) │\r\n└──────────────────┘ └──────────────────┘\r\n```\r\n\r\n**ASCII diagram rules:**\r\n- [ ] Consistent character set (box-drawing OR simple +/- characters — don't mix)\r\n- [ ] Technology labels on boxes\r\n- [ ] Protocol/pattern labels on arrows\r\n- [ ] Under 100 characters wide\r\n- [ ] Text description provided below for accessibility\r\n\r\n#### Diagram Consistency Across Documents\r\n\r\n- [ ] C4 L2 containers must be a subset of what's inside C4 L1 system boundary\r\n- [ ] C4 L3 components must exist within a C4 L2 container\r\n- [ ] Technology labels on diagrams match ADR decisions\r\n- [ ] External system names consistent across all diagrams\r\n\r\n---\r\n\r\n### 5. ADR Validation\r\n\r\nEvery ADR file must:\r\n\r\n- [ ] Follow the template structure (Context, Drivers, Options, Decision, Rationale, Consequences)\r\n- [ ] Have a unique sequential number (no gaps, no duplicates)\r\n- [ ] Have a status (Proposed / Accepted / Deprecated / Superseded)\r\n- [ ] List at least 2 options that were genuinely considered\r\n- [ ] Include both positive AND negative consequences\r\n- [ ] Reference the decision drivers that justified the choice\r\n- [ ] Be cross-referenced in the parent architecture document\r\n- [ ] Be registered in the state file ADR register\r\n\r\n---\r\n\r\n### 6. Technical Accuracy\r\n\r\nArchitecture documents must be technically sound:\r\n\r\n| Check | What to Verify |\r\n|-------|---------------|\r\n| **Technology names** | Correct spelling, correct version numbers, official names (not nicknames) |\r\n| **Protocol references** | Correct protocol names (REST, gRPC, AMQP, not \"API calls\") |\r\n| **Port numbers** | Standard ports cited correctly (5432 for PostgreSQL, 6379 for Redis, etc.) |\r\n| **License claims** | If claiming \"MIT licensed\" — verify it's actually MIT (not MIT-0, not Apache, not AGPL) |\r\n| **Performance claims** | If citing benchmarks, qualify with \"under typical conditions\" or reference source |\r\n| **Ecosystem claims** | If claiming \"largest ecosystem\" or \"most popular\" — be accurate or hedge |\r\n| **Version currency** | Recommend current/LTS versions, not outdated ones |\r\n\r\n---\r\n\r\n### 7. Completeness Per Document Type\r\n\r\n#### Architecture Vision Document\r\n- [ ] Vision statement present (1-2 sentences)\r\n- [ ] Principles listed with ID, name, statement, and rationale\r\n- [ ] Constraints table with source and impact\r\n- [ ] Quality attributes with priority levels\r\n- [ ] Stakeholder concerns mapping\r\n\r\n#### C4 Diagrams (L1, L2, L3)\r\n- [ ] Diagram present (Mermaid or ASCII)\r\n- [ ] Every element described in a table below the diagram\r\n- [ ] Relationships documented with technology/protocol\r\n- [ ] Narrative explanation accompanies the diagram\r\n\r\n#### Technology Stack Document\r\n- [ ] Every container has technology selected\r\n- [ ] Each selection has rationale (even if brief)\r\n- [ ] Key selections reference their ADR\r\n- [ ] Alternatives considered (at least mentioned)\r\n- [ ] Stack compatibility verified (no conflicting choices)\r\n\r\n#### Security Architecture\r\n- [ ] Authentication methods defined\r\n- [ ] Authorization model defined\r\n- [ ] Encryption (at rest + in transit) specified\r\n- [ ] Audit logging approach defined\r\n- [ ] OWASP Top 10 considerations addressed (at minimum acknowledged)\r\n\r\n---\r\n\r\n### 8. Cross-Reference Integrity\r\n\r\nWhen an architecture document references another:\r\n\r\n- [ ] Referenced document exists (or is planned in a future stage)\r\n- [ ] ADR numbers cited exist in the ADR folder\r\n- [ ] Principle IDs (P1, P2, etc.) match those in the Vision document\r\n- [ ] Constraint IDs (if used) match state file\r\n- [ ] Container names match C4 L2 exactly (case-sensitive)\r\n- [ ] Component names match C4 L3 exactly\r\n\r\n**Format for references:**\r\n- Same folder: `See 04_Technology_Stack.md`\r\n- ADR reference: `See ADR/ADR-001_Technology_Stack.md`\r\n- Principle reference: `(Principle P3: {name})`\r\n- Future document: `_[To be detailed in Stage {n}]_`\r\n\r\n---\r\n\r\n### 9. File Naming Conventions\r\n\r\n| Rule | Example |\r\n|------|---------|\r\n| Numbered documents: 2-digit prefix | `01_Architecture_Vision.md` |\r\n| ADRs: ADR-{NNN}_{Title} | `ADR-001_Technology_Stack.md` |\r\n| Underscores for spaces | `Security_Identity_Architecture.md` |\r\n| No spaces in file names | ✅ `Data_Architecture.md` ❌ `Data Architecture.md` |\r\n| State file lowercase hyphenated | `adlc-state.md` |\r\n| Workbook title case | `Architecture_Workbook.md` |\r\n| Drafts marked | `03_Container_Diagram_DRAFT.md` |\r\n\r\n---\r\n\r\n### 10. Placeholder Hygiene\r\n\r\nArchitecture documents should have fewer placeholders than PMO documents (because the architect IS making the decisions), but some are acceptable:\r\n\r\n| Acceptable Placeholders | Context |\r\n|------------------------|---------|\r\n| `_[To be detailed in Stage {n}]_` | Forward reference to a future stage |\r\n| `_[Pending team input]_` | Requires developer team consultation |\r\n| `_[TBD — depends on ADR-{nnn}]_` | Blocked by an upstream decision |\r\n| `_[Performance target: validate in load test]_` | Architecture assumption to be verified |\r\n\r\n**Unacceptable in architecture documents:**\r\n- `_[TBD]_` without explanation (must say WHY it's TBD)\r\n- Placeholder for a technology choice (the CTO must decide, not defer)\r\n- Placeholder for a pattern (the architect must choose)\r\n\r\n---\r\n\r\n## Validation Failure Handling\r\n\r\nIf validation fails:\r\n\r\n1. **Constraint violation:** DO NOT save. Alert user. Propose compliant alternative.\r\n2. **Diagram syntax error:** Fix automatically if unambiguous. Re-validate.\r\n3. **Cross-reference mismatch:** Alert user. Ask which document is authoritative.\r\n4. **ADR inconsistency:** Flag the conflict. Ask if earlier ADR should be superseded.\r\n5. **Technical inaccuracy:** Correct silently if factual (e.g., wrong port number). Flag if judgment-based.\r\n\r\n---\r\n\r\n## Architecture Document vs. PMO Document Rules\r\n\r\n| Rule | Architecture Docs | PMO Docs (AI-PILC) |\r\n|------|------------------|---------------------|\r\n| Placeholders allowed? | Minimal — architect decides | More acceptable — decisions may be pending |\r\n| Diagrams required? | Yes — at least one per stage | Optional |\r\n| ADR cross-references? | Required for major decisions | N/A |\r\n| Technical specificity? | High — name specific technologies, versions, patterns | Low — high-level statements |\r\n| Constraint checking? | Mandatory on every recommendation | Applies to scope only |\n\nFile v1.0.0:ai-adlc/ai-adlc-rule-details/common/diagram-standards.md\n\n\n# Diagram Standards\r\n\r\n## Purpose\r\n\r\nAI-ADLC produces architectural diagrams at every decomposition level. This document defines the conventions, notation, quality rules, and format requirements for all diagrams produced during the workflow.\r\n\r\n---\r\n\r\n## C4 Model Overview\r\n\r\nAI-ADLC uses the [C4 Model](https://c4model.com/) for progressive architectural decomposition:\r\n\r\n```\r\nLevel 1: System Context — The system in its environment (who uses it, what it connects to)\r\nLevel 2: Container — Major deployable/runtime units inside the system\r\nLevel 3: Component — Internal modules/components within a container\r\nLevel 4: Code — (NOT produced by AI-ADLC — this is AI-DLC v1's territory)\r\n```\r\n\r\nEach level zooms in from the previous. A reader should be able to understand the system by reading L1 → L2 → L3 in sequence.\r\n\r\n---\r\n\r\n## Diagram Formats\r\n\r\nAI-ADLC supports two diagram formats. Choose based on user preference and platform support:\r\n\r\n### Option A: Mermaid (Preferred when platform renders it)\r\n\r\n```mermaid\r\nC4Context\r\n title System Name — System Context\r\n Person(actor, \"Actor Name\", \"Description\")\r\n System(sys, \"System Name\", \"Description\")\r\n Rel(actor, sys, \"Uses\", \"Protocol\")\r\n```\r\n\r\n### Option B: ASCII (Universal compatibility)\r\n\r\n```\r\n┌──────────────────┐ ┌──────────────────┐\r\n│ Component A │────────►│ Component B │\r\n│ (Technology) │ Protocol│ (Technology) │\r\n└──────────────────┘ └──────────────────┘\r\n```\r\n\r\n**Selection rule:** Use Mermaid as default. Fall back to ASCII if:\r\n- User requests it\r\n- Platform doesn't render Mermaid\r\n- Diagram is too complex for Mermaid's layout engine\r\n\r\n**Always provide:** A text narrative below every diagram explaining what it shows. Diagrams are not self-sufficient — they need accompanying explanation.\r\n\r\n---\r\n\r\n## C4 Level 1: System Context Diagram\r\n\r\n### What It Shows\r\n- The system as a single box\r\n- External actors (people) who interact with it\r\n- External systems that integrate with it\r\n- Relationships (who talks to whom, how)\r\n\r\n### Mermaid Template\r\n\r\n```mermaid\r\nC4Context\r\n title {System Name} — System Context (C4 Level 1)\r\n\r\n Person(actor1, \"Actor Name\", \"Brief role description\")\r\n Person(actor2, \"Actor Name\", \"Brief role description\")\r\n\r\n System(system, \"System Name\", \"One-sentence purpose\")\r\n\r\n System_Ext(ext1, \"External System\", \"Brief description\")\r\n System_Ext(ext2, \"External System\", \"Brief description\")\r\n\r\n Rel(actor1, system, \"Action verb\", \"Protocol/channel\")\r\n Rel(system, ext1, \"Action verb\", \"Protocol\")\r\n```\r\n\r\n### ASCII Template\r\n\r\n```\r\n ┌─────────────────────────────────────┐\r\n │ SYSTEM BOUNDARY │\r\n ┌────────────┐ │ │ ┌────────────────┐\r\n │ Actor 1 │─────►│ │─────►│ External Sys │\r\n │ (Role) │ HTTPS│ {System Name} │ API │ (Description) │\r\n └────────────┘ │ │ └────────────────┘\r\n │ │\r\n ┌────────────┐ │ │ ┌────────────────┐\r\n │ Actor 2 │─────►│ │◄─────│ External Sys │\r\n │ (Role) │ HTTPS│ │Events│ (Description) │\r\n └────────────┘ └─────────────────────────────────────┘ └────────────────┘\r\n```\r\n\r\n### Required Accompanying Table\r\n\r\n```markdown\r\n## External Actors\r\n\r\n| Actor | Description | Interaction |\r\n|-------|-------------|-------------|\r\n| {Name} | {Who they are} | {What they do with the system, via what channel} |\r\n\r\n## External Systems\r\n\r\n| System | Type | Interaction |\r\n|--------|------|-------------|\r\n| {Name} | {What kind of system} | {Direction + purpose + protocol} |\r\n```\r\n\r\n---\r\n\r\n## C4 Level 2: Container Diagram\r\n\r\n### What It Shows\r\n- The system decomposed into containers (deployable units)\r\n- Each container: name, technology choice, primary responsibility\r\n- Relationships between containers (protocol, data flow)\r\n- External actors/systems from L1 still visible (for context)\r\n\r\n### Mermaid Template\r\n\r\n```mermaid\r\nC4Container\r\n title {System Name} — Container Diagram (C4 Level 2)\r\n\r\n Person(actor, \"Actor\", \"Description\")\r\n\r\n System_Boundary(sys, \"System Name\") {\r\n Container(web, \"Web Application\", \"React\", \"Serves the user interface\")\r\n Container(api, \"API Server\", \"NestJS\", \"Business logic and REST API\")\r\n Container(db, \"Database\", \"PostgreSQL\", \"Persistent data storage\")\r\n Container(cache, \"Cache\", \"Redis/Valkey\", \"Session and config caching\")\r\n Container(queue, \"Job Queue\", \"BullMQ\", \"Async task processing\")\r\n }\r\n\r\n Rel(actor, web, \"Uses\", \"HTTPS\")\r\n Rel(web, api, \"Calls\", \"REST/JSON\")\r\n Rel(api, db, \"Reads/Writes\", \"SQL\")\r\n Rel(api, cache, \"Reads/Writes\", \"Redis protocol\")\r\n Rel(api, queue, \"Enqueues\", \"Redis protocol\")\r\n```\r\n\r\n### Required Accompanying Table\r\n\r\n```markdown\r\n## Containers\r\n\r\n| Container | Technology | Responsibility | Scaling |\r\n|-----------|-----------|----------------|---------|\r\n| {Name} | {Tech stack} | {Primary responsibility — 1 sentence} | {How it scales} |\r\n```\r\n\r\n### Container Naming Rules\r\n\r\n- Name by WHAT it does, not how (✅ \"API Server\" not ❌ \"NestJS App\")\r\n- Technology in parentheses or separate column\r\n- One clear responsibility per container (Single Responsibility at deployment level)\r\n\r\n---\r\n\r\n## C4 Level 3: Component Diagram\r\n\r\n### What It Shows\r\n- Internal structure of ONE container (typically the main application)\r\n- Modules, services, or major classes\r\n- Dependencies between components\r\n- External interfaces exposed by each component\r\n\r\n### Mermaid Template\r\n\r\n```mermaid\r\nC4Component\r\n title {Container Name} — Component Diagram (C4 Level 3)\r\n\r\n Container_Boundary(api, \"API Server\") {\r\n Component(auth, \"Auth Module\", \"Framework Module\", \"Authentication & authorization\")\r\n Component(orders, \"Orders Module\", \"Framework Module\", \"Order lifecycle management\")\r\n Component(tenant, \"Tenant Module\", \"Framework Module\", \"Tenant resolution & context\")\r\n Component(notify, \"Notification Service\", \"Service\", \"Email, in-app, broadcast\")\r\n }\r\n\r\n Rel(auth, tenant, \"Resolves tenant context\")\r\n Rel(orders, notify, \"Triggers notifications\")\r\n Rel(orders, auth, \"Checks permissions\")\r\n```\r\n\r\n### Required Accompanying Table\r\n\r\n```markdown\r\n## Components\r\n\r\n| Component | Type | Responsibility | Depends On |\r\n|-----------|------|----------------|-----------|\r\n| {Name} | {Module / Service / Library} | {What it does} | {Other components it requires} |\r\n```\r\n\r\n### Component Granularity Rules\r\n\r\n| Depth Level | Component Granularity |\r\n|-------------|----------------------|\r\n| Minimal | 5-10 major modules with responsibilities |\r\n| Standard | 10-20 components with dependency arrows |\r\n| Comprehensive | 15-30 components + interface contracts + sequence diagrams for key flows |\r\n\r\n---\r\n\r\n## Relationship Labels\r\n\r\nEvery arrow/relationship in a diagram MUST have:\r\n\r\n1. **Verb** — what action occurs (Uses, Calls, Reads, Writes, Publishes, Subscribes, Queries)\r\n2. **Technology/Protocol** — how the communication happens (REST, gRPC, SQL, WebSocket, AMQP, Event)\r\n\r\n**Good examples:**\r\n- `\"Calls\" \"REST/JSON\"`\r\n- `\"Reads/Writes\" \"SQL over TCP\"`\r\n- `\"Publishes events\" \"AMQP\"`\r\n- `\"Streams updates\" \"WebSocket\"`\r\n\r\n**Bad examples:**\r\n- ❌ `\"Connects to\"` (too vague — connects how?)\r\n- ❌ No label at all (what flows between them?)\r\n- ❌ `\"API\"` alone (what kind? REST? gRPC? GraphQL?)\r\n\r\n---\r\n\r\n## Color/Style Conventions (for Mermaid)\r\n\r\n| Element Type | C4 Type | Typical Color |\r\n|-------------|---------|:-------------:|\r\n| Person (actor) | Person | Blue |\r\n| Internal system/container | System / Container | Blue |\r\n| External system | System_Ext | Gray |\r\n| Database | ContainerDb | Blue with DB icon |\r\n| Message queue | ContainerQueue | Blue with queue icon |\r\n| System boundary | System_Boundary | Dashed border |\r\n\r\n---\r\n\r\n## Diagram Quality Checklist\r\n\r\nApply to EVERY diagram before saving:\r\n\r\n- [ ] Title present and matches document context\r\n- [ ] Every element has a name AND description\r\n- [ ] Every relationship has a verb AND protocol\r\n- [ ] No orphan nodes (everything connected to at least one other element)\r\n- [ ] Technology labels are specific (not generic)\r\n- [ ] Consistent naming with other diagrams (same system = same name everywhere)\r\n- [ ] Direction of arrows is meaningful (caller → callee, or data flow direction)\r\n- [ ] Diagram is not too crowded (max ~15 elements per diagram; split if larger)\r\n- [ ] Text narrative below explains what the diagram shows\r\n- [ ] Accompanying table provides details the diagram can't show\r\n\r\n---\r\n\r\n## Diagram Consistency Across Levels\r\n\r\n| Rule | Enforcement |\r\n|------|------------|\r\n| L1 system = the boundary box in L2 | Everything inside L2 must be inside L1's system |\r\n| L2 containers = the boundary boxes in L3 | L3 zooms into exactly one L2 container |\r\n| External systems in L1 = those referenced in L2/L3 | Same names, same descriptions |\r\n| Technology in L2 = technology in ADRs | If ADR says PostgreSQL, L2 must say PostgreSQL (not \"Database\") |\r\n| Actor names consistent L1-L2 | Same actor, same name, same description |\r\n\r\n---\r\n\r\n## Supplementary Diagrams (Optional)\r\n\r\nBeyond C4, AI-ADLC may produce these when depth requires:\r\n\r\n| Diagram Type | When Used | Format |\r\n|-------------|-----------|--------|\r\n| **Sequence diagram** | Complex interaction flows (auth flow, ticket lifecycle) | Mermaid `sequenceDiagram` |\r\n| **Deployment diagram** | Physical/virtual infrastructure topology | ASCII or Mermaid |\r\n| **Data flow diagram** | Sensitive data pathways (for security architecture) | ASCII |\r\n| **Entity relationship (ERD)** | Core data model relationships | Mermaid `erDiagram` or ASCII |\r\n| **State diagram** | Workflow/ticket state machines | Mermaid `stateDiagram-v2` |\r\n\r\n### Sequence Diagram Template\r\n\r\n```mermaid\r\nsequenceDiagram\r\n participant Client\r\n participant API\r\n participant DB\r\n \r\n Client->>API: POST /tickets\r\n API->>API: Validate + resolve tenant\r\n API->>DB: INSERT ticket\r\n DB-->>API: OK\r\n API-->>Client: 201 Created\r\n```\r\n\r\n### State Diagram Template\r\n\r\n```mermaid\r\nstateDiagram-v2\r\n [*] --> Open: Created\r\n Open --> InProgress: Assigned\r\n InProgress --> Pending: Awaiting info\r\n Pending --> InProgress: Info received\r\n InProgress --> Resolved: Fix applied\r\n Resolved --> Closed: Confirmed\r\n Resolved --> InProgress: Reopened\r\n Closed --> [*]\r\n```\r\n\r\n---\r\n\r\n## Diagram Don'ts\r\n\r\n| Don't | Why | Do Instead |\r\n|-------|-----|-----------|\r\n| Diagram without narrative | Readers may misinterpret | Always add explanatory text below |\r\n| Too many elements (>15) | Unreadable; cognitive overload | Split into multiple diagrams |\r\n| Generic labels (\"Service A\") | Meaningless to readers | Use real names and technologies |\r\n| Mixing abstraction levels | Confuses L2 with L3 concepts | One level per diagram |\r\n| Arrows without labels | Ambiguous communication | Always label with verb + protocol |\r\n| Inconsistent naming | \"API Server\" in L2 but \"Backend\" in L3 | Same name everywhere |\r\n| Screenshot of a whiteboard | Not version-controllable | Use text-based notation |\n\nFile v1.0.0:ai-adlc/ai-adlc-rule-details/common/process-overview.md\n\n\n# AI-ADLC Process Overview\r\n\r\n## What is AI-ADLC?\r\n\r\nAI-ADLC (AI-Driven Architecture Design Life Cycle) is a structured, interactive workflow that guides an AI assistant (acting as CTO/Chief Architect) and a human user through the complete process of designing a solution architecture — from receiving project requirements to delivering a professional, development-ready Architecture Package.\r\n\r\n---\r\n\r\n## The AI-* Family\r\n\r\n```\r\n╔════════════════ PORTFOLIO LAYER · scope = MANY projects ════════════════╗\r\n\r\n (optional)\r\n AI-ILC ⇢ AI-PILC ⇢ AI-PPM\r\n Decide it Initiate it Govern it (portfolio of N projects)\r\n\r\n╚═════════════════════════════════╤═══════════════════════════════════════╝\r\n │\r\n AI-FLO Route it — package-to-package\r\n │ flow on the edge between layers\r\n╔════════════════ PROJECT LAYER · scope = ONE project ════════════════════╗\r\n\r\n AI-POLC ──► AI-UXD ──► AI-ADLC ──► AI-DWG ──► AI-DLC v1 (build) ¹\r\n Own it Design UX Design it Prepare it ▲\r\n │\r\n AI-POLC ⇄ AI-DLC v1 (back-and-forth)┘\r\n AI-DLC v1 ⇢ AI-UXD+AI-POLC (feedback)\r\n\r\n AI-GCE + AI-TGE ──── alongside AI-DLC v1 (continuous quality) ────►\r\n Guard it Test it\r\n\r\n╚═════════════════════════════════════════════════════════════════════════╝\r\n ¹ AI-DLC v1 = Amazon's open-source build lifecycle (not ours; we feed it).\r\n```\r\n\r\n| Layer | Package | Type | Input | Output |\r\n|-------|---------|------|-------|--------|\r\n| Portfolio | **AI-ILC** ² | Interactive workflow (lifecycle) | Raw idea | Approved Idea Brief / Feature Brief |\r\n| Portfolio | **AI-PILC** | Interactive workflow (lifecycle) | Raw requirement | Project Initiation Package (PIP) |\r\n| Portfolio | **AI-PPM** ³ | Adaptive portfolio engine | Multiple PIPs + Approved Idea Briefs | Portfolio register + cross-project prioritization & governance |\r\n| Edge | **AI-FLO** ³ | Router / orchestration engine | Any package output marker | Routing decision + handoff to next package/layer |\r\n| Project | **AI-POLC** ³ | Interactive workflow (lifecycle) | PIP | Product Backlog Package (PBP) |\r\n| Project | **AI-UXD** ³ | Interactive workflow (lifecycle) | PIP + PBP | UX Design Package (UXP): personas/journeys, IA, user flows, design system + tokens, accessibility baseline |\r\n| Project | **AI-ADLC** | Interactive workflow (lifecycle) | PIP + PBP + UXP | Architecture Package (AP) |\r\n| Project | **AI-DWG** | One-time generator | AP + PBP + UXP | Ready-to-code development workspace (DW) |\r\n| Project | **AI-GCE** | Adaptive governance engine | DW (AI-DWG output) | Compliance enforcement layer |\r\n| Project | **AI-TGE** | Test governance engine | DW / build artifacts | Test governance & quality layer |\r\n| Project | **AI-DLC v1** ¹ | Interactive workflow (lifecycle) | DW + GCE + User Stories (from AI-POLC) | Working Software |\r\n\r\n> ¹ **AI-DLC v1** ([awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows)) is NOT our product. Our chain produces the workspace AI-DLC v1 consumes.\r\n> ² **AI-ILC** is an **optional pre-stage** (the funnel before the funnel). The chain still works without it for users who start at AI-PILC. `⇢` denotes the optional link.\r\n> ³ All packages in this table are **built**. AI-PPM (portfolio engine), AI-FLO (router), AI-POLC (product ownership lifecycle), and AI-UXD (UX design lifecycle) were the last four — completed June 2026. Within the Project layer, **AI-POLC, AI-UXD, and AI-ADLC run sequentially** (POLC→UXD→ADLC) — each feeds the next, culminating at AI-DWG which receives all three outputs (AP + PBP + UXP). **AI-GCE and AI-TGE run alongside AI-DLC v1** as continuous quality engines; **AI-POLC ⇄ AI-DLC v1** exchange backlog/acceptance throughout delivery; and **AI-DLC v1 runtime feedback flows back to both AI-UXD and AI-POLC**. Feedback loops (ADLC→POLC cost/risk, ADLC→UXD constraints) provide iterative refinement without changing the forward sequence.\r\n\r\nAI-ADLC sits between initiation and construction. It takes the \"what\" and \"why\" from AI-PILC and produces the \"how\" that AI-DWG transforms into a development workspace and AI-DLC v1 builds against.\r\n\r\n---\r\n\r\n## The Five Phases\r\n\r\n```\r\n┌─────────────────────────────────────────────────────────────────────────────┐\r\n│ AI-ADLC WORKFLOW │\r\n├─────────────────────────────────────────────────────────────────────────────┤\r\n│ │\r\n│ 🔵 FOUNDATION → Load context, assess complexity, define vision │\r\n│ 🟠 DECOMPOSITION → Define system boundaries and major containers │\r\n│ 🟡 DECISIONS → Select technology and key architectural patterns │\r\n│ 🟢 DESIGN → Detail internal architecture per concern │\r\n│ 🚀 ASSEMBLY → Consolidate, cross-check, produce final package │\r\n│ │\r\n├─────────────────────────────────────────────────────────────────────────────┤\r\n│ ↕ THROUGHOUT: ADRs produced at every decision point │\r\n│ ↕ THROUGHOUT: Architecture Workbook maintained continuously │\r\n└─────────────────────────────────────────────────────────────────────────────┘\r\n```\r\n\r\n---\r\n\r\n## Phase-Stage Mapping\r\n\r\n| Phase | Stage # | Stage Name | Execution | Key Output |\r\n|-------|:-------:|------------|:---------:|------------|\r\n| 🔵 FOUNDATION | 1 | Workspace Detection & Context Loading | ALWAYS | State file, output structure |\r\n| | 2 | Requirements Ingestion | ALWAYS (adaptive) | Architecture Requirements Summary |\r\n| | 3 | Architecture Vision & Principles | ALWAYS | Vision document, principles, constraints |\r\n| 🟠 DECOMPOSITION | 4 | System Context (C4 L1) | ALWAYS | Context diagram + document |\r\n| | 5 | Container Design (C4 L2) | ALWAYS | Container diagram + document |\r\n| 🟡 DECISIONS | 6 | Technology Stack Selection | ALWAYS | Tech stack doc + ADRs |\r\n| | 7 | Multi-Tenancy & Data Isolation | CONDITIONAL | Multi-tenancy doc + ADR |\r\n| | 8 | Security & Identity Architecture | ALWAYS | Security doc + ADRs |\r\n| 🟢 DESIGN | 9 | Data Architecture & Schema | ALWAYS | Data architecture doc |\r\n| | 10 | API Architecture & Contracts | ALWAYS | API architecture doc |\r\n| | 11 | Integration & Infrastructure | ALWAYS | Integration + Infrastructure docs |\r\n| | 12 | Component Design (C4 L3) | ALWAYS | Component diagram + document |\r\n| 🚀 ASSEMBLY | 13 | Architecture Package Assembly | ALWAYS | Package README + quality report |\r\n\r\n---\r\n\r\n## Adaptive Depth Model\r\n\r\n| Depth Level | When Applied | Behavior |\r\n|-------------|-------------|----------|\r\n| **Minimal** | Small system, proven patterns, clear requirements, <5 components | Brief documents; fewer ADRs; 1 iteration per stage |\r\n| **Standard** | Normal complexity, some design challenges, 5-15 components | Full document set; ADRs for key decisions; 1-2 iterations per stage |\r\n| **Comprehensive** | High complexity, novel patterns, strict constraints, >15 components | Detailed design with sequence diagrams; extensive ADRs; deep options analysis; multiple iterations |\r\n\r\n**Depth indicators (assessed at Stage 2):**\r\n\r\n| Factor | Minimal | Standard | Comprehensive |\r\n|--------|---------|----------|---------------|\r\n| Component count | <5 | 5-15 | >15 |\r\n| Integration points | 0-2 | 3-6 | >6 |\r\n| Multi-tenancy | No | Simple isolation | Complex isolation model |\r\n| Security requirements | Standard | Elevated (PII, compliance) | Strict (regulated, classified) |\r\n| Scale targets | <1K users | 1K-100K users | >100K users |\r\n| Team familiarity | Known patterns | Some new patterns | Novel/unproven approaches |\r\n| Deployment model | Standard cloud/on-prem | Hybrid or constrained | Air-gapped, compliance-heavy |\r\n\r\n---\r\n\r\n## The CTO Perspective\r\n\r\nThroughout the workflow, the AI operates as an experienced CTO/Chief Architect:\r\n\r\n| CTO Principle | What It Means in Practice |\r\n|---------------|--------------------------|\r\n| **Pragmatic over perfect** | Recommend what works reliably, not what's theoretically elegant |\r\n| **Team-aware** | Consider: \"Can this team build and maintain this for 5 years?\" |\r\n| **Operable first** | A system that can't be monitored, debugged, and scaled is a bad architecture |\r\n| **Proven patterns** | Prefer patterns with production track records; novel only when justified |\r\n| **Constraint-respectful** | Never recommend what violates stated constraints (budget, on-prem, team size) |\r\n| **Decision transparency** | Every choice has recorded rationale; future CTOs can understand \"why\" |\r\n| **Progressive detail** | Start big (C4 L1) and zoom in (C4 L3); don't detail internals before boundaries are set |\r\n\r\n---\r\n\r\n## Interaction Model\r\n\r\n### Gate Behavior\r\n\r\n```\r\n[AI produces architecture artifact] → [Presents to user] → [User reviews]\r\n │\r\n ┌────────────┼────────────┐\r\n ▼ ▼ ▼\r\n Approve Challenge Stop/\r\n (proceed) Decision Pause\r\n │ │ │\r\n ▼ ▼ ▼\r\n Next Stage Discuss & Save State\r\n Re-decide\r\n```\r\n\r\n### ADR Trigger\r\n\r\nAn ADR is produced when:\r\n- 2+ viable technology options were evaluated\r\n- A pattern choice has long-term implications\r\n- The decision would not be obvious to a future reader\r\n- The user asks \"why not X?\" — that's a signal an ADR is needed\r\n\r\n### User Commands (Available at Any Time)\r\n\r\n| Command | Effect |\r\n|---------|--------|\r\n| \"Skip this stage\" | Logs skip; moves on |\r\n| \"Go back to stage {n}\" | Revisits; state updated |\r\n| \"Show progress\" | Displays current state |\r\n| \"Show ADRs\" | Lists all ADRs with status |\r\n| \"Show workbook\" | Displays open questions |\r\n| \"Add a stage for {topic}\" | Inserts custom design stage |\r\n| \"Change depth\" | Adjusts remaining workflow |\r\n| \"Stop here\" | Saves state; generates partial package |\r\n| \"Why did we choose X?\" | Shows ADR rationale |\r\n\r\n---\r\n\r\n## Architecture Workbook\r\n\r\nA living document maintained throughout:\r\n\r\n| Section | Purpose |\r\n|---------|---------|\r\n| **Decision Backlog** | Questions that need answers (prioritized) |\r\n| **Open Questions** | Design issues not yet resolved |\r\n| **Discussion Notes** | Key conversation points captured |\r\n| **Resolved Items** | Decisions made — cross-referenced to ADRs |\r\n| **Architecture Sessions** | Log of what was covered in each session |\r\n\r\nThe Workbook is the \"thinking trail\" — it shows not just WHAT was decided but HOW we got there.\r\n\r\n---\r\n\r\n## Session Continuity\r\n\r\nAI-ADLC supports multi-session work:\r\n\r\n1. **State file** (`adlc-state.md`) persists all progress\r\n2. On session start, workflow detects state and offers to resume\r\n3. ADR register is preserved across sessions\r\n4. Architecture Workbook accumulates across all sessions\r\n5. C4 diagrams build progressively (L1 → L2 → L3 across sessions)\r\n\r\n---\r\n\r\n## What AI-ADLC Does NOT Do\r\n\r\n- ❌ Write code (that's AI-DLC v1's job)\r\n- ❌ Produce project management artifacts (that's AI-PILC's job)\r\n- ❌ Generate developer handoff packages or steering files (separate activity)\r\n- ❌ Make final decisions without user approval\r\n- ❌ Recommend technologies it can't justify with evidence\r\n- ❌ Ignore stated constraints because a \"better\" option exists outside them\r\n- ❌ Design in isolation — always references requirements as the source of truth","readmeExcerpt":"Skill: Pdlc Owner: mbmd Summary: AIFLC PDLC Family — 11 injectable workflow packages that guide AI coding agents through professional software delivery: idea evaluation → project initiation... Tags: latest:1.0.0 Version history: v1.0.0 | 2026-07-07T16:51:06.102Z | auto - Initial release of the AIPDLC skill, offering 11 modular, injectable workflow packages for AI-assisted professional software delivery. - Covers the ","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"File v1.0.0:ai-adlc/ai-adlc-rule-details/assembly/package-assembly.md\n\n\r\n# Architecture Package Assembly\r\n\r\n## Stage: 13 of 13\r\n## Phase: 🚀 ASSEMBLY\r\n## Execution: ALWAYS (Final Stage)\r\n\r\n---\r\n\r\n## Purpose\r\n\r\nConsolidate all architecture deliverables into a complete, cross-referenced, quality-checked Architecture Package (AP). Verify consistency across all documents and ADRs, identify unresolved questions, and produce a package README that serves as the table of contents and reading guide.\r\n\r\n---\r\n\r\n## Depth Adaptation\r\n\r\n| Depth | Assembly Behavior |\r\n|-------|------------------|\r\n| **Minimal** | Inventory check. Brief consistency scan. Package README with TOC and reading order. Quality score. |\r\n| **Standard** | Full cross-reference integrity check (containers ↔ tech stack ↔ ADRs ↔ security). Completeness audit. Open questions summary. Package README with full narrative. Quality score with per-category breakdown. |\r\n| **Comprehensive** | Deep consistency audit with explicit verification per document pair. Traceability matrix (requirement → principle → decision → ADR). Gap analysis against requirements. Executive architecture summary. Package README with detailed reading guide and decision map. Quality score with recommendations for future iterations. |\r\n\r\n---\r\n\r\n## Step-by-Step Execution\r\n\r\n### Step 1: Inventory All Artifacts\r\n\r\nScan the output directory and compile a complete inventory:"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"ai-adlc/ai-adlc-rule-details/extensions/README.md","content":"# AI-ADLC Extensions — How They Work\r\n\r\n## Overview\r\n\r\nExtensions are optional rule sets that add specialized architectural pattern guidance on top of the core AI-ADLC workflow. They activate via user opt-in during the workflow — only when your system needs a specific pattern.\r\n\r\n---\r\n\r\n## The Pattern\r\n\r\nEach extension has **two files**:\r\n\r\n```\r\nextensions/{name}/\r\n├── {name}.opt-in.md ← Lightweight prompt (always scanned at workflow start)\r\n└── {name}.md ← Full rules (loaded ONLY if user opts in)\r\n```\r\n\r\n| File | Size | Loaded When | Purpose |\r\n|------|:----:|-------------|---------|\r\n| `*.opt-in.md` | Small | Always (at workflow start) | Presents the opt-in question to the user |\r\n| `*.md` (rules) | Large | Only if user says \"Yes\" | Provides detailed design rules, verification criteria, and templates |\r\n\r\n---\r\n\r\n## The Flow\r\n\r\n```\r\nWorkflow Start\r\n │\r\n ▼\r\n[Scan extensions/ folder — load ONLY *.opt-in.md files]\r\n │\r\n ▼ (During relevant stage — Stage 5, 6, or 12)\r\n │\r\n[Present opt-in questions to user]\r\n │\r\n ├── User says \"Yes\" ──► Load {name}.md (full rules)\r\n │ └──► Enforce in subsequent stages\r\n │ └──► Verify compliance at stage completion\r\n │\r\n └── User says \"No\" ──► Never load full rules\r\n └──► Zero overhead; workflow proceeds normally\r\n```\r\n\r\n---\r\n\r\n## Example Walkthrough: DDD Tactical Patterns\r\n\r\n**Step 1 — Workflow Start:**\r\nAI scans `extensions/` directory. Finds `ddd-tactical/ddd-tactical.opt-in.md`. Reads it (lightweight — just a question prompt and applicability criteria).\r\n\r\n**Step 2 — During Stage 12 (Component Design):**\r\nThe workflow presents the opt-in question:\r\n\r\n> \"Would you like to apply DDD Tactical Patterns?\r\n> This adds: Aggregate design rules, Domain Events catalog, Anti-Corruption Layers, Value Objects.\r\n> (a) Yes (b) No\"\r\n\r\n**Step 3a — User says Yes:**\r\n- AI loads `ddd-tactical/ddd-tactical.md` (the full rules file)\r\n- Those rules become **enforced constraints** for the current and remaining stages\r\n- Example rule: \"Every aggregate must define its consistency boundary explicitly\"\r\n- At stage completion, the AI verifies compliance and reports findings\r\n- Non-compliance is a blocking finding — stage cannot complete until resolved\r\n\r\n**Step 3b — User says No:**\r\n- `ddd-tactical.md` is NEVER loaded into context\r\n- No context/token budget consumed\r\n- Workflow proceeds with standard component design from core rules\r\n- No enforcement, no compliance check for DDD patterns\r\n\r\n---\r\n\r\n## Why This Design?\r\n\r\n| Benefit | Explanation |\r\n|---------|-------------|\r\n| **Context-efficient** | Only load heavy rule files when actually needed — saves AI context budget |\r\n| **Non-intrusive** | Core workflow works perfectly without any extensions activated |\r\n| **User-controlled** | User decides which advanced patterns to apply — never forced |\r\n| **Additive** | Extensions ADD rules on top of core workflow — never "},{"path":"ai-adlc/README.md","content":"# AI-ADLC (AI-Driven Architecture Design Life Cycle)\r\n\r\n[![License: Apache 2.0](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](./LICENSE)\r\n\r\n**Version:** 1.1.0\r\n**Created By:** Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\r\n**Inspired By:** [awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows) (MIT-0)\r\n**License:** Apache 2.0 with Attribution Addendum — See `LICENSE` and `NOTICE`\r\n\r\n---\r\n\r\n## The AI-* PDLC Family\r\n\r\nAI-ADLC is part of **AIFLC** (AI Full Life Cycle) — the AI-* PDLC Family of injectable workflow packages.\r\n\r\n```\r\n╔════════════════ PORTFOLIO LAYER · scope = MANY projects ════════════════╗\r\n\r\n (optional)\r\n AI-ILC ⇢ AI-PILC ⇢ AI-PPM\r\n Decide it Initiate it Govern it (portfolio of N projects)\r\n\r\n╚═════════════════════════════════╤═══════════════════════════════════════╝\r\n │\r\n AI-FLO Route it — package-to-package\r\n │ flow on the edge between layers\r\n╔════════════════ PROJECT LAYER · scope = ONE project ════════════════════╗\r\n\r\n AI-POLC ──► AI-UXD ──► AI-ADLC ──► AI-DWG ──► AI-DLC v1 (build) ¹\r\n Own it Design UX Design it Prepare it ▲\r\n │\r\n AI-POLC ⇄ AI-DLC v1 (back-and-forth)┘\r\n AI-DLC v1 ⇢ AI-UXD+AI-POLC (feedback)\r\n\r\n AI-GCE + AI-TGE ──── alongside AI-DLC v1 (continuous quality) ────►\r\n Guard it Test it\r\n\r\n╚═════════════════════════════════════════════════════════════════════════╝\r\n ¹ AI-DLC v1 = Amazon's open-source build lifecycle (not ours; we feed it).\r\n```\r\n\r\n| Layer | Package | Type | Input | Output |\r\n|-------|---------|------|-------|--------|\r\n| Portfolio | **AI-ILC** ² | Interactive workflow (lifecycle) | Raw idea | Approved Idea Brief / Feature Brief |\r\n| Portfolio | **AI-PILC** | Interactive workflow (lifecycle) | Raw requirement | Project Initiation Package (PIP) |\r\n| Portfolio | **AI-PPM** ³ | Adaptive portfolio engine | Multiple PIPs + Approved Idea Briefs | Portfolio register + cross-project prioritization & governance |\r\n| Edge | **AI-FLO** ³ | Router / orchestration engine | Any package output marker | Routing decision + handoff to next package/layer |\r\n| Project | **AI-POLC** ³ | Interactive workflow (lifecycle) | PIP | Product Backlog Package (PBP) |\r\n| Project | **AI-UXD** ³ | Interactive workflow (lifecycle) | PIP + PBP | UX Design Package (UXP): personas/journeys, IA, user flows, design system + tokens, accessibility baseline |\r\n| Project | **AI-ADLC** | Interactive workflow (lifecycle) | PIP + PBP + UXP | Architecture Package (AP) |\r\n| Project | **AI-DWG** | One-time generator | AP + PBP + UXP | Ready-to-code development workspace (DW) |\r\n| Project | **AI-GCE** | Adaptive governance engine | DW (AI-DWG output) | Compliance enforcement layer |\r\n| Project | **AI-TGE** | Test governance engine | DW / build artifac"},{"path":"ai-dfe/README.md","content":"# AI-DFE — AI-Driven Data Fabric\r\n\r\n[![License: Apache 2.0](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](./LICENSE)\r\n\r\n**Version:** 1.0.0\r\n**Created By:** Maheri — [LinkedIn](https://www.linkedin.com/in/mohammad-maheri-8399565b)\r\n**License:** Apache 2.0 with Attribution\r\n\r\n---\r\n\r\n## What Is AI-DFE?\r\n\r\nAI-DFE is the data layer of the AI-* PDLC Family. It gathers the scattered markdown outputs every package produces, shapes them into structured JSON per consumer needs, and distributes them to one read-point — so dashboards, extensions, and reports get clean, machine-readable data without ever knowing where the raw files live.\r\n\r\n**In one sentence:** AI-DFE turns the family's scattered, human-readable outputs into a single governed, machine-readable data surface — gather, shape, distribute.\r\n\r\n**Tagline:** *Fabric it.*\r\n\r\n---\r\n\r\n## Family Position\r\n\r\nAI-DFE is part of **AIFLC** (AI Full Life Cycle) and the **AI-* PDLC Family**. Like AI-FLO, it lives in **every family** as a continuous adaptive engine — but where FLO routes decisions, DFE fabrics data. It owns one folder, `pdlc-ws/data/`, and is its sole writer.\r\n\r\n```\r\n╔════════════════ PORTFOLIO LAYER · scope = MANY projects ════════════════╗\r\n\r\n (optional)\r\n AI-ILC ⇢ AI-PILC ⇢ AI-PPM\r\n Decide it Initiate it Govern it (portfolio of N projects)\r\n\r\n╚═════════════════════════════════╤═══════════════════════════════════════╝\r\n │\r\n AI-FLO Route it — package-to-package\r\n │ flow on the edge between layers\r\n╔════════════════ PROJECT LAYER · scope = ONE project ════════════════════╗\r\n\r\n AI-POLC ──► AI-UXD ──► AI-ADLC ──► AI-DWG ──► AI-DLC v1 (build) ¹\r\n Own it Design UX Design it Prepare it ▲\r\n │\r\n AI-POLC ⇄ AI-DLC v1 (back-and-forth)┘\r\n AI-DLC v1 ⇢ AI-UXD+AI-POLC (feedback)\r\n\r\n AI-GCE + AI-TGE ──── alongside AI-DLC v1 (continuous quality) ────►\r\n Guard it Test it\r\n\r\n╚═════════════════════════════════════════════════════════════════════════╝\r\n ¹ AI-DLC v1 = Amazon's open-source build lifecycle (not ours; we feed it).\r\n```\r\n\r\n| Layer | Package | Type | Input | Output |\r\n|-------|---------|------|-------|--------|\r\n| Portfolio | **AI-ILC** ² | Interactive workflow (lifecycle) | Raw idea | Approved Idea Brief / Feature Brief |\r\n| Portfolio | **AI-PILC** | Interactive workflow (lifecycle) | Raw requirement | Project Initiation Package (PIP) |\r\n| Portfolio | **AI-PPM** ³ | Adaptive portfolio engine | Multiple PIPs + Approved Idea Briefs | Portfolio register + cross-project prioritization & governance |\r\n| Edge | **AI-FLO** ³ | Router / orchestration engine | Any package output marker | Routing decision + handoff to next package/layer |\r\n| Project | **AI-POLC** ³ | Interactive workflow (lifecycle) | PIP | Product Backlog Package (PBP) |\r\n| Project | **AI"},{"path":"ai-dwg/ai-dwg-rule-details/templates/examples/README.md","content":"\r\n---\r\ngeneratedBy: AI-DWG\r\ngeneratedVersion: \"{version}\"\r\nsource: \"AI-ADLC AP (tech patterns) + AI-UXD UXP (UI component patterns)\"\r\ngeneratedOn: \"{generation-date}\"\r\nownership: hybrid\r\n---\r\n# Template: examples/ Directory (SKELETON)\r\n\r\n**Generate IF:** At least one peer input is present (any valid input set).\r\n**Cluster:** Cross-cluster (tech patterns from ADLC, UI patterns from UXD)\r\n**Purpose:** Provide AI-DLC v1 and developers with copy-paste starter patterns that demonstrate the correct way to implement common code patterns in this workspace. Seeded from architecture decisions (ADLC) and design system components (UXD).\r\n\r\n## Directory Structure\r\n\r\n```\r\n{workspace-root}/examples/\r\n├── README.md ← This file (index + usage guide)\r\n├── api-endpoint.{ext} ← IF ADLC: REST endpoint boilerplate\r\n├── database-query.{ext} ← IF ADLC: Query pattern (ORM/raw)\r\n├── service-layer.{ext} ← IF ADLC: Service/use-case pattern\r\n├── error-handling.{ext} ← IF ADLC: Error pattern\r\n├── test-unit.{ext} ← IF ADLC: Unit test pattern\r\n├── test-integration.{ext} ← IF ADLC: Integration test pattern\r\n└── ui-component.{ext} ← IF UXD: Component using design system tokens\r\n```\r\n\r\n## Template: examples/README.md\r\n\r\n```markdown\r\n\r\n\r\n# Code Examples\r\n\r\nStarter patterns demonstrating the correct implementation approach for this workspace. These examples are **prescriptive** — they show the ONE correct way, not alternatives.\r\n\r\n## How to Use\r\n\r\n1. Find the pattern closest to what you're building\r\n2. Copy the file as a starting point\r\n3. Replace placeholders with your implementation\r\n4. Follow the inline comments for guidance\r\n\r\n## Available Patterns\r\n\r\n| Pattern | File | Source | When to Use |\r\n|---------|------|--------|-------------|\r\n| API Endpoint | `api-endpoint.{ext}` | AP: API Architecture + Tech Stack | New REST/GraphQL endpoint |\r\n| Database Query | `database-query.{ext}` | AP: Data Architecture + Tech Stack | New data access method |\r\n| Service Layer | `service-layer.{ext}` | AP: Component Design patterns | New business logic unit |\r\n| Error Handling | `error-handling.{ext}` | AP: Error patterns + API standards | Custom error scenarios |\r\n| Unit Test | `test-unit.{ext}` | AP: Testing strategy + Tech Stack | New unit under test |\r\n| Integration Test | `test-integration.{ext}` | AP: Testing strategy | New integration scenario |\r\n| UI Component | `ui-component.{ext}` | UXP: Design System + Component Inventory | New frontend component |\r\n\r\n## Rules\r\n\r\n- MUST follow these patterns — don't invent new approaches\r\n- MUST use the project's design tokens (see `design-system.md`) for UI components\r\n- MUST follow naming conventions (see `naming-conventions.md`)\r\n- Patterns a"},{"path":"ai-dwg/README.md","content":"# AI-DWG — AI-Driven Workspace Generator\r\n\r\n[![License: Apache 2.0](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](./LICENSE)\r\n\r\n**Version:** 1.0.0\r\n\r\n**Transform architecture into a ready-to-code development workspace.**\r\n\r\n---\r\n\r\n## What It Does\r\n\r\nAI-DWG composes a complete development workspace from one or more design-time peer inputs — Architecture Package (from AI-ADLC), Product Backlog Package (from AI-POLC), and/or UX Design Package (from AI-UXD). Any non-empty combination is valid; none is privileged. It generates Kiro steering files, project instructions, repository structure, configuration files, and operational documents — scoped to the input clusters actually present.\r\n\r\n**Input:** Any non-empty subset of {Architecture Package (AI-ADLC), Product Backlog Package (AI-POLC), UX Design Package (AI-UXD)} — all structured markdown documents. At least one is required; the more you provide, the richer the workspace.\r\n**Output:** Ready-to-code workspace with governance, structure, and rules\r\n\r\n---\r\n\r\n## The AI-* PDLC Family\r\n\r\nAI-DWG is part of **AIFLC** (AI Full Life Cycle) — the AI-* PDLC Family of injectable workflow packages.\r\n\r\n```\r\n╔════════════════ PORTFOLIO LAYER · scope = MANY projects ════════════════╗\r\n\r\n (optional)\r\n AI-ILC ⇢ AI-PILC ⇢ AI-PPM\r\n Decide it Initiate it Govern it (portfolio of N projects)\r\n\r\n╚═════════════════════════════════╤═══════════════════════════════════════╝\r\n │\r\n AI-FLO Route it — package-to-package\r\n │ flow on the edge between layers\r\n╔════════════════ PROJECT LAYER · scope = ONE project ════════════════════╗\r\n\r\n AI-POLC ──► AI-UXD ──► AI-ADLC ──► AI-DWG ──► AI-DLC v1 (build) ¹\r\n Own it Design UX Design it Prepare it ▲\r\n │\r\n AI-POLC ⇄ AI-DLC v1 (back-and-forth)┘\r\n AI-DLC v1 ⇢ AI-UXD+AI-POLC (feedback)\r\n\r\n AI-GCE + AI-TGE ──── alongside AI-DLC v1 (continuous quality) ────►\r\n Guard it Test it\r\n\r\n╚═════════════════════════════════════════════════════════════════════════╝\r\n ¹ AI-DLC v1 = Amazon's open-source build lifecycle (not ours; we feed it).\r\n```\r\n\r\n| Layer | Package | Type | Input | Output |\r\n|-------|---------|------|-------|--------|\r\n| Portfolio | **AI-ILC** ² | Interactive workflow (lifecycle) | Raw idea | Approved Idea Brief / Feature Brief |\r\n| Portfolio | **AI-PILC** | Interactive workflow (lifecycle) | Raw requirement | Project Initiation Package (PIP) |\r\n| Portfolio | **AI-PPM** ³ | Adaptive portfolio engine | Multiple PIPs + Approved Idea Briefs | Portfolio register + cross-project prioritization & governance |\r\n| Edge | **AI-FLO** ³ | Router / orchestration engine | Any package output marker | Routing decision + handoff to next package/layer |\r\n| Project | **AI-POLC** ³ | Interactive workflow (lifecycle) | PIP | Product Backlog Package ("}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"AIFLC PDLC Family — 11 injectable workflow packages that guide AI coding agents through professional software delivery: idea evaluation → project initiation... Skill: Pdlc Owner: mbmd Summary: AIFLC PDLC Family — 11 injectable workflow packages that guide AI coding agents through professional software delivery: idea evaluation → project initiation... Tags: latest:1.0.0 Version history: v1.0.0 | 2026-07-07T16:51:06.102Z | auto - Initial release of the AIPDLC skill, offering 11 modular, injectable workflow packages for AI-assisted professional software delivery. - Covers the","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1459,"uniquenessScore":46,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T04:11:01.573Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T04:11:01.573Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T07:36:28.460Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}