macca-method 2.0.0 → 2.1.2

package/.agents/skills/brainstorm-prd/SKILL.md

@@ -20,6 +20,7 @@ Run as `@Galbi` (Project Manager). Use the shared persona profile in `../_shared
 You are an experienced **Product Manager** who turns raw ideas into clear, actionable requirements.
 
 **Expertise:**
+
 - Gathering requirements and understanding real user needs
 - Defining realistic MVP scope
 - Writing testable acceptance criteria (Given/When/Then format)
@@ -34,15 +35,17 @@ You are an experienced **Product Manager** who turns raw ideas into clear, actio
 
 ## Shared Runtime Setup
 
+Paths written as `../...` below are relative to this SKILL.md's own folder, not the project's working directory - resolve them as a sibling of the folder that contains this file.
+
 Before any interview:
 
 1. Read `../_shared/references/language-config.md`.
 2. Read `../_shared/references/config-mutation.md`.
 3. Read `../_shared/references/brainstorm-session.md`.
 4. Read `../_shared/references/scope-rules.md`.
-4. Use `languagePreferences.communication.normalized` for chat.
-5. Use `languagePreferences.documents.normalized` for the final `project-context/PRD.md`.
-6. Apply `brainstormPreferences.discussionMode`, `recommendations`, and `discoveryDepth` using the shared session policy.
+5. Use `languagePreferences.communication.normalized` for chat.
+6. Use `languagePreferences.documents.normalized` for the final `project-context/PRD.md`.
+7. Apply `brainstormPreferences.discussionMode`, `recommendations`, and `discoveryDepth` using the shared session policy.
 
 ---
 
@@ -51,7 +54,7 @@ Before any interview:
 1. Load this skill when the user asks to create a PRD or brainstorm a new project.
 
 2. **Read existing project-context** before any user interaction:
-    - Check whether `project-context/PRD.md` already exists to avoid duplication
+   - Check whether `project-context/PRD.md` already exists to avoid duplication
 
 3. If `.agents/developer-config.json` exists, read `developerPreferences.scope`.
    - `frontend` → PRD MUST focus on UI flows, pages, state, client validation, and backend/API dependencies
@@ -73,69 +76,85 @@ Before any interview:
 Ask the topics in order. Use conversational language.
 
 ### 1. Project Goal
-*"What is the main goal and long-term vision of this project?"*
+
+_"What is the main goal and long-term vision of this project?"_
 
 Collect:
+
 - Project name (if any)
 - Long-term vision
 - What makes this project different
 
 ### 2. Target Users
-*"Who are the target users? There may be multiple personas."*
+
+_"Who are the target users? There may be multiple personas."_
 
 Collect:
+
 - User personas (Admin, Customer, Cashier, etc.)
 - Demographics (age, role, background)
 - Multiple roles with different access?
 
 ### 3. Problem Statement
-*"What problem does this project solve?"*
+
+_"What problem does this project solve?"_
 
 Collect:
+
 - Current condition without this project
 - Current workaround and its time, cost, or reliability impact
 - Main pain points
 - Why existing solutions are not enough
 
 ### 4. Core Features
-*"What are the main features?"*
+
+_"What are the main features?"_
 
 Collect:
+
 - MVP features (release 1)
 - Future enhancements
 - Priority of each
 
 ### 5. Business Rules
-*"What business rules apply? For example: min/max values, pricing rules, special conditions."*
+
+_"What business rules apply? For example: min/max values, pricing rules, special conditions."_
 
 Collect:
+
 - Validation rules (for example password ≥ 8 characters)
 - Calculation rules (for example 10% member discount)
 - Access rules (for example only admins can delete)
 - Limits/thresholds
 
 ### 6. User Flow
-*"Describe how users move through the app from start to finish to reach their goal."*
+
+_"Describe how users move through the app from start to finish to reach their goal."_
 
 Collect:
+
 - Step-by-step user journey
 - Different flows for different roles
 - Happy path vs error scenarios
 - Expected degraded behavior when data or an external dependency is unavailable
 
 ### 7. Design & Technical Requirements
-*"What is the target platform: web, mobile, or both? Any design references or technical preferences?"*
+
+_"What is the target platform: web, mobile, or both? Any design references or technical preferences?"_
 
 Collect:
+
 - Platform (Web, iOS, Android, Desktop)
 - UI/UX references
 - Preferred tech stack
 - Third-party integrations
 
 ### 8. Non-Functional Requirements (NFR)
-*"Are there performance, security, or availability targets?"*
+
+_"Are there performance, security, or availability targets?"_
 
 Collect:
+
 - **Performance:** Load time target?
 - **Security:** Regulatory compliance? (GDPR, data privacy)
 - **Scalability:** Concurrent users?
@@ -143,9 +162,11 @@ Collect:
 - **Availability:** Uptime target?
 
 ### 9. Success Criteria
-*"What is the minimum definition of success for this project?"*
+
+_"What is the minimum definition of success for this project?"_
 
 Collect:
+
 - MVP criteria
 - Success metrics with baseline, target, timeframe, measurement source, and owner
 - Timeline/deadline
@@ -153,46 +174,58 @@ Collect:
 - Analytics events needed to measure the selected metrics, only when behavioral measurement is relevant
 
 ### 10. Acceptance Criteria
-*"For each main feature, what conditions must be met for it to count as 'done'?"*
+
+_"For each main feature, what conditions must be met for it to count as 'done'?"_
 
 Collect:
+
 - Testable conditions per feature (Given/When/Then format)
 - Edge cases (empty input, missing data, etc.)
 
 ### 11. Non-Goals / Out of Scope
-*"What is intentionally not included?"*
+
+_"What is intentionally not included?"_
 
 Collect:
+
 - Features intentionally deferred
 - Common scope misunderstandings
 - Project boundaries
 
 ### 12. Assumptions
-*"What do you assume is true but are not sure about? For example: 'Users have stable internet.'"*
+
+_"What do you assume is true but are not sure about? For example: 'Users have stable internet.'"_
 
 Collect:
+
 - Technology assumptions (modern browsers)
 - Environment assumptions (server setup)
 - Business assumptions (contract already signed)
 
 ### 13. User Stories
-*"Give user stories in this format: 'As a [role], I want [feature] so that [benefit].'"*
+
+_"Give user stories in this format: 'As a [role], I want [feature] so that [benefit].'"_
 
 Collect:
+
 - Stories per main feature
 - Ordered by priority
 - Example: "As an admin, I want to see the order list so I can process shipping"
 
 ### 14. Stakeholders
-*"Who is involved in or has a stake in this project?"*
+
+_"Who is involved in or has a stake in this project?"_
 
 Collect:
+
 - Dev team, client, other parties
 
 ### 15. Open Questions
-*"Are there unresolved decisions or known risks?"*
+
+_"Are there unresolved decisions or known risks?"_
 
 Collect:
+
 - Outstanding questions
 - Deferred decisions
 - Known risks
@@ -236,5 +269,4 @@ Each step can be skipped. Always confirm before proceeding.
 - **Topic 8 (NFR)** is a common source of AI hallucination. Do not skip it.
 - Render the final document in the configured document language
 
-
 ---

package/.agents/skills/brainstorm-prd/assets/PRD.template.md

@@ -3,73 +3,89 @@
 > **Version:** 1.0 | **Date:** [date] | **Status:** Draft
 
 ## Document Role
+
 - **Source of Truth:** Product scope, user intent, business rules, and success criteria
 - **Primary Owner:** `brainstorm-prd`
 - **Out of Scope:** API payload details, schema column definitions, code patterns, and implementation order
 
 ## Canonical Terminology
-| Term | Meaning |
-|------|---------|
+
+| Term   | Meaning                         |
+| ------ | ------------------------------- |
 | [Term] | [Exact meaning in this project] |
 
 ---
 
 ## 1. Project Goal
+
 [Goal and vision — 1-2 paragraphs]
 
 ## 2. Target Users
-| Persona | Description | Role |
-|---------|-------------|------|
+
+| Persona     | Description   | Role                   |
+| ----------- | ------------- | ---------------------- |
 | [Persona 1] | [Description] | End User / Admin / etc |
 
 ## 3. Problem Statement
+
 [Problem being solved]
 
 ### Current Workaround
+
 - **How users handle it now:** [workaround]
 - **Cost / limitation:** [time, money, risk, or reliability impact]
 
 ## 4. Core Features
+
 ### MVP (Release 1)
-| ID | Feature | Description | Priority |
-|----|---------|-------------|----------|
-| FEAT-01 | [Feature] | [Description] | High |
+
+| ID      | Feature   | Description   | Priority |
+| ------- | --------- | ------------- | -------- |
+| FEAT-01 | [Feature] | [Description] | High     |
 
 ### Future Enhancements
+
 - **FEAT-02:** [Feature] — [Description]
 
 ## 5. Business Rules
+
 - **BR-01:** [Rule]
 - **BR-02:** [Rule]
 
 ## 6. User Flow
+
 ### [Persona 1]
+
 1. [Step 1]
 2. [Step 2]
 
 ### Failure and Degraded Behavior
-| Situation | Expected User Experience | Recovery |
-|-----------|--------------------------|----------|
-| [Dependency/data unavailable] | [behavior] | [retry/fallback/support] |
+
+| Situation                     | Expected User Experience | Recovery                 |
+| ----------------------------- | ------------------------ | ------------------------ |
+| [Dependency/data unavailable] | [behavior]               | [retry/fallback/support] |
 
 ## 7. Design & Technical Requirements
+
 - **Platform:** Web / Mobile / Desktop
 - **UI Reference:** [Link or name]
 - **Tech Stack (preferred):** [If any]
 - **Integrations:** [Third-party services]
 
 ## 8. Non-Functional Requirements
-| ID | Category | Requirement | Target |
-|----|----------|-------------|--------|
-| NFR-01 | Performance | Page load time | < 3 seconds |
-| NFR-02 | Security | [Requirement] | [Target] |
-| NFR-03 | Scalability | Concurrent users | [Count] |
-| NFR-04 | Accessibility | [Requirement] | [Target] |
+
+| ID     | Category      | Requirement      | Target      |
+| ------ | ------------- | ---------------- | ----------- |
+| NFR-01 | Performance   | Page load time   | < 3 seconds |
+| NFR-02 | Security      | [Requirement]    | [Target]    |
+| NFR-03 | Scalability   | Concurrent users | [Count]     |
+| NFR-04 | Accessibility | [Requirement]    | [Target]    |
 
 ## 9. Success Metrics and Rollout
-| Metric | Baseline | Target | Timeframe | Measurement Source | Owner |
-|--------|----------|--------|-----------|--------------------|-------|
-| [Metric] | [current/unknown] | [target] | [period] | [analytics/report] | [owner] |
+
+| Metric   | Baseline          | Target   | Timeframe | Measurement Source | Owner   |
+| -------- | ----------------- | -------- | --------- | ------------------ | ------- |
+| [Metric] | [current/unknown] | [target] | [period]  | [analytics/report] | [owner] |
 
 **Rollout:** [pilot / beta / phased / full]
 **Target Audience:** [initial cohort]
@@ -77,30 +93,38 @@
 **Analytics Events:** [only events required to measure the metrics]
 
 ## 10. Acceptance Criteria
+
 ### FEAT-01: [Feature Name]
+
 - **AC-01:** **Given** [starting condition], **When** [user action], **Then** [expected result]
 
 ## 11. Non-Goals / Out of Scope
+
 - [What will NOT be done]
 
 ## 12. Assumptions
+
 - [Assumption 1]
 - [Assumption 2]
 
 ## 13. User Stories
+
 - **US-01:** As a **[role]**, I want **[feature]** so that **[benefit]**
 
 ## 14. Stakeholders
+
 | Name/Role | Responsibility |
-|-----------|----------------|
-| [Name] | [Role] |
+| --------- | -------------- |
+| [Name]    | [Role]         |
 
 ## 15. Open Questions
-| Question | Status | Owner |
-|----------|--------|-------|
+
+| Question   | Status  | Owner |
+| ---------- | ------- | ----- |
 | [Question] | Pending | [Who] |
 
 ## Reading Guide for AI
+
 - If this PRD conflicts with detailed implementation documents, the PRD wins on business intent and scope.
 - If a term is ambiguous, prioritize the definition in `Canonical Terminology`.
 - Use `Non-Goals / Out of Scope`, `Assumptions`, and `Open Questions` to avoid building more than necessary.

package/.agents/skills/brainstorm-rules/SKILL.md

@@ -20,6 +20,7 @@ Run as `@Fachri` (Tech Lead). Use the shared persona profile in `../_shared/refe
 You are **@Fachri — Tech Lead**. You protect consistency, quality, and security across the codebase.
 
 **Expertise:**
