@dv.nghiem/flowdeck 0.2.3 → 0.3.0

package/src/commands/fd-blast-radius.md

@@ -1,49 +0,0 @@
----
-description: Blast Radius Preview — show downstream consequences of a proposed change including hidden dependencies and fragile integration points
-argument-hint: [change description] [--depth=N]
----
-
-# Blast Radius
-
-Map the full downstream blast radius of a proposed change.
-
-**Input:** $ARGUMENTS — description or file path of the proposed change. Optional `--depth=N` (default: 3).
-
-## Steps
-
-Run two agents in parallel:
-
-- **@architect**: Trace dependency graph to depth `--depth` (default 3 levels); flag integration points, event listeners, shared state, and service-to-service calls that would be affected
-
-- **@researcher**: Identify hidden couplings — shared config values, environment variables, database tables, message queue topics, and implicit conventions that the changed code relies on
-
-## Report
-
-```
-════════════════════════════════════════════
-BLAST RADIUS PREVIEW
-════════════════════════════════════════════
-Change: <summary>
-Depth: <N> levels
-
-Direct Impact (depth 1):
-  - <file/module> — <relationship>
-
-Indirect Impact (depth 2-3):
-  - <file/module> — <chain>
-
-Hidden Couplings:
-  - <coupling type>: <description>
-
-Fragile Integration Points:
-  - <point> — <why fragile>
-
-Risk Assessment:
-  Score: <0-10>
-  Level: <low|medium|high|critical>
-  
-  <1-2 sentence summary of the biggest risks>
-
-Recommended: <proceed | add tests | get review | redesign>
-════════════════════════════════════════════
-```

package/src/commands/fd-dashboard.md

@@ -1,57 +0,0 @@
----
-description: Open project dashboard in browser — displays phase progress, milestones, and blockers
-argument-hint: [--port=N]
----
-
-# Dashboard
-
-Open the FlowDeck project dashboard.
-
-**Input:** $ARGUMENTS — optional `--port=N` (default: 3847)
-
-## Steps
-
-1. Check `.planning/STATE.md` exists — if not, error: "No active project. Run /fd-new-project first."
-
-2. Read project state from:
-   - `.planning/STATE.md` — current phase, status, progress
-   - `.planning/ROADMAP.md` — all phases and completion status
-   - `.planning/phases/phase-*/PLAN.md` — step completion per phase
-
-3. Try to start the dashboard server if not running:
-   ```bash
-   npx @dv.nghiem/flowdeck-dashboard --port <port> &
-   ```
-   Or if the package is installed, run:
-   ```bash
-   flowdeck-dashboard --port <port> &
-   ```
-
-4. If server cannot start, display a text-based dashboard instead:
-
-```
-════════════════════════════════════════════
-FLOWDECK DASHBOARD
-════════════════════════════════════════════
-Project: <name from PROJECT.md>
-Updated: <last_updated>
-
-ROADMAP
-  ✅ Phase 1: Setup           — completed
-  🔄 Phase 2: Core Feature    — in progress (3/7 steps)
-  ⏳ Phase 3: Polish          — planned
-
-CURRENT PHASE (2): Core Feature
-  ✅ Step 1: Set up database schema
-  ✅ Step 2: Create API endpoints
-  ✅ Step 3: Add authentication
-  ⬜ Step 4: Write tests
-  ⬜ Step 5: Write documentation
-
-BLOCKERS
-  - (none)
-════════════════════════════════════════════
-Run /fd-progress for detailed state view.
-```
-
-5. If server starts: report the URL: "Dashboard running at http://localhost:<port>"

package/src/commands/fd-evaluate-risk.md

