tribunal-kit 9.2.4 → 9.2.5

package/.agent/workflows/plan.md

@@ -1,206 +1,206 @@
----
-description: 'Create project plan using project-planner agent. 4-phase approach: Analyze → Research → Plan Document → Human Gate. NO code writing — only plan file generation. Writing begins only after explicit human approval.'
-tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
-required-skills:
-  - plan-writing
-  - architecture
-  - domain-modeling
-scripts-binding:
-  - .agent/scripts/verify_all.js
----
-
-# /plan — Strategic Implementation Planning
-
-$ARGUMENTS
-
----
-
-## Mandatory Pre-Flight Context Inspection
-
-Before drafting implementation plans or technical blueprints, you MUST inspect:
-
-1. Workspace Context & Dependencies (`package.json`, `tsconfig.json`) → Confirm current stack capabilities and path mappings
-2. Existing Architecture & Directory Layout → Review current module boundaries to prevent redundant architectural patterns
-3. Zero Code Modification Rule → Restrict outputs in `/plan` mode to research, architectural design, and plan artifact generation; ban code generation before Plan approval
-
-4. Required Skills → Before executing, load and follow procedural rules from:
-   - `plan-writing` (.agent/skills/plan-writing/SKILL.md): Implementation plan structure, phases, and approval gates
-   - `architecture` (.agent/skills/architecture/SKILL.md): System architecture, module boundaries, and dependency management
-   - `domain-modeling` (.agent/skills/domain-modeling/SKILL.md): Ubiquitous language, entity relationships, bounded contexts
-
----
-
-## When to Use /plan
-
-| Use `/plan` when...                       | Skip plan and go to...                            |
-| :---------------------------------------- | :------------------------------------------------ |
-| New feature with unclear scope            | Simple, well-defined single file edit → just edit |
-| Multi-file change with dependencies       | Generating a snippet → `/generate`                |
-| Architecture decisions to make            | Fixing a bug → `/debug`                           |
-| Risk needs to be assessed first           | Adding to an existing feature → `/enhance`        |
-| Stakeholder requirements → technical spec |                                                   |
-
----
-
-## The Plan Contract: No Code Before Approval
-
-```
-The project-planner agent is the only agent active in /plan mode.
-It does NOT write code.
-It DOES read existing code to inform the plan.
-No other agents activate, no code is generated.
-```
-
----
-
-## Phase 1 — Socratic Gate (5 Questions)
-
-```
-1. GOAL: What specific outcome defines success? (not "add a feature" — a measurable outcome)
-2. USERS: Who exactly uses this? What do they currently do without this feature?
-3. SCOPE: What is explicitly OUT of scope for this version/sprint?
-4. RISK: What is the highest-risk assumption this plan rests on?
-5. STACK: Is the technology stack decided? Any constraints?
-```
-
-If any answer is "I don't know" → **ask before writing the plan document.**
-
----
-
-## Phase 2 — Research (Read Before Planning)
-
-```bash
-# What currently exists?
-ls -la src/      # Understand directory structure
-cat package.json # Understand actual dependencies
-cat tsconfig.json # Understand TypeScript config and path aliases
-git log --oneline -5 # Recent work context
-
-# Domain-specific reads:
-cat prisma/schema.prisma    # If DB changes planned
-cat src/middleware.ts        # If auth changes planned
-cat src/lib/auth.ts          # If auth changes planned
-```
-
----
-
-## Phase 3 — Wave Decomposition
-
-Plans execute in topological waves:
-
-```
-Wave 1 — Foundation (always first)
-├── Database schema changes (must precede all code)
-├── Shared types and Zod schemas (must precede callers)
-└── Auth/middleware changes (must precede protected routes)
-
-Wave 2 — Core Implementation
-├── API routes / Server Actions (depends on Wave 1 schema)
-├── Business logic layer
-└── Unit tests for Wave 1
-
-Wave 3 — Integration
-├── Frontend components (depends on Wave 2 API)
-├── Integration tests
-└── E2E tests for critical paths
-
-Wave 4 — Polish
-├── Performance optimization
-├── Accessibility audit
-└── Deploy prep
-```
-
----
-
-## Phase 4 — Implementation Plan Document
-
-```markdown
-# Implementation Plan: [Feature Name]
-
-## Goal
-
-[Single sentence: what is true when this is complete]
-
-## User Review Required
-
-> [!IMPORTANT]
-> [Breaking changes, architectural choices needing approval]
-
-## Research Findings
-
-- [what currently exists that's relevant]
-- [constraints discovered]
-
-## Proposed Changes
-
-### Wave 1 — Foundation
-
-#### [MODIFY] prisma/schema.prisma
-
-[What changes and why]
-
-#### [NEW] src/lib/validators/newFeature.ts
-
-[What this creates]
-
-### Wave 2 — Core
-
-#### [NEW] src/app/api/new-feature/route.ts
-
-[What this creates]
-
-## Out of Scope (This Version)
-
-- [explicit exclusion]
-
-## Verification Plan
-
-- [ ] npx tsc --noEmit passes
-- [ ] npm test passes
-- [ ] [specific behavioral assertion]
-```
-
----
-
-## Human Gate — Mandatory Before Execution
-
-After the plan document is written:
-
-```
-━━━ Plan Ready for Review ━━━━━━━━━━━━━━━━━
-
-[summary of what will change across N files in N waves]
-
-Approve?
-Y = begin execution (proceed to /generate or /enhance)
-N = discard plan
-R = revise with feedback
-```
-
-**Zero code is written until "Y" is received.**
-
----
-
-## Anti-Pattern Guard
-
-```
-❌ Never write code during /plan mode
-❌ Never assume what the user wants — ask if unclear
-❌ Never plan without reading the existing codebase first
-❌ Never omit the Out of Scope section (it's how scope creep is prevented)
-❌ Never skip the Socratic Gate — even for "simple" features
-❌ Never write a plan that requires understanding unexplored files
-```
-
----
-
-## After /plan — Next Steps
-
-| Outcome                              | Next Command                             |
-| :----------------------------------- | :--------------------------------------- |
-| Plan approved, new code needed       | → `/generate` for Tribunal-reviewed code |
-| Plan approved, existing code changes | → `/enhance` with impact analysis        |
-| Plan approved, full project build    | → `/create` for full scaffolding         |
-| Plan needs more brainstorming        | → `/brainstorm` to explore options       |
+---
+description: 'Create project plan using project-planner agent. 4-phase approach: Analyze → Research → Plan Document → Human Gate. NO code writing — only plan file generation. Writing begins only after explicit human approval.'
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - plan-writing
+  - architecture
+  - domain-modeling
+scripts-binding:
+  - .agent/scripts/verify_all.js
+---
+
+# /plan — Strategic Implementation Planning
+
+$ARGUMENTS
+
+---
+
+## Mandatory Pre-Flight Context Inspection
+
+Before drafting implementation plans or technical blueprints, you MUST inspect:
+
+1. Workspace Context & Dependencies (`package.json`, `tsconfig.json`) → Confirm current stack capabilities and path mappings
+2. Existing Architecture & Directory Layout → Review current module boundaries to prevent redundant architectural patterns
+3. Zero Code Modification Rule → Restrict outputs in `/plan` mode to research, architectural design, and plan artifact generation; ban code generation before Plan approval
+
+4. Required Skills → Before executing, load and follow procedural rules from:
+   - `plan-writing` (.agent/skills/plan-writing/SKILL.md): Implementation plan structure, phases, and approval gates
+   - `architecture` (.agent/skills/architecture/SKILL.md): System architecture, module boundaries, and dependency management
+   - `domain-modeling` (.agent/skills/domain-modeling/SKILL.md): Ubiquitous language, entity relationships, bounded contexts
+
+---
+
+## When to Use /plan
+
+| Use `/plan` when...                       | Skip plan and go to...                            |
+| :---------------------------------------- | :------------------------------------------------ |
+| New feature with unclear scope            | Simple, well-defined single file edit → just edit |
+| Multi-file change with dependencies       | Generating a snippet → `/generate`                |
+| Architecture decisions to make            | Fixing a bug → `/debug`                           |
+| Risk needs to be assessed first           | Adding to an existing feature → `/enhance`        |
+| Stakeholder requirements → technical spec |                                                   |
+
+---
+
+## The Plan Contract: No Code Before Approval
+
+```
+The project-planner agent is the only agent active in /plan mode.
+It does NOT write code.
+It DOES read existing code to inform the plan.
+No other agents activate, no code is generated.
+```
+
+---
+
+## Phase 1 — Socratic Gate (5 Questions)
+
+```
+1. GOAL: What specific outcome defines success? (not "add a feature" — a measurable outcome)
+2. USERS: Who exactly uses this? What do they currently do without this feature?
+3. SCOPE: What is explicitly OUT of scope for this version/sprint?
+4. RISK: What is the highest-risk assumption this plan rests on?
+5. STACK: Is the technology stack decided? Any constraints?
+```
+
+If any answer is "I don't know" → **ask before writing the plan document.**
+
+---
+
+## Phase 2 — Research (Read Before Planning)
+
+```bash
+# What currently exists?
+ls -la src/      # Understand directory structure
+cat package.json # Understand actual dependencies
+cat tsconfig.json # Understand TypeScript config and path aliases
+git log --oneline -5 # Recent work context
+
+# Domain-specific reads:
+cat prisma/schema.prisma    # If DB changes planned
+cat src/middleware.ts        # If auth changes planned
+cat src/lib/auth.ts          # If auth changes planned
+```
+
+---
+
+## Phase 3 — Wave Decomposition
+
+Plans execute in topological waves:
+
+```
+Wave 1 — Foundation (always first)
+├── Database schema changes (must precede all code)
+├── Shared types and Zod schemas (must precede callers)
+└── Auth/middleware changes (must precede protected routes)
+
+Wave 2 — Core Implementation
+├── API routes / Server Actions (depends on Wave 1 schema)
+├── Business logic layer
+└── Unit tests for Wave 1
+
+Wave 3 — Integration
+├── Frontend components (depends on Wave 2 API)
+├── Integration tests
+└── E2E tests for critical paths
+
+Wave 4 — Polish
+├── Performance optimization
+├── Accessibility audit
+└── Deploy prep
+```
+
+---
+
+## Phase 4 — Implementation Plan Document
+
+```markdown
+# Implementation Plan: [Feature Name]
+
+## Goal
+
+[Single sentence: what is true when this is complete]
+
+## User Review Required
+
+> [!IMPORTANT]
+> [Breaking changes, architectural choices needing approval]
+
+## Research Findings
+
+- [what currently exists that's relevant]
+- [constraints discovered]
+
+## Proposed Changes
+
+### Wave 1 — Foundation
+
+#### [MODIFY] prisma/schema.prisma
+
+[What changes and why]
+
+#### [NEW] src/lib/validators/newFeature.ts
+
+[What this creates]
+
+### Wave 2 — Core
+
+#### [NEW] src/app/api/new-feature/route.ts
+
+[What this creates]
+
+## Out of Scope (This Version)
+
+- [explicit exclusion]
+
+## Verification Plan
+
+- [ ] npx tsc --noEmit passes
+- [ ] npm test passes
+- [ ] [specific behavioral assertion]
+```
+
+---
+
+## Human Gate — Mandatory Before Execution
+
+After the plan document is written:
+
+```
+━━━ Plan Ready for Review ━━━━━━━━━━━━━━━━━
+
+[summary of what will change across N files in N waves]
+
+Approve?
+Y = begin execution (proceed to /generate or /enhance)
+N = discard plan
+R = revise with feedback
+```
+
+**Zero code is written until "Y" is received.**
+
+---
+
+## Anti-Pattern Guard
+
+```
+❌ Never write code during /plan mode
+❌ Never assume what the user wants — ask if unclear
+❌ Never plan without reading the existing codebase first
+❌ Never omit the Out of Scope section (it's how scope creep is prevented)
+❌ Never skip the Socratic Gate — even for "simple" features
+❌ Never write a plan that requires understanding unexplored files
+```
+
+---
+
+## After /plan — Next Steps
+
+| Outcome                              | Next Command                             |
+| :----------------------------------- | :--------------------------------------- |
+| Plan approved, new code needed       | → `/generate` for Tribunal-reviewed code |
+| Plan approved, existing code changes | → `/enhance` with impact analysis        |
+| Plan approved, full project build    | → `/create` for full scaffolding         |
+| Plan needs more brainstorming        | → `/brainstorm` to explore options       |