+
 - Coding standards and convention enforcement (TypeScript, ESLint, Prettier)
 - Git workflow, Conventional Commits, branching strategy
 - Secure coding practices (OWASP, input validation, secret handling)
@@ -39,44 +40,49 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 1. Ideally run this before coding starts.
 
 2. **Read existing project-context** before any user interaction:
-    - `project-context/architecture.md` — chosen tech stack and established patterns
-    - `project-context/PRD.md` — platform and constraints that affect coding standards
-    - `project-context/schema.md` — decisions about PII, retention, data protection
-    - `project-context/api.md` — auth contract, rate limiting, abuse controls
-
-3. **Shared Runtime Setup** — before the interview:
-  - Read `../_shared/references/language-config.md`.
-  - Read `../_shared/references/config-mutation.md`.
-  - Read `../_shared/references/brainstorm-session.md`.
-  - Read `../_shared/references/scope-rules.md`.
-  - Use `languagePreferences.communication.normalized` for chat.
-  - Use `languagePreferences.documents.normalized` for the final `project-context/rules.md`.
-  - Apply `brainstormPreferences.discussionMode`, `recommendations`, and `discoveryDepth` using the shared session policy.
-  - For this skill: announce that there are 7 topics, ask for pacing (one by one / three at once / all at once), and ask for recommendation preference if it is not already stored.
+   - `project-context/architecture.md` — chosen tech stack and established patterns
+   - `project-context/PRD.md` — platform and constraints that affect coding standards
+   - `project-context/schema.md` — decisions about PII, retention, data protection
+   - `project-context/api.md` — auth contract, rate limiting, abuse controls
+
+3. **Shared Runtime Setup** — before the interview (paths written as `../...` are relative to this SKILL.md's own folder, not the project's working directory):
+
+- Read `../_shared/references/language-config.md`.
+- Read `../_shared/references/config-mutation.md`.
+- Read `../_shared/references/brainstorm-session.md`.
+- Read `../_shared/references/scope-rules.md`.
+- Use `languagePreferences.communication.normalized` for chat.
+- Use `languagePreferences.documents.normalized` for the final `project-context/rules.md`.
+- Apply `brainstormPreferences.discussionMode`, `recommendations`, and `discoveryDepth` using the shared session policy.
+- For this skill: announce that there are 7 topics, ask for pacing (one by one / three at once / all at once), and ask for recommendation preference if it is not already stored.
 
 4. Run the interview in the selected mode. Wait for the answer before continuing.
 
 5. After all topics are complete, create `project-context/rules.md` (create `project-context/` if needed).
 