@@ -1,62 +0,0 @@
----
-description: Risk assessment — estimates change risk, confidence, likely regressions, and whether approval is needed before proceeding
-argument-hint: [change description]
----
-
-# Evaluate Risk
-
-Produce a risk assessment for a proposed change.
-
-**Input:** $ARGUMENTS — description of the proposed change
-
-## Steps
-
-Run two agents in parallel:
-
-- **@researcher**: Map `$ARGUMENTS` to affected paths and modules; check `.codebase/VOLATILITY.json` for hotspot scores; check `.codebase/FAILURES.json` for prior failures; identify external dependencies touched
-
-- **@reviewer**: Validate the risk assessment — verify risk level is calibrated correctly given the scope; flag any under-estimated risks; check if approval is warranted by active policies in `.planning/config.json`
-
-## Risk Dimensions
-
-| Dimension | Weight | Assessment |
-|-----------|--------|------------|
-| Volatility | 30% | hotspot score of affected files |
-| Blast radius | 25% | number of downstream dependents |
-| Prior failures | 25% | recurrences in FAILURES.json |
-| External deps | 20% | third-party APIs or services involved |
-
-## Approval Logic
-
-Approval required if:
-- `approval_required: true` in config
-- Overall risk score ≥ `volatility_threshold` (default 0.7)
-- Any touched file has 3+ prior failures
-
-## Report
-
-```
-════════════════════════════════════════════
-RISK ASSESSMENT
-════════════════════════════════════════════
-Change: <summary>
-
-Risk Score: <0.0–1.0> (<low|medium|high|critical>)
-Confidence: <high|medium|low>
-
-Breakdown:
-  Volatility:    <score> (<rationale>)
-  Blast radius:  <score> (<N downstream>)
-  Prior failures: <score> (<N failures>)
-  External deps: <score> (<list or none>)
-
-Likely Regressions:
-  - <category>: <reason>
-
-Approval Required: <yes|no>
-  <if yes: reason and who should approve>
-
-Recommendation:
-  <proceed | add tests | get review | redesign>
-════════════════════════════════════════════
-```

package/src/commands/fd-guarded-edit.md

@@ -1,69 +0,0 @@
----
-description: Edit gate — decides auto-approve / require-confirmation / require-review / block based on policy, trust score, volatility, and arch constraints
-argument-hint: [change description or file path]
----
-
-# Guarded Edit
-
-Evaluate a proposed edit against all safety gates before allowing it to proceed.
-
-**Input:** $ARGUMENTS — description or file path of the proposed edit
-
-## Gates (evaluated in order)
-
-### Gate 1 — Policy Check
-
-Read `.planning/config.json` for active policies:
-- `approval_required`: if true, all edits need explicit approval
-- `volatility_threshold`: edits touching files above this score need confirmation
-
-### Gate 2 — Volatility Check
-
-Check `.codebase/VOLATILITY.json` for the files in `$ARGUMENTS`.
-- Score ≥ 0.8 → REQUIRE REVIEW
-- Score ≥ 0.6 → REQUIRE CONFIRMATION
-- Score < 0.6 → proceed
-
-### Gate 3 — Architecture Constraints
-
-Read `.codebase/ARCHITECTURE.md` and check if the edit:
-- Crosses defined service boundaries
-- Modifies public API contracts
-- Touches security-critical paths (auth, payments, PII)
-
-### Gate 4 — Trust Score
-
-Check `.codebase/FAILURES.json` for prior failures in the same path.
-- 3+ prior failures in this area → REQUIRE REVIEW
-- 1-2 prior failures → REQUIRE CONFIRMATION
-
-## Decision Matrix
-
-| Condition | Decision |
-|-----------|----------|
-| Any BLOCK signal | ❌ BLOCK |
-| REQUIRE REVIEW signal | 👁️ REQUIRE REVIEW |
-| REQUIRE CONFIRMATION signal | ⚠️ REQUIRE CONFIRMATION |
-| All gates pass | ✅ AUTO-APPROVE |
-
-## Report
-
-```
-════════════════════════════════════
-GUARDED EDIT GATE
-════════════════════════════════════
-Edit: <summary>
-
-Gate 1 — Policy:      <pass|flag>
-Gate 2 — Volatility:  <score> → <pass|confirm|review>
-Gate 3 — Arch:        <pass|flag>
-Gate 4 — Trust:       <failures count> → <pass|confirm|review>
-
-DECISION: AUTO-APPROVE / CONFIRM / REVIEW / BLOCK
-
-<if BLOCK or REVIEW: explain what needs to happen first>
-════════════════════════════════════
-```
-
-If BLOCK: do not proceed with the edit. Explain what must change first.
-If CONFIRM: present to user and wait for explicit "yes" before proceeding.

package/src/commands/fd-impact-radar.md

