feat: reshape Plan / pre-implementation tier (Cluster C)

openspec/changes/reshape-plan-preimpl-tier/.openspec.yaml

@@ -0,0 +1,4 @@
+schema: spec-driven
+created: 2026-07-07
+created_by: che cheng <kiki830621@gmail.com>
+created_with: claude

openspec/changes/reshape-plan-preimpl-tier/proposal.md

@@ -0,0 +1,38 @@
+## Why
+
+IDD's Plan / pre-implementation tier has three ratified gaps (user decisions 2026-07-07, issues #129 / #57 / #111). (1) Complexity routing's Layer P is purely advisory disjunctive any-match — large multi-file / shared-abstraction changes can silently route Simple and be under-planned (empirically #44 / #47: one conceptual change scattered across three artifacts, missed by a single Plan pass, needing two closes to fully cover). (2) Meeting / deliberation issues are forced through a code-centric pipeline (Strategy = Files & Changes, closing = TDD verify) that does not fit user-driven decision work. (3) Pre-implementation staging (brainstorm → written plan) has no home in IDD, and #209 already made superpowers a hard dependency — so the correct move is delegation, not a self-built equivalent.
+
+## What Changes
+
+- **#129 — complexity hard gate**: Layer P keeps its current disjunctive any-match "may trigger" behavior; on top of it, a **MUST-trigger hard gate** forces Plan tier when a change touches ≥ N files or modifies a shared abstraction (a data structure / helper interface / constants set used by multiple callers). The Simple default is preserved for everything else — the gate escalates, it does NOT invert the default to Default-Plan.
+- **#57 — explicit meeting issue type**: add `meeting` to the issue-type taxonomy alongside bug / feature / refactor / docs. `/idd-diagnose` emits a Phase A/B/C Strategy template (deliberation deliverables, not code Files & Changes) for `type=meeting`; `/idd-plan` detects `type=meeting`, uses a meeting-adapted Plan body, and skips the Step 6 chain to `/idd-implement`; closing semantics become a decision→action mapping with no `/idd-verify` TDD pass.
+- **#111 — delegate pre-implementation staging to superpowers**: add an IDD ↔ superpowers stage-mapping table to the plugin README (marking the verify ensemble and close audit trail as IDD-unique), and a hand-off hint in `/idd-issue` Step 5 and `/idd-diagnose` pointing design-heavy issues at superpowers:brainstorming. No new idd-brainstorm / idd-write-plan skill is created — self-building would be a forbidden vendored fork under the deep-integration-over-hardcode rule.
+
+Coupling: #129's hard gate and #57's meeting branch both alter `/idd-diagnose` Step 3.5 routing, so they are designed together in this one change to avoid a double or conflicting verdict path.
+
+## Capabilities
+
+### New Capabilities
+
+- `complexity-hard-gate`: MUST-trigger escalation layered above Layer P that forces Plan tier on ≥ N-file or shared-abstraction changes, while preserving the Simple default elsewhere.
+- `meeting-issue-type`: first-class `meeting` issue type with a deliberation-shaped diagnose Strategy template, a meeting-adapted plan body that skips the implement chain, and decision→action closing semantics.
+
+### Modified Capabilities
+
+- `superpowers-integration`: add a pre-implementation staging hand-off requirement — README stage-mapping table plus diagnose / issue hand-off pointers to superpowers:brainstorming, with no self-built staging skill.
+
+## Impact
+
+- Affected specs: `complexity-hard-gate` (new), `meeting-issue-type` (new), `superpowers-integration` (modified)
+- Affected code:
+  - Modified:
+    - plugins/issue-driven-dev/skills/idd-diagnose/SKILL.md (Step 3.5 routing — #129 hard gate + #57 meeting Strategy template branch)
+    - plugins/issue-driven-dev/skills/idd-plan/SKILL.md (#57 meeting-adapted Plan body + skip Step 6 chain to implement)
+    - plugins/issue-driven-dev/skills/idd-issue/SKILL.md (#57 add meeting to the type taxonomy; #111 hand-off hint at Step 5)
+    - plugins/issue-driven-dev/skills/idd-close/SKILL.md (#57 meeting decision→action closing semantics — no /idd-verify TDD pass)
+    - plugins/issue-driven-dev/rules/sdd-integration.md (#129 Layer P hard-gate definition)
+    - plugins/issue-driven-dev/README.md (#111 IDD ↔ superpowers stage-mapping table)
+  - New:
+    - openspec/specs/complexity-hard-gate/spec.md (on archive)
+    - openspec/specs/meeting-issue-type/spec.md (on archive)
+  - Removed: (none)

openspec/changes/reshape-plan-preimpl-tier/specs/complexity-hard-gate/spec.md

@@ -0,0 +1,53 @@
+## ADDED Requirements
+
+### Requirement: MUST-trigger complexity hard gate layered above Layer P
+
+`/idd-diagnose` Step 3.5 SHALL evaluate a MUST-trigger hard gate that forces the `Plan` complexity tier when the diagnosed change is estimated to touch at least N files (default N = 5) **that belong to one interdependent concept**, OR to modify a shared abstraction. A shared abstraction is a data structure, helper interface, or constants set estimated to be referenced by at least 2 distinct files other than the one under change. The file-count trigger is scoped to *one interdependent concept scattered across files*, NOT raw file count: genuinely-independent multi-file changes (parallel doc updates, independent script tweaks) SHALL NOT trigger the hard gate — they remain `Simple` via the Layer 1 "Multi-file but each file independent" disqualifier. The hard gate SHALL only escalate: when it does not trigger, routing SHALL fall through to the existing Layer P disjunctive any-match evaluation with the `Simple` default preserved. The hard gate SHALL NOT invert the default tier to `Plan`.
+
+#### Scenario: Multi-file change of one interdependent concept forces Plan
+
+- **WHEN** `/idd-diagnose` estimates a change will touch 5 or more files that belong to one interdependent concept
+- **THEN** the Complexity verdict is `Plan`, set by the hard gate before Layer P is consulted
+
+#### Scenario: Shared-abstraction change forces Plan
+
+- **WHEN** `/idd-diagnose` estimates the change modifies a helper interface referenced by 2 or more other files
+- **THEN** the Complexity verdict is `Plan`, set by the hard gate
+
+##### Example: gate decisions by estimated scope
+
+| Estimated scope | Shared abstraction touched | Hard gate | Complexity verdict |
+| --------------- | -------------------------- | --------- | ------------------ |
+| 1 file (impl only) | no | not triggered | Simple (default) |
+| 3 files (impl + test + doc) | no | not triggered | Simple (default), unless Layer P any-match fires |
+| 5 files of one interdependent concept | no | triggered | Plan |
+| 5 genuinely-independent files (parallel doc / script edits) | no | not triggered | Simple (Layer 1 disqualifier) |
+| 2 files | yes (constants set used by 4 callers) | triggered | Plan |
+
+#### Scenario: Small isolated change preserves the Simple default
+
+- **WHEN** `/idd-diagnose` estimates a change touches 1 file and no shared abstraction, and no Layer P signal fires
+- **THEN** the hard gate does not trigger and the Complexity verdict is `Simple`
+
+### Requirement: Hard-gate estimate is disclosed in the audit trail
+
+The hard-gate evaluation SHALL be an AI scope estimate, because `/idd-diagnose` runs before implementation and no diff exists yet. The evaluation SHALL be disclosed as a single audit line of the form `Hard-gate: <triggered|not triggered> — <reason with concrete anchors>` in the Diagnosis comment, placed alongside the Layer V audit line. The reason SHALL cite concrete anchors (estimated file names or symbol names), not style words. When the issue provides insufficient signal to estimate file count or caller count, the hard gate SHALL NOT trigger and the audit line SHALL state `insufficient signal`.
+
+#### Scenario: Triggered gate discloses reason and anchors
+
+- **WHEN** the hard gate triggers because the issue names four scale-family modules plus a shared scoring helper
+- **THEN** the Diagnosis comment contains a line `Hard-gate: triggered — <names the modules and the shared helper>`
+
+#### Scenario: Insufficient signal fails open to Layer P
+
+- **WHEN** the issue body is too sparse to estimate file count or caller count
+- **THEN** the hard gate does not trigger, the audit line reads `Hard-gate: not triggered — insufficient signal`, and routing falls through to Layer P with the `Simple` default
+
+### Requirement: Shared-abstraction trigger forces family-wide Plan scope
+
+When the hard gate triggers because of a shared-abstraction estimate, the resulting Plan SHALL enumerate all known call sites and family members of that abstraction as in-scope, not only the triggering file.
+
+#### Scenario: Plan enumerates family members
+
+- **WHEN** the hard gate triggers on a change to a scoring helper shared by three sibling scale modules
+- **THEN** the Plan lists all three sibling modules as in-scope, not just the one module named in the issue title

openspec/changes/reshape-plan-preimpl-tier/specs/meeting-issue-type/spec.md

@@ -0,0 +1,52 @@
+## ADDED Requirements
+
+### Requirement: meeting is a first-class issue type
+
+The IDD issue-type taxonomy SHALL include `meeting` alongside `bug`, `feature`, `refactor`, and `docs`. `/idd-issue` SHALL accept `meeting` as a valid type value when creating an issue.
+
+#### Scenario: idd-issue accepts the meeting type
+
+- **WHEN** a user creates an issue and selects type `meeting`
+- **THEN** `/idd-issue` records the type as `meeting` without falling back to `feature` or rejecting the value
+
+### Requirement: Diagnose emits a deliberation Strategy for meeting issues
+
+For an issue with `type=meeting`, `/idd-diagnose` SHALL emit a Phase A/B/C deliberation Strategy template (Phase A agenda, Phase B decision points, Phase C action items) instead of the code-centric Files & Changes Strategy. The `meeting` branch SHALL be evaluated FIRST in routing — before the Layer 1 disqualifier, before the Layer V vagueness pre-check (which SHALL short-circuit at Step 3.4 for `type=meeting`), before the Spectra (Layer 2+3) evaluation, before the complexity hard gate, and before Layer P — so a `meeting` issue SHALL NOT be assigned a `Simple`, `Plan`, or `Spectra` complexity verdict by any of them. Evaluating meeting first is required because a meeting's deliberation content would otherwise match the Layer 1 narrative disqualifier and be forced to `Simple`.
+
+#### Scenario: meeting issue gets a Phase A/B/C Strategy
+
+- **WHEN** `/idd-diagnose` runs on an issue with `type=meeting`
+- **THEN** the emitted Strategy contains Phase A / Phase B / Phase C deliberation sections and contains no Files & Changes section
+
+#### Scenario: meeting issue bypasses the complexity hard gate
+
+- **WHEN** `/idd-diagnose` reaches Step 3.5 routing for an issue with `type=meeting`
+- **THEN** the meeting branch is taken before complexity scoring, so none of Spectra (Layer 2+3), the hard gate, or Layer P assigns a `Simple` / `Plan` / `Spectra` verdict to the issue
+
+#### Scenario: meeting issue skips the Layer V vagueness gate
+
+- **WHEN** `/idd-diagnose` reaches Step 3.4 (Layer V) for an issue with `type=meeting` whose body would otherwise score V1/V4 ≥ 4
+- **THEN** Step 3.4 short-circuits without scoring V1/V4 or raising the vagueness AskUserQuestion, and routing proceeds directly to the Step 3.5 meeting branch
+
+### Requirement: Plan for meeting issues skips the implement chain
+
+For an issue with `type=meeting`, `/idd-plan` SHALL produce a meeting-adapted Plan body and SHALL NOT chain to `/idd-implement`.
+
+#### Scenario: meeting plan does not chain to implement
+
+- **WHEN** `/idd-plan` completes for an issue with `type=meeting`
+- **THEN** the Plan body uses the meeting-adapted schema and the skill does not invoke or prompt to invoke `/idd-implement`
+
+### Requirement: Meeting closing maps decisions to actions without a TDD verify pass
+
+Closing an issue with `type=meeting` SHALL use a decision-to-action mapping as the closing summary and SHALL NOT require an `/idd-verify` TDD verification pass. `/idd-close` SHALL gate a `type=meeting` issue with a **meeting-specific gate** — NOT the generic code-issue checklist gate / `authoritative_source` resolution. The meeting gate SHALL scan the authoritative meeting deliverable — the approved Meeting Plan's Phase C action items, falling back to the diagnose Strategy deliberation's Phase C when no plan stage ran (when both exist, only the Meeting Plan Phase C is scanned) — and each action item SHALL carry a disposition marker (`[x]` done / `[~]` tracked in a follow-up / `[-]` dropped). A bare undispositioned `- [ ]` action item SHALL block close.
+
+#### Scenario: meeting close needs no TDD verify
+
+- **WHEN** an issue with `type=meeting` is closed
+- **THEN** the closing summary records each decision mapped to its follow-up action, and no `/idd-verify` TDD pass is required as a precondition of closing
+
+#### Scenario: meeting gate blocks on an undispositioned Phase C action item
+
+- **WHEN** a `type=meeting` issue with an approved Meeting Plan whose Phase C contains a bare `- [ ]` action item (no owner / no disposition) is closed
+- **THEN** the meeting-specific gate blocks close until that item is marked `[x]`, `[~] — tracked in #NNN`, or `[-] — <reason>` (mirroring the generic checklist markers), and the generic `authoritative_source` resolution is not consulted for the meeting issue

openspec/changes/reshape-plan-preimpl-tier/specs/superpowers-integration/spec.md

@@ -0,0 +1,36 @@
+## MODIFIED Requirements
+
+### Requirement: Kept disciplines are excluded from delegation
+
+`idd-verify` ensemble backend resolution, worktree isolation, and planning disciplines (idd-plan / Spectra — explicitly including the `brainstorming` and `writing-plans` counterparts) SHALL NOT delegate to `superpowers`. A non-binding hand-off pointer surfaced by `idd-issue` or `idd-diagnose` that names `superpowers:brainstorming` as an optional pre-implementation staging destination for the user is NOT delegation — IDD's own planning flow does not invoke it, and the user chooses whether to follow the pointer — and it is permitted; that pointer is governed by the "Pre-implementation staging hand-off to superpowers" requirement.
+
+#### Scenario: Verify backend unaffected
+
+- **WHEN** `idd-verify` resolves its ensemble backend
+- **THEN** resolution follows the existing `idd-verify` spec chain (pai canonical → vendored fallback → manual fan-out) with no `superpowers` involvement
+
+#### Scenario: Planning disciplines remain superpowers-free
+
+- **WHEN** `idd-plan` or the Spectra planning skills execute
+- **THEN** their skill definitions contain no `superpowers:` invocation (mechanical check: `grep -rn 'superpowers:' plugins/issue-driven-dev/skills/idd-plan/` returns zero hits)
+
+## ADDED Requirements
+
+### Requirement: Pre-implementation staging hand-off to superpowers
+
+The IDD plugin README SHALL contain an IDD-to-superpowers stage-mapping table that maps each IDD pipeline stage to its superpowers counterpart and marks the `idd-verify` ensemble and the `idd-close` audit trail as IDD-unique (no superpowers counterpart). For a design-heavy issue, `idd-issue` (at its issue-creation summary step) and `idd-diagnose` SHALL surface a non-binding hand-off pointer naming `superpowers:brainstorming` as the pre-implementation staging destination. IDD SHALL NOT add a self-built brainstorming or plan-writing skill; no skill named `idd-brainstorm` or `idd-write-plan` SHALL exist.
+
+#### Scenario: README documents the stage mapping
+
+- **WHEN** a reader opens the IDD plugin README
+- **THEN** a stage-mapping table maps IDD pipeline stages to superpowers counterparts and explicitly marks the verify ensemble and close audit trail as having no superpowers counterpart
+
+#### Scenario: Design-heavy issue surfaces the brainstorming pointer
+
+- **WHEN** `idd-diagnose` classifies an issue as design-heavy (Plan tier or Spectra tier)
+- **THEN** the emitted output contains a non-binding pointer naming `superpowers:brainstorming` as the pre-implementation staging destination, and the pointer does not cause IDD to invoke that skill itself
+
+#### Scenario: No self-built staging skill is added
+
+- **WHEN** the IDD plugin skill set is enumerated
+- **THEN** no skill named `idd-brainstorm` or `idd-write-plan` exists (mechanical check: the `plugins/issue-driven-dev/skills/` directory contains neither)