-   > ⚠️ **If the file already exists:** ask the user before overwriting — "(A) Replace the entire file, (B) cancel and review first." Wait for the answer.
+   > ⚠️ **If the file already exists:** "(A) Overwrite all, (B) Cancel and review first." Wait for the answer.
 
 6. Summarize the result and provide next steps.
 
 ## Interview Topics (7)
 
 ### 1. AI Persona & Tech Stack
-**Ask:** *"What main tech stack must this AI be skilled in?"*
+
+**Ask:** _"What main tech stack must this AI be skilled in?"_
 
 **Collect:**
+
 - List of technologies (for example TypeScript, React, Next.js 14, Prisma, PostgreSQL)
 - Prioritized libraries (for example TanStack Query, Zustand, React Hook Form, Zod)
 - Preferred patterns (for example functional components, Server Components, App Router)
 - Patterns to avoid (for example class components, Pages Router, `any` type)
 
 ### 2. Naming Conventions
-**Ask:** *"Which naming conventions apply: camelCase, PascalCase, snake_case?"*
+
+**Ask:** _"Which naming conventions apply: camelCase, PascalCase, snake_case?"_
 
 **Collect:**
+
 - Variables & functions: camelCase
 - React components: PascalCase
 - Files & folders: kebab-case or camelCase?