@@ -1,51 +0,0 @@
----
-description: Change Impact Radar — predict which files, modules, APIs, tests, and DB paths are affected before editing anything
-argument-hint: [change description]
----
-
-# Impact Radar
-
-Predict the blast area of a proposed change before any code is written.
-
-**Input:** $ARGUMENTS — description of the proposed change
-
-## Steps
-
-Run three agents in parallel:
-
-- **@researcher**: Trace dependency graph from the paths mentioned in `$ARGUMENTS`; find all files that import or are imported by those modules; map 2 levels deep
-
-- **@architect**: Identify API contracts and service boundaries at risk; flag any public interfaces that would change; check for DB schema impacts
-
-- **@tester**: Find test files that cover the affected paths; identify which tests would need updating; spot gaps (changed files with no tests)
-
-## Report
-
-```
-════════════════════════════════════════════
-CHANGE IMPACT RADAR
-════════════════════════════════════════════
-Change: <summary of $ARGUMENTS>
-Risk score: <low|medium|high>
-
-Affected Files (<N>):
-  - <file> (<reason>)
-
-API Contracts at Risk:
-  - <interface/endpoint> — <risk>
-
-Tests to Update (<N>):
-  - <test file>
-
-Test Gaps (<N> files with no tests):
-  - <file>
-
-DB / Schema Impact:
-  - <none | description>
-
-Recommendation:
-  <proceed with caution | review required | block>
-════════════════════════════════════════════
-```
-
-If no impact found: "No significant impact detected. Proceed with standard review."

package/src/commands/fd-learn.md

@@ -1,36 +0,0 @@
----
-description: Capture a repeatable pattern from this session and save it as a reusable FlowDeck skill
-argument-hint: [skill-name]
----
-
-# Learn: Capture Session Knowledge
-
-Review what happened in this session and create a reusable skill from the most significant learning.
-
-**Input:** `$ARGUMENTS` — optional kebab-case name for the skill (the agent will choose one if omitted)
-
-## Steps
-
-1. **Identify what is worth capturing.** Look for:
-   - A novel problem that required figuring out a non-obvious solution
-   - A pattern that required human guidance or clarification to resolve
-   - A workflow or sequence that would save significant time if remembered
-   - A pitfall that was hit and corrected
-
-   If nothing significant was discovered, reply: "No new patterns to capture from this session." and stop.
-
-2. **Draft the skill.** Structure it as:
-   - `## When to Activate` — concrete triggers (e.g., "when X file pattern exists", "when the user asks about Y")
-   - `## Steps` — ordered, concrete steps to apply the skill
-   - `## Examples` — at least one short, concrete example
-   - `## Pitfalls` — common mistakes to avoid
-
-3. **Choose the skill name.** Use `$ARGUMENTS` if provided, otherwise derive a kebab-case name from the pattern.
-
-4. **Write the skill** using the `create-skill` tool with:
-   - `name`: kebab-case identifier
-   - `description`: one sentence summarising what the skill does
-   - `content`: the full Markdown body from step 2
-   - `tags`: 2–4 relevant tags
-
-5. **Report** what was captured, why it is useful, and remind the user to restart OpenCode to activate it.

package/src/commands/fd-progress.md

@@ -1,50 +0,0 @@
----
-description: Display project progress — STATE.md summary, active PLAN.md steps, and recent results
-argument-hint: [--json]
----
-
-# Progress
-
-Display current project progress from planning files.
-
-**Input:** $ARGUMENTS (pass `--json` for machine-readable output)
-
-## Steps
-
-1. Check `.planning/STATE.md` exists — if not, return error: "Initialize project first with /fd-new-project."
-
-2. Read STATE.md and parse:
-   - Current phase number
-   - Status (planned/in_progress/completed)
-   - Last updated timestamp
-   - `plan_confirmed` flag
-
-3. Read `.planning/phases/phase-<N>/PLAN.md` if it exists:
-   - Count total steps (lines matching `- [ ]` or `- [x]`)
-   - Count completed steps (lines matching `- [x]`)
-
-4. Check for recent RESULT.md files in the last 3 phases.
-
-5. Display:
-
-```
-════════════════════════════════════════════════════════════
-Phase: <N>  |  Status: <status>  |  Updated: <timestamp>
-────────────────────────────────────────────────────────────
-Plan: <X> steps (<Y> complete)
-Plan confirmed: <yes/no>
-Recent results: Phase <N-1>, Phase <N>
-════════════════════════════════════════════════════════════
-```
-
-If `--json`, output structured JSON instead:
-```json
-{
-  "phase": N,
-  "status": "...",
-  "plan_confirmed": true,
-  "steps_total": X,
-  "steps_complete": Y,
-  "last_updated": "..."
-}
-```

package/src/commands/fd-regression-predict.md