package/.agent/workflows/preview.md

@@ -1,116 +1,116 @@
----
-description: Preview server start, stop, and status check. Local development server management. Uses auto_preview.js for automated lifecycle control. Shows current URL and hot-reload status.
-tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
-required-skills:
-  - bash-linux
-  - nextjs-react-expert
-  - devops-engineer
-scripts-binding:
-  - .agent/scripts/auto_preview.js
----
-
-# /preview — Local Development Server
-
-$ARGUMENTS
-
----
-
-## Mandatory Pre-Flight Context Inspection
-
-Before managing dev server lifecycle or starting preview servers, you MUST inspect:
-
-1. Workspace Dev Script Configuration (`package.json`) → Verify `npm run dev` or equivalent start script and framework server port
-2. Environment Configuration (`.env`) → Check port bindings and dev server host configs
-3. Dev Server Lifecycle Script (`.agent/scripts/auto_preview.js`) → Use automated script for process management, port collision detection, and health checks
-
-4. Required Skills → Before executing, load and follow procedural rules from:
-   - `bash-linux` (.agent/skills/bash-linux/SKILL.md): Shell scripting patterns and command-line automation
-   - `nextjs-react-expert` (.agent/skills/nextjs-react-expert/SKILL.md): Next.js 15+ App Router, Server Components, Server Actions, PPR
-   - `devops-engineer` (.agent/skills/devops-engineer/SKILL.md): CI/CD pipeline management and infrastructure automation
-
----
-
-## Commands
-
-```
-/preview start    → Start the local dev server
-/preview stop     → Stop the local dev server
-/preview restart  → Restart the dev server (after config changes)
-/preview status   → Show current server status and URL
-```
-
----
-
-## Execution
-
-```bash
-# Start
-node .agent/scripts/auto_preview.js start
-
-# Stop
-node .agent/scripts/auto_preview.js stop
-
-# Restart
-node .agent/scripts/auto_preview.js restart
-
-# Status
-node .agent/scripts/auto_preview.js status
-```
-
----
-
-## Server Start Output
-
-```
-━━━ Dev Server Starting ━━━━━━━━━━━━━━━━━━
-
-Command:   npm run dev
-URL:       http://localhost:3000
-Status:    ✅ Running
-
-Hot reload: ✅ Enabled
-TypeScript: ✅ Type checking active
-```
-
----
-
-## Common Issues
-
-```
-Port 3000 in use:
-  → Kill: taskkill /F /IM node.exe  (Windows)
-  → OR:   lsof -i:3000 && kill -9 [PID]  (Mac/Linux)
-  → OR:   Run on different port: PORT=3001 npm run dev
-
-Build error on start:
-  → Run: npx tsc --noEmit to see TypeScript errors
-  → Fix errors first, then /preview start
-
-Config change not reflected:
-  → /preview restart (hot reload doesn't pick up next.config.js changes)
-```
-
----
-
-## When to Use /preview
-
-| Use `/preview` when...                   |                             |
-| :--------------------------------------- | :-------------------------- |
-| After code generation to visually verify | Start: `/preview start`     |
-| Config file was changed                  | Restart: `/preview restart` |
-| Done working for the session             | Stop: `/preview stop`       |
-| Checking if server is active             | Status: `/preview status`   |
-
----
-
-## After /preview — Next Steps
-
-| Outcome               | Next Command                               |
-| :-------------------- | :----------------------------------------- |
-| Preview looks correct | → `/deploy` or commit code                 |
-| Preview shows errors  | → `/debug` to analyze console/network logs |
-| Changes not updating  | → `/preview restart` to bust cache         |
-
----
+---
+description: Preview server start, stop, and status check. Local development server management. Uses auto_preview.js for automated lifecycle control. Shows current URL and hot-reload status.
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - bash-linux
+  - nextjs-react-expert
+  - devops-engineer
+scripts-binding:
+  - .agent/scripts/auto_preview.js
+---
+
+# /preview — Local Development Server
+
+$ARGUMENTS
+
+---
+
+## Mandatory Pre-Flight Context Inspection
+
+Before managing dev server lifecycle or starting preview servers, you MUST inspect:
+
+1. Workspace Dev Script Configuration (`package.json`) → Verify `npm run dev` or equivalent start script and framework server port
+2. Environment Configuration (`.env`) → Check port bindings and dev server host configs
+3. Dev Server Lifecycle Script (`.agent/scripts/auto_preview.js`) → Use automated script for process management, port collision detection, and health checks
+
+4. Required Skills → Before executing, load and follow procedural rules from:
+   - `bash-linux` (.agent/skills/bash-linux/SKILL.md): Shell scripting patterns and command-line automation
+   - `nextjs-react-expert` (.agent/skills/nextjs-react-expert/SKILL.md): Next.js 15+ App Router, Server Components, Server Actions, PPR
+   - `devops-engineer` (.agent/skills/devops-engineer/SKILL.md): CI/CD pipeline management and infrastructure automation
+
+---
+
+## Commands
+
+```
+/preview start    → Start the local dev server
+/preview stop     → Stop the local dev server
+/preview restart  → Restart the dev server (after config changes)
+/preview status   → Show current server status and URL
+```
+
+---
+
+## Execution
+
+```bash
+# Start
+node .agent/scripts/auto_preview.js start
+
+# Stop
+node .agent/scripts/auto_preview.js stop
+
+# Restart
+node .agent/scripts/auto_preview.js restart
+
+# Status
+node .agent/scripts/auto_preview.js status
+```
+
+---
+
+## Server Start Output
+
+```
+━━━ Dev Server Starting ━━━━━━━━━━━━━━━━━━
+
+Command:   npm run dev
+URL:       http://localhost:3000
+Status:    ✅ Running
+
+Hot reload: ✅ Enabled
+TypeScript: ✅ Type checking active
+```
+
+---
+
+## Common Issues
+
+```
+Port 3000 in use:
+  → Kill: taskkill /F /IM node.exe  (Windows)
+  → OR:   lsof -i:3000 && kill -9 [PID]  (Mac/Linux)
+  → OR:   Run on different port: PORT=3001 npm run dev
+
+Build error on start:
+  → Run: npx tsc --noEmit to see TypeScript errors
+  → Fix errors first, then /preview start
+
+Config change not reflected:
+  → /preview restart (hot reload doesn't pick up next.config.js changes)
+```
+
+---
+
+## When to Use /preview
+
+| Use `/preview` when...                   |                             |
+| :--------------------------------------- | :-------------------------- |
+| After code generation to visually verify | Start: `/preview start`     |
+| Config file was changed                  | Restart: `/preview restart` |
+| Done working for the session             | Stop: `/preview stop`       |
+| Checking if server is active             | Status: `/preview status`   |
+
+---
+
+## After /preview — Next Steps
+
+| Outcome               | Next Command                               |
+| :-------------------- | :----------------------------------------- |
+| Preview looks correct | → `/deploy` or commit code                 |
+| Preview shows errors  | → `/debug` to analyze console/network logs |
+| Changes not updating  | → `/preview restart` to bust cache         |
+
+---