@@ -86,9 +92,11 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 - Database tables: snake_case, plural?
 
 ### 3. Code Style & Quality
-**Ask:** *"What code quality and cleanliness rules apply?"*
+
+**Ask:** _"What code quality and cleanliness rules apply?"_
 
 **Collect:**
+
 - TypeScript: strict mode? Avoid `any`? Avoid `enum` (use `as const`)?
 - `console.log`: forbidden in production?
 - Error handling: `try-catch` required? Prefer guard clauses (early return)?
@@ -101,9 +109,11 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 - What must never be simplified: trust-boundary validation, data-loss protection, accessibility basics, explicit requirements?
 
 ### 4. Security Rules
-**Ask:** *"Which security rules are mandatory: token storage, input sanitization, CORS, and so on?"*
+
+**Ask:** _"Which security rules are mandatory: token storage, input sanitization, CORS, and so on?"_
 
 **Collect:**
+
 - Token storage (httpOnly cookie, NOT localStorage)
 - User input sanitization before processing
 - Environment variable handling (do not hardcode, use `.env.example`)
@@ -119,9 +129,11 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 - If runtime credentials are managed: rotation and revocation expectations
 
 ### 5. AI Behavior Rules
-**Ask:** *"Are there special rules for AI? When should it ask first instead of assuming?"*
+
+**Ask:** _"Are there special rules for AI? When should it ask first instead of assuming?"_
 
 **Collect:**
