chief-clancy 0.5.4 → 0.5.6

package/src/roles/setup/workflows/settings.md

@@ -51,6 +51,7 @@ General
   [G1] Max iterations    {MAX_ITERATIONS:-5}          tickets per /clancy:run session
   [G2] Claude model      {CLANCY_MODEL:-default}     model used for each ticket session
   [G3] Base branch       {CLANCY_BASE_BRANCH:-main}
+  [G4] Max rework        {CLANCY_MAX_REWORK:-3}
 
 {If Jira:}
 Jira
@@ -61,16 +62,12 @@ Jira
   [B5] Done status       {CLANCY_STATUS_DONE if set, else off}
   [B6] Review status     {CLANCY_STATUS_REVIEW if set, else "uses Done status"}
 
-{If GitHub:}
-GitHub
-  (No board-specific settings — labels are managed in GitHub directly)
-
 {If Linear:}
 Linear
   [B1] Label filter      {CLANCY_LABEL if set, else off}
   [B2] Pickup status     {CLANCY_STATUS_IN_PROGRESS if set, else off}
   [B3] Done status       {CLANCY_STATUS_DONE if set, else off}
-  [B4] Review status     {CLANCY_STATUS_REVIEW if set, else "uses Done status"}
+  [B4] Review status     {CLANCY_STATUS_REVIEW if set, else "uses Done state"}
 
 Roles
   [R1] Planner           {✅ enabled / ─ disabled}
@@ -83,6 +80,8 @@ Planner
   [P1] Plan label         {CLANCY_PLAN_LABEL:-needs-refinement}
 {If Linear:}
   [P1] Plan state type    {CLANCY_PLAN_STATE_TYPE:-backlog}
+{If Jira:}
+  [P2] Post-approval      {CLANCY_STATUS_PLANNED if set, else "off"}
 
 Git Host (PR creation)
   [H1] Git host token    {platform: GitHub/GitLab/Bitbucket or "not set"}
@@ -156,6 +155,24 @@ Write `CLANCY_BASE_BRANCH=<value>` to `.clancy/.env`.
 
 ---
 
+### [G4] Max rework cycles
+
+```
+Max rework cycles — current: {value or 3}
+After this many rework cycles on a single ticket, Clancy flags it for human intervention.
+
+[1] 3 (default)
+[2] Enter a different number
+[3] Cancel
+```
+
+Validate the input is a positive integer between 1 and 20. If invalid, re-prompt.
+
+If [1]: remove `CLANCY_MAX_REWORK` from `.clancy/.env` (uses default).
+If [2]: prompt `How many rework cycles before human intervention?` then write `CLANCY_MAX_REWORK=<value>` to `.clancy/.env`.
+
+---
+
 ### [B1] Jira status filter (Jira only)
 
 ```
@@ -327,7 +344,7 @@ If [2]: remove `CLANCY_STATUS_REVIEW` from `.clancy/.env`.
 ```
 Planner role — currently: {enabled / disabled}
 The Planner refines vague backlog tickets into structured implementation plans.
-Commands: /clancy:plan, /clancy:approve
+Commands: /clancy:plan, /clancy:approve-plan
 
 [1] Enable
 [2] Disable