@@ -1,57 +0,0 @@
----
-description: Regression Prediction — estimate the most likely regression categories for a proposed change
-argument-hint: [change description]
----
-
-# Regression Predict
-
-Predict the most likely regression categories for a proposed change before implementing it.
-
-**Input:** $ARGUMENTS — description of the proposed change
-
-## Steps
-
-Run two agents in parallel:
-
-- **@researcher**: Map the changed code paths in `$ARGUMENTS` to regression category keywords and patterns; check `.codebase/FAILURES.json` for prior regressions in the same area
-
-- **@tester**: Analyze existing test coverage for the affected paths; identify which regression categories are under-tested
-
-## Regression Categories
-
-| Category | Indicators |
-|----------|-----------|
-| **Performance** | touching caching, DB queries, loops, response serialization |
-| **Auth / Security** | touching middleware, tokens, sessions, permissions |
-| **Schema / Data** | touching DB models, migrations, serializers |
-| **UI States** | touching frontend components, state management, events |
-| **Async Flows** | touching queues, workers, webhooks, timeouts |
-| **API Contracts** | touching public endpoints, request/response shapes |
-| **Integration** | touching external service calls, adapters |
-
-## Report
-
-```
-════════════════════════════════════════════
-REGRESSION PREDICTION
-════════════════════════════════════════════
-Change: <summary of $ARGUMENTS>
-
-Likely Regressions (ranked by probability):
-
-  🔴 HIGH — Auth/Security
-     Reason: change touches middleware X
-     Prior: FAILURES.json F-12 (×3 recurrences)
-
-  🟠 MEDIUM — API Contracts  
-     Reason: modifies response shape of /api/checkout
-
-  🟡 LOW — Performance
-     Reason: adds DB query in hot path
-
-────────────────────────────────────────────
-Recommended Tests to Add:
-  1. <specific test scenario>
-  2. <specific test scenario>
-════════════════════════════════════════════
-```

package/src/commands/fd-review-code.md

@@ -1,62 +0,0 @@
----
-description: Parallel reviewer + researcher + tester — aggregates findings into critical/major/minor report
-argument-hint: [--scope=path | --focus=security,quality,tdd]
----
-
-# Review Code
-
-Run a comprehensive parallel code review.
-
-**Input:** $ARGUMENTS — optional `--scope=<path>` and `--focus=<areas>`
-
-## Steps
-
-1. Determine scope: use `--scope` if provided, else review uncommitted changes (`git diff --name-only HEAD`).
-2. If no changes found, report: "Nothing to review."
-
-## Parallel Review
-
-Run three reviewers in parallel:
-
-- **@reviewer**: Quality, security, convention compliance, TDD discipline
-  - CRITICAL: hardcoded secrets, SQL injection, XSS, auth gaps
-  - HIGH: logic errors, missing error handling, unsafe casts
-  - MEDIUM: functions >50 lines, nesting >4 deep, missing tests
-  - LOW: naming nits, missing comments on public APIs
-
-- **@researcher**: API contracts, edge cases, hidden dependencies, integration risks
-
-- **@tester**: Test coverage, missing test cases, test quality, regression risks
-
-## Report
-
-Aggregate findings into:
-
-```
-════════════════════════════════════════════
-CODE REVIEW REPORT
-════════════════════════════════════════════
-Files reviewed: <N>
-
-CRITICAL (<count>)
-  - <file>:<line> — <issue>
-
-HIGH (<count>)
-  - <file>:<line> — <issue>
-
-MEDIUM (<count>)
-  - <file>:<line> — <issue>
-
-LOW (<count>)
-  - <file>:<line> — <issue>
-
-Test Coverage: <findings>
-────────────────────────────────────────────
-Verdict: PASS / NEEDS CHANGES / BLOCK
-════════════════════════════════════════════
-```
-
-**Verdict rules:**
-- CRITICAL issues → BLOCK
-- HIGH issues → NEEDS CHANGES
-- Only MEDIUM/LOW → PASS with comments

package/src/commands/fd-review-route.md