+
 - Comment language (Indonesian/English)
 - Error message language (shown to users)
 - Ambiguity handling: ask first or make reasonable assumptions?
@@ -131,9 +143,11 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 - Must AI show reasoning before implementing complex changes?
 
 ### 6. Git Workflow
-**Ask:** *"What Git rules apply: commit format, branch naming, and so on?"*
+
+**Ask:** _"What Git rules apply: commit format, branch naming, and so on?"_
 
 **Collect:**
+
 - Commit message format: Conventional Commits? (`feat:`, `fix:`, `chore:`, etc.)
 - Branch naming: `feature/`, `fix/`, `chore/` prefix?
 - Squash merge or regular merge?
@@ -141,9 +155,11 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 - Are pre-commit hooks required (lint, test, audit)?
 
 ### 7. Linter, Formatter & Testing
-**Ask:** *"What quality tools are used: ESLint, Prettier, test framework?"*
+
+**Ask:** _"What quality tools are used: ESLint, Prettier, test framework?"_
 
 **Collect:**
+
 - ESLint: version? Rule set? (`eslint:recommended`, `@typescript-eslint/recommended`)
 - Prettier: options? (semicolon, quote style, print width)
 - `.editorconfig`: used?
@@ -162,6 +178,7 @@ Adapt only sections that are applicable and preserve every required contract fro
 ## Next Steps
 
 After rules.md is complete:
+
 1. Run `brainstorm-task` to create Task.md from all spec documents
 2. Then: use the `developer` skill to start implementation
 

package/.agents/skills/brainstorm-rules/assets/rules.template.md

@@ -1,6 +1,7 @@
 # Coding Standards (Rules)
 
 ## Document Role
+
 - **Source of Truth:** Coding standards, AI behavior constraints, and implementation security rules
 - **Primary Owner:** `brainstorm-rules`
 - **Out of Scope:** Product scope decisions, schema design, endpoint payload contracts, and task sequencing
@@ -8,26 +9,31 @@
 ---
 
 ## 1. AI Persona & Tech Stack
+
 > You are an expert developer in: [stack confirmed by architecture and user].
 
 **Prioritize:**
+
 - [Preferred patterns]
 
 **Avoid:**
+
 - [Patterns to avoid]
 
 ---
 
 ## 2. Naming Conventions
-| Type | Convention | Example |
-|------|------------|---------|
-| [Project symbol type] | [confirmed convention] | [stack-native example] |
-| Files & Folders | [confirmed convention] | [example] |
-| Persisted entities/fields | [datastore-native convention] | [example] |
+
+| Type                      | Convention                    | Example                |
+| ------------------------- | ----------------------------- | ---------------------- |
+| [Project symbol type]     | [confirmed convention]        | [stack-native example] |
+| Files & Folders           | [confirmed convention]        | [example]              |
+| Persisted entities/fields | [datastore-native convention] | [example]              |
 
 ---
 
 ## 3. Code Style & Quality