@@ -394,6 +411,24 @@ If [3]: prompt `What state type should /clancy:plan fetch from?` then write `CLA
 
 ---
 
+### [P2] Post-approval transition (Jira only)
+
+Only shown when Planner is enabled and board is Jira.
+
+```
+Post-approval transition — current: {value or "off"}
+After approving a plan, transition the ticket to this status.
+
+[1] Set status name
+[2] Off (move manually)
+[3] Cancel
+```
+
+If [1]: prompt `What status should Clancy transition to after approving a plan? (e.g. To Do, Ready)` then write `CLANCY_STATUS_PLANNED=<value>` to `.clancy/.env`. Wrap in double quotes.
+If [2]: remove `CLANCY_STATUS_PLANNED` from `.clancy/.env`.
+
+---
+
 ### [H1] Git host token
 
 Only shown for Jira and Linear boards. GitHub Issues users already have `GITHUB_TOKEN` for PR creation.

package/src/templates/CLAUDE.md

@@ -54,7 +54,9 @@ Log completed tickets to `.clancy/progress.txt`:
 `YYYY-MM-DD HH:MM | TICKET-KEY | Summary | DONE`
 
 Planning entries use: `YYYY-MM-DD HH:MM | TICKET-KEY | PLAN | S/M/L`
+Revised plan entries use: `YYYY-MM-DD HH:MM | TICKET-KEY | REVISED | S/M/L`
 Approval entries use: `YYYY-MM-DD HH:MM | TICKET-KEY | APPROVE | —`
+Failed comment posts use: `YYYY-MM-DD HH:MM | TICKET-KEY | POST_FAILED | {reason}`
 
 ### Design context
 When a ticket description contains a Figma URL, fetch design context before implementing.

package/src/roles/planner/commands/approve.md

@@ -1,7 +0,0 @@
-# /clancy:approve
-
-Promote an approved Clancy plan to the ticket description. Requires a ticket key argument (e.g. `/clancy:approve PROJ-123`).
-
-@.claude/clancy/workflows/approve.md
-
-Follow the approve workflow above. Fetch the plan comment, confirm with the user, and append it to the ticket description.

package/src/roles/planner/workflows/approve.md

@@ -1,237 +0,0 @@
-# Clancy Approve Workflow
-
-## Overview
-
-Promote an approved Clancy plan from a ticket comment to the ticket description. The plan is appended below the existing description, never replacing it.
-
----
-
-## Step 1 — Preflight checks
-
-1. Check `.clancy/` exists and `.clancy/.env` is present. If not:
-   ```
-   .clancy/ not found. Run /clancy:init to set up Clancy first.
-   ```
-   Stop.
-
-2. Source `.clancy/.env` and check board credentials are present.
-
----
-
-## Step 2 — Parse argument
-
-The user must provide a ticket key as an argument (e.g. `/clancy:approve PROJ-123`).
-
-If no key is provided:
-```
-Usage: /clancy:approve PROJ-123
-```
-Stop.
-
----
-
-## Step 3 — Fetch the plan comment
-
-Detect board from `.clancy/.env` and fetch comments for the specified ticket.
-
-### Jira
-
-```bash
-RESPONSE=$(curl -s \
-  -u "$JIRA_USER:$JIRA_API_TOKEN" \
-  -H "Accept: application/json" \
-  "$JIRA_BASE_URL/rest/api/3/issue/$TICKET_KEY/comment")
-```
-
-### GitHub
-
-First, determine the issue number from the ticket key (strip the `#` prefix if present):
-
-```bash
-RESPONSE=$(curl -s \
-  -H "Authorization: Bearer $GITHUB_TOKEN" \
-  -H "X-GitHub-Api-Version: 2022-11-28" \
-  "https://api.github.com/repos/$GITHUB_REPO/issues/$ISSUE_NUMBER/comments")
-```
-
-### Linear
-
-```graphql
-query {
-  issue(id: "<issue-id>") {
-    id identifier title description
-    comments { nodes { body createdAt } }
-  }
-}
-```
-
-For Linear, the user provides the issue identifier (e.g. `ENG-42`). Look up the issue by identifier to get the internal ID and comments:
-
-```graphql
-query {
-  issueSearch(query: "$IDENTIFIER", first: 5) {
-    nodes {
-      id identifier title description
-      comments { nodes { body createdAt } }
-    }
-  }
-}
-```
-
-**Important:** `issueSearch` is a fuzzy text search. After fetching results, verify the returned issue's `identifier` field exactly matches the provided key (case-insensitive). If no exact match is found in the results, report: `❌ Issue {KEY} not found. Check the identifier and try again.`
-
-Search the comments for the most recent one containing `## Clancy Implementation Plan`.
-
-If no plan comment is found:
-```
-❌ No Clancy plan found for {KEY}. Run /clancy:plan first.
-```
-Stop.
-
----
-
-## Step 3b — Check for existing plan in description
-
-Before confirming, check if the ticket description already contains `## Clancy Implementation Plan`.
-
-If it does:
-```
-⚠️  This ticket's description already contains a Clancy plan.
-Continuing will add a duplicate.
-
-[1] Continue anyway
-[2] Cancel
-```
-
-If the user picks [2], stop: `Cancelled. No changes made.`
-
----
-
-## Step 4 — Confirm
-
-Display a summary and ask for confirmation:
-
-```
-🚨 Clancy — Approve
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-[{KEY}] {Title}
-Size: {S/M/L} | {N} affected files
-Planned: {date from plan}
-
-Promote this plan to the ticket description? [Y/n]
-```
-
-If the user declines, stop:
-```
-Cancelled. No changes made.
-```
-
----
-
-## Step 5 — Update ticket description
-
-Append the plan below the existing description with a separator. Never overwrite the original description.
-
-The updated description follows this format:
-```
-{existing description}
-
----
-
-{full plan content}
-```
-
-### Jira — PUT issue
-
-Fetch the current description first:
-```bash
-CURRENT=$(curl -s \
-  -u "$JIRA_USER:$JIRA_API_TOKEN" \
-  -H "Accept: application/json" \
-  "$JIRA_BASE_URL/rest/api/3/issue/$TICKET_KEY?fields=description")
-```
-
-Merge the existing ADF description with a `rule` node (horizontal rule) and the plan content as new ADF nodes. Then update:
-
-```bash
-curl -s \
-  -u "$JIRA_USER:$JIRA_API_TOKEN" \
-  -X PUT \
-  -H "Content-Type: application/json" \
-  -H "Accept: application/json" \
-  "$JIRA_BASE_URL/rest/api/3/issue/$TICKET_KEY" \
-  -d '{"fields": {"description": <merged ADF>}}'
-```
-
-If ADF construction fails for the plan content, wrap the plan in a `codeBlock` node as fallback.
-
-### GitHub — PATCH issue
-
-Fetch the current body:
-```bash
-CURRENT=$(curl -s \
-  -H "Authorization: Bearer $GITHUB_TOKEN" \
-  -H "X-GitHub-Api-Version: 2022-11-28" \
-  "https://api.github.com/repos/$GITHUB_REPO/issues/$ISSUE_NUMBER")
-```
-
-Append the plan:
-```bash
-curl -s \
-  -H "Authorization: Bearer $GITHUB_TOKEN" \
-  -H "X-GitHub-Api-Version: 2022-11-28" \
-  -X PATCH \
-  "https://api.github.com/repos/$GITHUB_REPO/issues/$ISSUE_NUMBER" \
-  -d '{"body": "<existing body>\n\n---\n\n<plan>"}'
-```
-
-### Linear — issueUpdate mutation
-
-Fetch the current description:
-```graphql
-query { issue(id: "$ISSUE_ID") { description } }
-```
-
-Update with appended plan:
-```graphql
-mutation {
-  issueUpdate(
-    id: "$ISSUE_ID"
-    input: { description: "<existing>\n\n---\n\n<plan>" }
-  ) { success }
-}
-```
-
----
-
-## Step 6 — Confirm and log
-
-On success:
-```
-✅ Plan promoted to description for [{KEY}].
-
-Move [{KEY}] to your implementation queue (e.g. "To Do") so /clancy:once picks it up.
-
-"Book 'em, Lou." — The ticket is ready for /clancy:once.
-```
-
-Append to `.clancy/progress.txt`:
-```
-YYYY-MM-DD HH:MM | {KEY} | APPROVE | —
-```
-
-On failure:
-```
-❌ Failed to update description for [{KEY}]. Check your board permissions.
-```
-
----
-
-## Notes
-
-- This command only appends — it never overwrites the existing ticket description
-- If the ticket has multiple plan comments, the most recent one is used
-- The plan content is taken verbatim from the comment — no regeneration
-- Step 3b checks for existing plans in the description to prevent accidental duplication
-- The ticket key is case-insensitive — accept `PROJ-123`, `proj-123`, or `#123` (GitHub)