v0.7.0 — sandbox staging gate

Inserts a sandbox staging gate between local smoke and prod. Chain grows from 11 → 15 subtasks, with two human gates (sandbox manual test, merge approval). Architect review moves earlier (subtask 7, pre-sandbox). See PR #1 for full details.

v0.5.0 — jira-architect-review skill with dynamic sizing

Third skill in the plugin. Right-sizes the architect review to the feature being shipped.

Why

The 10-angle review was designed for framework-level changes (like WFR-5's Export Framework — 32 files, 3925 lines). Running all 10 on a 3-line typo fix is waste; running all 10 every time also creates review fatigue, which leads to rubber-stamping.

How it sizes

Autodetects feature size from the diff:

Size	Triggers	Angles
Minor	≤ 3 files, ≤ 50 lines, no migration, no new endpoints	3 (correctness, security, rollback)
Small	≤ 10 files, ≤ 300 lines, maybe 1 migration	5 (+ data integrity, UX polish)
Medium	≤ 20 files, ≤ 1000 lines, cross-module impact	7 (+ cross-system, performance)
Large	20+ files OR new module OR 500+ lines OR touches auth	10 (all angles)

Forced-include rules keep risk-sensitive angles in scope regardless of size: anything touching auth code forces the Auth angle; any migration forces Data integrity; frontend changes at Small+ force UX polish; new async code paths (cron, workers) force Observability.

Written size decision on line 1 of the Jira comment for audit: Review size: LARGE — 32 files, +3925/-59 lines, 1 migration, 5 new endpoints, 1 new module. Using all 10 angles.

Skill files

• skills/jira-architect-review/SKILL.md — orchestration, sizing rules, angle-selection table, return format
• skills/jira-architect-review/references/angles-library.md — full checklist per angle
• skills/jira-architect-review/references/sizing-heuristics.md — real-example calibration per tier

Wiring

• subtask-templates.md subtask 8 now prefers jira-architect-review and falls back to superpowers:code-reviewer
• jira-story-execute SKILL.md lists the new skill in Related

Unchanged

Same plugin-level userConfig. Install path is /plugin install jira-sprint-workflow@carma-plugins as before; this is a minor skill addition, no breaking changes.

v0.4.0 — frictions from the first live dogfood run

All captured frictions from the first live production-ship of this skill (Carma365 WFR-5 / Export Framework):

Already shipped in 0.3.x

• Autonomy guard: orchestrator MUST poll TaskOutput each tick instead of relying on in-context notifications (failure-handling.md)
• Subtask 9 ALWAYS opens a PR, never merges directly to main (subtask-templates.md)

New in 0.4.0

• Dispatch contract now documents environment gotchas so sub-agents do not waste tool calls rediscovering them:

  • Atlassian MCP token expires mid-run — immediately fall back to raw REST with creds from auto-memory
  • Sandbox PATH is missing mkdir/cat/head/grep/git/docker/python3 — use absolute paths or Read/Grep/bun
  • Bun is first-class; most work can be scripted with bun -e + fetch
  • Shared-state side effects may be hook-blocked — escalate cleanly rather than retry

• Failure-handling now covers:

  • Skipping fix subtasks (3, 5) when the main subtask returns clean — do not dispatch no-op sub-agents
  • Pre-existing bugs discovered mid-chain — guidance on fix-inline (small defensive fixes, flag to architect) vs. escalate (larger / scope-risk); 2-cycle cap before escalating to avoid the iterate-until-right loop we hit on bootstrap-migrations.ts

What worked unchanged

• 10-step chain + 1 human checkpoint at subtask 7
• Fix-loop pattern (2 ↔ 3, 4 ↔ 5) up to 3 cycles
• Self-contained subtask descriptions (teammate/sub-agent can execute without leaving Jira)
• Bundled-vs-cherry-pick decision at architect review stage

Live-run stats

• ~1.04M tokens total across ~100 min of chain execution
• 11 sub-agents dispatched, 1 fix-loop cycle, 1 unplanned bootstrap detour
• Shipped the Export Framework + Agents export to https://c360.carma365.com in the same session