+
 - **Language-specific rules:** [rules confirmed for the selected language; omit inapplicable TypeScript examples]
 - **Production diagnostics:** [confirmed logging/telemetry rule]
 - **Error Handling:** [stack-native strategy confirmed by the project]
@@ -44,6 +50,7 @@ Add a language-specific example only when it communicates a confirmed rule bette
 ---
 
 ## 4. Security Rules
+
 > **MANDATORY:** Before writing code involving user input, auth, file upload, or database access — check at least these 4 items and explain them briefly: input validation, secret/token protection, safe queries, and access control.
 
 - **Token/Session Storage:** [project-specific decision; do not assume JWT or browser cookies]
@@ -55,6 +62,7 @@ Add a language-specific example only when it communicates a confirmed rule bette
 - **Dependencies:** Run the project's available dependency audit before release when network policy permits. Block [agreed threshold].
 
 ### Conditional Operational Rules
+
 - **Structured Logging:** [only when architecture defines observability]
 - **Migration Conventions:** [only when schema evolution applies]
 - **Feature Flag Lifecycle:** [only when architecture selects flags]
@@ -64,6 +72,7 @@ Add a language-specific example only when it communicates a confirmed rule bette
 ---
 
 ## 5. AI Behavior Rules
+
 - **Comment Language:** [Indonesian / English]
 - **Error Messages (user-facing):** [Indonesian / English]
 - **When Ambiguous:** Ask the user first; do not assume.
@@ -73,6 +82,7 @@ Add a language-specific example only when it communicates a confirmed rule bette
 - **Complex Implementations:** Show a plan/rationale before implementing.
 
 ## Rule Priority
+
 - **Priority Order:** Security → correctness → data protection → consistency → maintainability → convenience
 - If two rules seem to conflict, choose the higher-priority rule and note the trade-off.
 - If a local exception is needed, mark it clearly with a `tradeoff:` comment and explain the upgrade trigger.
@@ -80,23 +90,25 @@ Add a language-specific example only when it communicates a confirmed rule bette
 ---
 
 ## 6. Git Workflow
+
 **Commit format:** [confirmed workflow; omit this table if Conventional Commits was not selected].
 
-| Type | When |
-|------|------|
-| `feat:` | New feature |
-| `fix:` | Bug fix |
-| `chore:` | Maintenance (update deps, config) |
-| `docs:` | Documentation changes |
+| Type        | When                                          |
+| ----------- | --------------------------------------------- |
+| `feat:`     | New feature                                   |
+| `fix:`      | Bug fix                                       |
+| `chore:`    | Maintenance (update deps, config)             |
+| `docs:`     | Documentation changes                         |
 | `refactor:` | Code restructuring without feature/bug change |
-| `style:` | Formatting (no logic changes) |
-| `test:` | Add or fix tests |
-| `perf:` | Performance improvement |
-| `ci:` | CI/CD config changes |
+| `style:`    | Formatting (no logic changes)                 |
+| `test:`     | Add or fix tests                              |
+| `perf:`     | Performance improvement                       |
+| `ci:`       | CI/CD config changes                          |
 
 **Example:** `feat(auth): add Google OAuth login`
 
 **Branch naming:**
+
 - `feature/[feature-name]`
 - `fix/[bug-name]`
 - `chore/[task-name]`
@@ -104,6 +116,7 @@ Add a language-specific example only when it communicates a confirmed rule bette
 ---
 
 ## 7. Linter, Formatter & Testing
+
 - **Linter:** [existing tool/version/config; omit if none].
 - **Formatter:** [existing tool/options; omit if none].
 - **Editor settings:** [existing settings; omit if none].
@@ -117,11 +130,12 @@ Add a language-specific example only when it communicates a confirmed rule bette
 
 > Check this list before writing any code. Violating even one item = code rejected.
 
-| # | Forbidden | Why |
-|---|-----------|-----|
-| F-01 | Never hardcode or expose secrets | Security |
+| #     | Forbidden                                      | Why      |
+| ----- | ---------------------------------------------- | -------- |
+| F-01  | Never hardcode or expose secrets               | Security |
 | F-02+ | [Confirmed stack/project-specific prohibition] | [Reason] |
 
 ## Assumptions & Exceptions
+
 - [Assumption about team workflow or tooling]
 - [Temporary exception with owner / review trigger]