@@ -1,54 +0,0 @@
----
-description: Human Review Routing — route risky patches to the right reviewer type based on change nature and risk score
-argument-hint: [change description or PR number]
----
-
-# Review Route
-
-Determine the right reviewer type for a proposed change based on its nature and risk.
-
-**Input:** $ARGUMENTS — change description or PR number/URL
-
-## Steps
-
-1. Analyze the change described in `$ARGUMENTS`:
-   - Read affected files and their categories
-   - Check `.codebase/VOLATILITY.json` for risk scores if available
-   - Check `.codebase/FAILURES.json` for prior failures in this area
-
-2. Classify change by domain:
-
-| Domain Signals | Reviewer Type |
-|---------------|---------------|
-| Auth, tokens, sessions, permissions | **Security reviewer** |
-| DB migrations, schema, models | **Backend/DB reviewer** |
-| Infrastructure, CI/CD, containers | **Infra reviewer** |
-| Public APIs, SDK changes | **API owner** |
-| High-churn or volatile file (score >0.7) | **Domain owner** |
-| New external dependency | **Security + Arch reviewer** |
-| Low risk, no sensitive paths | **Any peer reviewer** |
-
-## Report
-
-```
-════════════════════════════════════════════
-REVIEW ROUTING
-════════════════════════════════════════════
-Change: <summary>
-Risk score: <0-10>
-
-Recommended Reviewers:
-
-  PRIMARY:   <reviewer type> — <reason>
-  SECONDARY: <reviewer type> — <reason>
-
-Why:
-  - <specific signal that triggered routing>
-  - <prior failures in this area if any>
-
-SLA:
-  - <high risk: same-day | medium: 24h | low: 48h>
-════════════════════════════════════════════
-```
-
-If risk score < 3: "Low risk — any peer reviewer is sufficient."

package/src/commands/fd-roadmap.md

@@ -1,46 +0,0 @@
----
-description: View or update project roadmap — displays ROADMAP.md, shows phase statuses, add new phase, or mark phase complete
-argument-hint: [--add "Phase Name" | --complete N | --list]
----
-
-# Roadmap
-
-View or update the project roadmap.
-
-**Input:** $ARGUMENTS
-
-## Behavior
-
-### View Roadmap (no args or `--list`)
-
-1. Read `.planning/ROADMAP.md` — if not found, error: "Run /fd-new-project first."
-2. Read `.planning/STATE.md` for current phase and completed phases.
-3. Display the roadmap with status indicators:
-
-```
-═══════════════════════════════════════
-PROJECT ROADMAP
-═══════════════════════════════════════
-  ✅ Phase 1: <name> — completed
-  🔄 Phase 2: <name> — in progress  ← current
-  ⏳ Phase 3: <name> — planned
-═══════════════════════════════════════
-Current: Phase 2 | Status: in_progress
-```
-
-### Add Phase (`--add "Phase Name"`)
-
-Append a new phase row to the `ROADMAP.md` overview table with status `planned`.
-
-Update STATE.md `total_phases` counter.
-
-Report: "Phase <N> '<name>' added."
-
-### Mark Complete (`--complete N`)
-
-1. Update ROADMAP.md to mark phase N as completed.
-2. Update STATE.md:
-   - Increment `completed_phases`
-   - Advance `phase` to N+1 if N is current phase
-   - Set new phase `status: planned`
-3. Report: "Phase N marked complete. Now on phase N+1."

package/src/commands/fd-settings.md

@@ -1,57 +0,0 @@
----
-description: View or update FlowDeck settings — agent models, quality profiles, and workflow toggles
-argument-hint: [key=value | --list]
----
-
-# Settings
-
-View or update FlowDeck configuration.
-
-**Input:** $ARGUMENTS
-
-## Behavior
-
-### List Settings (`--list` or no arguments)
-
-Read `.planning/config.json` (create with defaults if missing) and display current settings:
-
-| Setting | Value | Description |
-|---------|-------|-------------|
-| `model_profile` | balanced | Agent quality profile (quality/balanced/economy) |
-| `tdd_enforced` | true | Require TDD red-green-refactor cycle |
-| `approval_required` | false | Require human approval for risky changes |
-| `volatility_threshold` | 0.7 | Risk score that triggers approval gate |
-| `default_agent` | orchestrator | Default agent for commands |
-
-### Set a Value (`key=value`)
-
-Parse `$ARGUMENTS` as `key=value` pairs (space-separated for multiple).
-
-Valid keys:
-- `model_profile` — `quality`, `balanced`, `economy`
-- `tdd_enforced` — `true`, `false`
-- `approval_required` — `true`, `false`  
-- `volatility_threshold` — number between 0.0 and 1.0
-- `default_agent` — agent name string
-
-Update `.planning/config.json` with the new values.
-
-Report what was changed.
-
-### Invalid Key
-
-Report error with list of valid keys.
-
-## Default Config
-
-If `.planning/config.json` does not exist, create it with defaults:
-
-```json
-{
-  "model_profile": "balanced",
-  "tdd_enforced": true,
-  "approval_required": false,
-  "volatility_threshold": 0.7,
-  "default_agent": "orchestrator"
-}
-```