@reservine/dx 1.0.0

package/plugins/reservine-dx/skills/new-feature-planning/SKILL.md

@@ -0,0 +1,544 @@
+---
+name: reservine-dx:new-feature-planning
+description: >
+  Plan a new feature for the Reservine ecosystem. Supports three scopes:
+  FE-only, BE-only, or Full (both repos). Use prefix syntax to set scope:
+  "fe: description", "be: description", "full: description", or omit to choose.
+  Creates GitHub issues with questionnaire, milestone, and sub-issue linking.
+  Works from either repo (auto-detects FE vs BE).
+  Triggers: "plan new feature", "create feature issues", "new feature".
+argument-hint: "[fe:|be:|full:] <feature-description>"
+allowed-tools:
+  - Bash
+  - Read
+  - Write
+  - AskUserQuestion
+  - Agent
+  - Skill
+---
+
+# Reservine — New Feature Planning
+
+Creates structured GitHub issues for a new feature. Supports three scopes:
+
+| Prefix | Scope | What happens |
+|--------|-------|-------------|
+| `fe:` | FE-only | Issue in FE repo, FE questionnaire only |
+| `be:` | BE-only | Issue in BE repo, BE questionnaire only |
+| `full:` | Both repos | Linked parent-child issues, all questions |
+| *(none)* | Ask user | Presents scope selection with recommendation |
+
+**Repo-agnostic** — works from either the FE or BE repo. Auto-detects which repo
+it's running in and resolves the sibling repo from `.claude/config`.
+
+**Questionnaire style** — follows `my:interactive-questionnaire` pattern: one question
+per message, rich tradeoff descriptions, recommended option marked, acknowledge each
+answer before moving to the next question.
+
+---
+
+## Step 1: Load Config & Resolve Repos
+
+1. Read `.claude/config` + `.claude/config.local`:
+   ```bash
+   cat .claude/config 2>/dev/null
+   cat .claude/config.local 2>/dev/null
+   ```
+   Extract: `GITHUB_REPO`, `DEVELOPMENT_BRANCH`
+
+2. **Auto-detect repo context** — determine if we're in FE or BE:
+   ```bash
+   if [[ -f "angular.json" ]] || [[ -f "nx.json" ]]; then
+     CURRENT_REPO="FE"
+     FE_GITHUB_REPO=$GITHUB_REPO
+     SIBLING_DIR=$(grep 'BACKEND_DIR' .claude/config | cut -d= -f2)
+     SIBLING_DIR_ABS=$(grep 'BACKEND_DIR_ABSOLUTE' .claude/config.local 2>/dev/null | cut -d= -f2)
+     [[ -n "$SIBLING_DIR_ABS" ]] && SIBLING_DIR="$SIBLING_DIR_ABS"
+     BE_GITHUB_REPO=$(grep 'GITHUB_REPO' "$SIBLING_DIR/.claude/config" 2>/dev/null | cut -d= -f2)
+   else
+     CURRENT_REPO="BE"
+     BE_GITHUB_REPO=$GITHUB_REPO
+     SIBLING_DIR=$(grep 'FRONTEND_DIR' .claude/config | cut -d= -f2)
+     SIBLING_DIR_ABS=$(grep 'FRONTEND_DIR_ABSOLUTE' .claude/config.local 2>/dev/null | cut -d= -f2)
+     [[ -n "$SIBLING_DIR_ABS" ]] && SIBLING_DIR="$SIBLING_DIR_ABS"
+     FE_GITHUB_REPO=$(grep 'GITHUB_REPO' "$SIBLING_DIR/.claude/config" 2>/dev/null | cut -d= -f2)
+   fi
+   ```
+
+3. **Fallback defaults** (if sibling config unreadable):
+   - `FE_GITHUB_REPO` defaults to `LEFTEQ/reservine`
+   - `BE_GITHUB_REPO` defaults to `genesiscz/ReservineBack`
+
+## Step 2: Parse Arguments & Determine Scope
+
+1. **Parse prefix** from `$ARGUMENTS` using pattern `^(fe|be|full):\s*(.+)$` (case-insensitive):
+   - Match found → set `SCOPE` and `FEATURE_DESCRIPTION`
+   - No match → set `FEATURE_DESCRIPTION = $ARGUMENTS` (or null), `SCOPE = null`
+
+2. **If SCOPE is null**, `AskUserQuestion` with three options.
+   Mark the option matching `CURRENT_REPO` as "(Recommended)":
+
+   **FE-only** *(Recommended if running from FE repo)* — Creates a single issue in the
+   Angular/FE repo. Only asks UI/UX architecture questions (page layout, state management,
+   forms, etc.). Best for features that don't need new API endpoints or data model changes:
+   UI polish, new admin pages consuming existing APIs, layout refactors. If backend changes
+   are discovered later, you can create a cross-plan intent file as a follow-up.
+
+   **BE-only** *(Recommended if running from BE repo)* — Creates a single issue in the
+   Laravel/BE repo. Only asks data model and API architecture questions (models, endpoints,
+   permissions, etc.). Best for new endpoints, migrations, background jobs, or API-only
+   features: webhook systems, cron jobs, data exports. If frontend changes are discovered
+   later, you can create a cross-plan intent file as a follow-up.
+
+   **Full (both repos)** — Creates linked parent-child issues in both repos (FE = parent,
+   BE = child with sub-issue link). Asks all architecture questions for both stacks (BE
+   first, then FE — because data model constrains UI decisions). Best for complete features
+   spanning both repos: new CRUD modules, new settings pages with new APIs. Most thorough
+   but takes longer to complete.
+
+3. Acknowledge the choice: "Scope: **<scope>**. I'll create issue(s) in <repo(s)> and ask
+   <FE/BE/all> architecture questions."
+
+4. **If FEATURE_DESCRIPTION is still null**, `AskUserQuestion` for:
+   - Feature name (short, kebab-case-friendly)
+   - Business problem it solves
+   - Desired outcome / success criteria
+
+5. Search for existing related issues in the relevant repo(s):
+   - `fe` scope: search FE repo only
+   - `be` scope: search BE repo only
+   - `full` scope: search both repos
+   ```bash
+   gh search issues "<feature-keyword>" --repo $REPO --json number,title,state --limit 5
+   ```
+   If related issues found, present them and ask if this is a duplicate.
+
+## Step 3: Complexity Assessment
+
+`AskUserQuestion` with scope-specific complexity indicators:
+
+### If SCOPE == "fe"
+
+- **Simple** (1-2 days, single component/page, consuming existing API endpoints) —
+  Skip questionnaire, create minimal issue directly
+- **Medium** (3-5 days, 2-3 components, new state management or form flows) —
+  Abbreviated FE questionnaire (questions 1-5)
+- **Complex** (1+ weeks, multiple pages/layers, new UI patterns or complex state) —
+  Full FE questionnaire (all 10 questions)
+
+### If SCOPE == "be"
+
+- **Simple** (1-2 days, single endpoint, extending existing model) —
+  Skip questionnaire, create minimal issue directly
+- **Medium** (3-5 days, CRUD set, new model with 1-2 relationships) —
+  Abbreviated BE questionnaire (questions 1-5)
+- **Complex** (1+ weeks, multiple models, events, jobs, cross-service logic) —
+  Full BE questionnaire (all 10 questions)
+
+### If SCOPE == "full"
+
+- **Simple** (1-2 days per side, straightforward CRUD with UI) —
+  Skip questionnaire, create issues directly
+- **Medium** (3-5 days total, new model + new page) —
+  Abbreviated questionnaire (5 key questions per side, BE first)
+- **Complex** (1+ weeks, multiple modules on both sides) —
+  Full questionnaire (all 20 questions, BE first then FE)
+
+## Step 4: Interactive Questionnaire (Medium/Complex only)
+
+Present questions one-at-a-time via `AskUserQuestion`. Follow the `my:interactive-questionnaire`
+pattern for every question:
+
+1. **One question per message** — never batch
+2. **Rich option descriptions** — each option explains WHY and tradeoffs, not just the label
+3. **Mark recommended option** — add "(Recommended)" to the best default choice
+4. **Acknowledge each answer** — after the user picks, briefly explain how it constrains the next decision
+5. **Show question progress** — format as `**N/M — Topic**`
+
+### Scope filtering
+
+| Scope | Questions asked |
+|-------|----------------|
+| `fe` | FE Questions only (Q1-Q10 or Q1-Q5 for Medium) |
+| `be` | BE Questions only (Q1-Q10 or Q1-Q5 for Medium) |
+| `full` | BE Questions first (Q1-Q10), then FE Questions (Q1-Q10). BE first because data model/API constrains UI decisions. |
+
+### FE Questions
+
+| # | Topic | Options (present with rich descriptions + tradeoffs) |
+|---|-------|---------|
+| 1 | **Page Architecture** | **New admin page** (Recommended) — top-level route with sidebar entry, best for distinct domains. Tradeoff: adds nav complexity / **New tab on existing page** — extends an existing settings/detail page, keeps nav clean. Tradeoff: existing page grows / **Extension of existing component** — modifies existing component, best for small additions. Tradeoff: component complexity / **Layer/drawer only** — modal or side drawer from contextual triggers. Tradeoff: not directly URL-navigable |
+| 2 | **Layout Pattern** | **List + detail layer** (Recommended) — table/list with slide-in detail panel, most common admin pattern / **Card grid** — visual grid with filtering, good for media-heavy / **Split view** — side-by-side panels / **Dashboard widgets** — metric cards + charts / **Wizard/stepper** — multi-step linear flow |
+| 3 | **Data Display** | **CDK table with sort/paginate** (Recommended) — full-featured table with column sorting, pagination, best for data-heavy lists / **Card grid with filters** — visual cards with filter sidebar / **Timeline/feed** — chronological entries / **Kanban board** — drag-and-drop columns |
+| 4 | **Form Strategy** | **Single form section** — one `ui-form-section`, simplest / **Multi-section with tabs** — grouped settings-style / **Wizard steps** — multi-step with validation / **Inline editing** — click-to-edit cells / **Settings-style** — multiple independent sections with individual save |
+| 5 | **State Management** | **TanStack Query** (Recommended) — automatic caching, invalidation, loading states. Best for API data / **Signal-based service** — manual signals for local component state / **RxJS streams** — for complex async orchestration / **resource() API** — Angular 21 resource primitive for simple fetch |
+| 6 | **Empty States** | Illustration + CTA / Simple text + button / Onboarding guide / Contextual tips |
+| 7 | **Loading Strategy** | Skeleton screens / Spinner / Progressive loading / Optimistic UI |
+| 8 | **Mobile Approach** | Responsive table-to-cards / Dedicated mobile layout / Bottom sheet / Drawer navigation |
+| 9 | **Interaction Patterns** | Click-to-edit / Drag-and-drop / Bulk select + actions / Inline quick actions |
+| 10 | **Animation & Transitions** | None / Subtle (fade, slide) / Rich (stagger, spring) / Micro-interactions |
+
+### BE Questions
+
+| # | Topic | Options (present with rich descriptions + tradeoffs) |
+|---|-------|---------|
+| 1 | **Data Model Strategy** | **New standalone model** (Recommended) — clean separation, own migration + factory. Best for new domain concepts / **Extend existing model** — add columns to existing table, reuse existing factory. Best for enhancements / **Polymorphic** — shared interface across types (morphMany). More flexible but complex queries / **JSON extras on existing model** — store in model's `extra` JSON column. Fast to add, but no query indexing |
+| 2 | **API Scope** | **Admin-only** (Recommended) — behind auth + permission check. Most features start here / **Public-only** — no auth required, customer-facing / **Both** — separate admin + public endpoints / **Tenant-scoped public** — public but filtered by tenant context |
+| 3 | **CRUD Operations** | (Multi-select) List / Detail / Create / Update (PATCH) / Delete / Bulk operations |
+| 4 | **Authentication & Permissions** | **Existing permission** (Recommended) — reuse an existing PermissionEnum case / **New permission enum case** — add new case to PermissionEnum + seed / **Public (no auth)** — no guard / **Role-based guard** — check user role, not specific permission |
+| 5 | **Relationship Complexity** | **Simple belongsTo/hasMany** (Recommended) — standard FK relationships / **Many-to-many pivot** — pivot table with optional extra columns / **Polymorphic morphMany** — shared ownership across types / **Self-referencing tree** — parent-child within same table |
+| 6 | **Event-Driven Side Effects** | None / Queue job (email, SMS) / Event + Listener / Webhook / Real-time Pusher |
+| 7 | **File/Media Handling** | None / Single file upload / Multiple files / Image with crop / Documents with categories |
+| 8 | **Money & Pricing** | None / MoneyFactory pattern / Stripe integration / Custom pricing rules |
+| 9 | **Multi-tenant Scope** | **Standard BelongsToTenant** (Recommended) / Cross-tenant (SuperAdmin) / Tenant + Branch scoped |
+| 10 | **Migration Strategy** | **Fresh migration** (Recommended) — new table, clean start / Alter existing table / Seeder needed / Feature flag for rollout |
+
+After all questions, compile into a **Technical Assessment** and present to user for confirmation.
+
+## Step 5: Priority, Effort & Milestone
+
+`AskUserQuestion`:
+- **Priority**: P0 (critical) / P1 (high) / P2 (medium) / P3 (low)
+- **Impact**: Low / Medium / High
+- **Effort**: Low / Medium / High
+
+Then **select milestone** from the primary repo:
+
+```bash
+# fe scope or full scope: milestones from FE repo
+# be scope: milestones from BE repo
+MILESTONE_REPO=$FE_GITHUB_REPO  # default
+if [[ "$SCOPE" == "be" ]]; then
+  MILESTONE_REPO=$BE_GITHUB_REPO
+fi
+gh api repos/$MILESTONE_REPO/milestones --jq '.[].title'
+```
+
+`AskUserQuestion` with the available milestones as options + "No milestone" + "Other" (free text).
+
+## Step 6: Create Issues
+
+### 6a: FE-only Issue (SCOPE == "fe")
+
+```bash
+gh issue create --repo $FE_GITHUB_REPO --title "<feature-title>" --body "$(cat <<'ISSUE_EOF'
+- [ ] @LEFTEQ read this
+- [ ] @genesiscz read this
+
+---
+
+**Priority**: <priority> | **Impact**: <impact> | **Effort**: <effort>
+**Scope**: FE-only
+
+## Problem
+<business problem>
+
+## Current State
+<what exists today>
+
+## Implementation Plan
+
+### Phase 1: <phase-name>
+- [ ] <task 1>
+- [ ] <task 2>
+
+### Phase 2: <phase-name> (if applicable)
+<description>
+
+## Technical Assessment
+<compiled FE questionnaire answers — page architecture, layout, state management, etc.>
+
+## Success Criteria
+- [ ] <criterion 1>
+- [ ] <criterion 2>
+
+## Implementation Checklist
+- [ ] Build passes (0 errors)
+- [ ] Lint passes (0 warnings added)
+- [ ] E2E tests written and passing
+- [ ] Responsive (desktop + tablet + mobile)
+- [ ] Accessibility (keyboard nav + ARIA)
+- [ ] i18n keys added (no hardcoded text)
+- [ ] Loading states implemented
+- [ ] Empty states implemented
+- [ ] Error states implemented
+- [ ] PR created and linked
+ISSUE_EOF
+)" --label "feature"
+```
+
+### 6b: BE-only Issue (SCOPE == "be")
+
+```bash
+gh issue create --repo $BE_GITHUB_REPO --title "<feature-title>" --body "$(cat <<'ISSUE_EOF'
+- [ ] @LEFTEQ read this
+- [ ] @genesiscz read this
+
+---
+
+**Priority**: <priority> | **Impact**: <impact> | **Effort**: <effort>
+**Scope**: BE-only
+
+## Problem
+<business problem>
+
+## Current State
+<what exists today>
+
+## API Endpoints
+| Method | Path | Description | Auth |
+|--------|------|-------------|------|
+| GET | `/api/...` | ... | Bearer |
+| POST | `/api/...` | ... | Bearer |
+
+## Data Model
+<new models, relationships, migrations — from questionnaire>
+
+## Technical Decisions
+<from questionnaire — permissions, caching, events, multi-tenant scope>
+
+## Implementation Plan
+
+### Phase 1: <phase-name>
+- [ ] <task 1>
+- [ ] <task 2>
+
+### Phase 2: <phase-name> (if applicable)
+<description>
+
+## Success Criteria
+- [ ] <criterion 1>
+- [ ] <criterion 2>
+
+## Implementation Checklist
+- [ ] Migration created (reversible)
+- [ ] Model + Factory created
+- [ ] Service layer implemented
+- [ ] Controller + Routes created
+- [ ] DTOs (request + response) created
+- [ ] PHPStan passes (0 errors)
+- [ ] Tests passing (happy + edge + error paths)
+- [ ] Code review passed
+- [ ] Security audit passed (OWASP + GDPR + multi-tenant)
+- [ ] PR created and linked
+ISSUE_EOF
+)" --label "feature"
+```
+
+### 6c: Full Mode — Both Issues (SCOPE == "full")
+
+Create FE issue (parent) using the template from 6a but with **both** FE and BE sections in
+the Implementation Plan:
+
+```
+**Backend:**
+- [ ] <task 1>
+
+**Frontend:**
+- [ ] <task 2>
+```
+
+Then create BE issue (child) with the 6b template, adding a parent reference:
+
+```
+> **Parent:** $FE_GITHUB_REPO#<fe-issue>
+```
+
+And including cross-repo tasks in the checklist:
+```
+- [ ] Generate TypeScript types (`sail a app:types` + `./bin/types`)
+- [ ] Create FE intent file (cross-plan)
+```
+
+### Assign milestone (all scopes):
+```bash
+if [[ -n "$MILESTONE" ]]; then
+  # fe scope: FE repo only
+  # be scope: BE repo only
+  # full scope: both repos
+  gh issue edit <issue> --repo $REPO --milestone "$MILESTONE"
+fi
+```
+
+## Step 7: Link Issues via Sub-Issues (SCOPE == "full" only)
+
+> **Skip entirely for `fe` and `be` scopes.**
+
+```bash
+FE_OWNER=$(echo $FE_GITHUB_REPO | cut -d/ -f1)
+FE_NAME=$(echo $FE_GITHUB_REPO | cut -d/ -f2)
+FE_NODE_ID=$(gh api graphql -f query='
+  { repository(owner:"'"$FE_OWNER"'", name:"'"$FE_NAME"'") {
+    issue(number:<fe-issue>) { id }
+  } }' --jq '.data.repository.issue.id')
+
+BE_OWNER=$(echo $BE_GITHUB_REPO | cut -d/ -f1)
+BE_NAME=$(echo $BE_GITHUB_REPO | cut -d/ -f2)
+BE_NODE_ID=$(gh api graphql -f query='
+  { repository(owner:"'"$BE_OWNER"'", name:"'"$BE_NAME"'") {
+    issue(number:<be-issue>) { id }
+  } }' --jq '.data.repository.issue.id')
+
+gh api graphql -f query='
+  mutation {
+    addSubIssue(input: {
+      issueId: "'"$FE_NODE_ID"'"
+      subIssueId: "'"$BE_NODE_ID"'"
+    }) {
+      issue { id }
+      subIssue { id }
+    }
+  }'
+```
+
+If the sub-issue API fails, fall back to cross-reference comments only.
+
+## Step 8: Cross-Reference Comments (SCOPE == "full" only)
+
+> **Skip entirely for `fe` and `be` scopes.**
+
+```bash
+gh issue comment <fe-issue> --repo $FE_GITHUB_REPO \
+  --body "**BE Issue:** $BE_GITHUB_REPO#<be-issue>
+Linked as sub-issue for implementation tracking."
+
+gh issue comment <be-issue> --repo $BE_GITHUB_REPO \
+  --body "**FE Parent:** $FE_GITHUB_REPO#<fe-issue>
+This issue tracks the backend implementation."
+```
+
+## Step 9: Ensure Labels Exist
+
+Create status labels (idempotent) in the **affected repos only**:
+
+```bash
+declare -A LABELS=(
+  ["status:planning"]="FBCA04"
+  ["status:in-progress"]="1D76DB"
+  ["status:blocked"]="D93F0B"
+  ["status:architecture-decided"]="1D76DB"
+  ["status:design-decided"]="0E8A16"
+  ["status:build-passing"]="0E8A16"
+  ["status:tests-passing"]="0E8A16"
+  ["status:pr-ready"]="FBCA04"
+  ["status:review-passed"]="0E8A16"
+)
+
+# fe scope: FE repo only | be scope: BE repo only | full scope: both
+for repo in <affected-repos>; do
+  for label in "${!LABELS[@]}"; do
+    gh label create "$label" --repo "$repo" --color "${LABELS[$label]}" 2>/dev/null || true
+  done
+done
+```
+
+Apply `status:planning` to the created issue(s).
+
+## Step 10: Output Summary
+
+### 10a: FE-only Summary (SCOPE == "fe")
+
+```
+Feature Planning Complete
+=========================
+
+Scope:          FE-only
+FE Issue:       $FE_GITHUB_REPO#<number> — <title>
+                https://github.com/$FE_GITHUB_REPO/issues/<number>
+
+Milestone:      <milestone or "None">
+Labels:         status:planning
+Priority:       <priority> | Impact: <impact> | Effort: <effort>
+
+Next steps:
+1. Both @LEFTEQ and @genesiscz should read the issue and check their boxes
+2. To implement:
+   cd <FRONTEND_DIR>
+   /reservine-dx:implement-plan <fe-issue-number>
+```
+
+Then `AskUserQuestion`:
+- **Done** — finish here
+- **Create BE cross-plan** — create a `.intent.md` in the BE repo if backend changes are needed later (invokes `reservine-dx:cross-plan`)
+- **Run Apple Design Director critique** — screenshot related screens via Playwright MCP
+
+### 10b: BE-only Summary (SCOPE == "be")
+
+```
+Feature Planning Complete
+=========================
+
+Scope:          BE-only
+BE Issue:       $BE_GITHUB_REPO#<number> — <title>
+                https://github.com/$BE_GITHUB_REPO/issues/<number>
+
+Milestone:      <milestone or "None">
+Labels:         status:planning
+Priority:       <priority> | Impact: <impact> | Effort: <effort>
+
+Next steps:
+1. Both @LEFTEQ and @genesiscz should read the issue and check their boxes
+2. To implement:
+   cd <BACKEND_DIR>
+   /reservine-dx:implement-plan <be-issue-number>
+```
+
+Then `AskUserQuestion`:
+- **Done** — finish here
+- **Create FE cross-plan** — create a `.intent.md` in the FE repo if frontend changes are needed later (invokes `reservine-dx:cross-plan`)
+
+### 10c: Full Summary (SCOPE == "full")
+
+```
+Feature Planning Complete
+=========================
+
+Scope:          Full (both repos)
+FE Issue (Parent):  $FE_GITHUB_REPO#<number> — <title>
+                    https://github.com/$FE_GITHUB_REPO/issues/<number>
+
+BE Issue (Child):   $BE_GITHUB_REPO#<number> — <title>
+                    https://github.com/$BE_GITHUB_REPO/issues/<number>
+
+Relationship:       FE is parent, BE is sub-issue
+Milestone:          <milestone or "None">
+Labels:             status:planning (both repos)
+Priority:           <priority> | Impact: <impact> | Effort: <effort>
+
+Next steps:
+1. Both @LEFTEQ and @genesiscz should read the issues and check their boxes
+2. To implement BE first:
+   cd <BACKEND_DIR>
+   /reservine-dx:implement-plan <be-issue-number>
+3. To implement FE:
+   cd <FRONTEND_DIR>
+   /reservine-dx:implement-plan <fe-issue-number>
+```
+
+Then `AskUserQuestion`:
+- **Done** — finish here
+- **Run Apple Design Director critique** — screenshot related screens via Playwright MCP
+- **Create intent file** — write a `.intent.md` cross-plan file for the BE repo
+
+---
+
+## Config Variables
+
+| Variable | Source | Purpose |
+|----------|--------|---------|
+| `GITHUB_REPO` | `.claude/config` | Current repo for `gh` commands |
+| `FRONTEND_DIR` / `BACKEND_DIR` | `.claude/config` | Path to sibling repo |
+| `*_ABSOLUTE` variants | `.claude/config.local` | Worktree-safe absolute paths |
+| Sibling `GITHUB_REPO` | `<sibling>/.claude/config` | Other repo for `gh` commands |
+
+## Error Recovery
+
+| Step | Failure | Recovery |
+|------|---------|----------|
+| 1 | Sibling config not found | Use defaults: `LEFTEQ/reservine` (FE), `genesiscz/ReservineBack` (BE) |
+| 1 | Can't detect FE vs BE | `AskUserQuestion`: "Which repo is this?" |
+| 2 | Invalid scope prefix | Ignore prefix, treat entire string as description, ask for scope |
+| 5 | No milestones found | Skip milestone assignment |
+| 6 | Issue creation fails | Check `gh auth status`, verify repo access |
+| 7 | Sub-issues API not available | Fall back to cross-reference comments only |
+| 9 | Label creation fails | Labels may already exist — this is fine (idempotent) |