Skip to content

feat(triage-flow): create linked TOOL issue on completion; rename state file - #333

Closed
sergepr wants to merge 1 commit into
feat/triage-flow-harness-intakefrom
feat/triage-flow-tool-issue-link
Closed

feat(triage-flow): create linked TOOL issue on completion; rename state file#333
sergepr wants to merge 1 commit into
feat/triage-flow-harness-intakefrom
feat/triage-flow-tool-issue-link

Conversation

@sergepr

@sergepr sergepr commented Aug 28, 2026

Copy link
Copy Markdown

What

Stacked on #332. Adds a new terminal phase 6 to triage-flow: once phase 5 posts its assessment comment, create the corresponding Story in the configured target project (TOOL) from the finalized requirements, and link it back to the source ticket as an action item. Also renames the flow's own state file to match its sibling artifacts' naming convention.

This PR's diff is scoped to just this update — it is based on feat/triage-flow-harness-intake (#332), not main, so it will show only these changes. Once #332 merges, this PR's base should be retargeted to main.

Changes

New capability: linked TOOL issue on completion

  • workflows/triage-flow-create-tool-issue.md (new phase 6): two-state idempotency (create, then link — a link failure after a successful create is a resumable state, never a re-create, since there is no delete and a duplicate would be permanent).
  • skills/jira-write/ gains create issue and link issues capabilities (plus their mandatory preflight reads), extended dangerous-actions gate wording, new failure paths, and validation items.
  • agents/jira-triage.config.json gains a tool_issue_target block (project, issue type, carried fields, link type/direction) — by name, resolved to IDs at write time, never hardcoded.
  • triage-flow.md gains the phase 6 dispatch row, a new ## Tool Issue state section, and a resume-routing rule: a tick resuming after phase 5 already ran jumps straight to phase 6 (skipping phases 2-5), so phase 2's comment-ID idempotency check never misreads phase 5's own assessment comment as a new requester reply.

Unrelated cleanup, same scope (bundled per the approved plan)

  • Renamed triage-flow-state.md<TICKET-KEY>-TRIAGE-FLOW-STATE.md throughout the flow, matching the sibling <TICKET-KEY>-REQUIREMENTS.md / <TICKET-KEY>-TRIAGE-ASSESSMENT.md convention. Filename-only; the state file's internal section shape is unchanged.

Generated output

  • All plugin variants regenerated via scripts/pre_commit.py (npx -y rosettify-plugins@latest). No version bump in this change — plugins still read 3.1.12.

Verification

  • scripts/pre_commit.py run clean: hooks build, plugin sync (both profiles), type validation, and the full test suite (1441 hooks tests + 761 rosettify-plugins tests) all passed.
  • Repo-wide grep confirms zero remaining canonical-source references to the old triage-flow-state.md filename (only generated plugins/** copies, which this same regen pass already updated).

Open item flagged for follow-up

It is not yet verified whether the source ticket's raw assignee account ID survives data-collection/sensitive-data redaction into phase 1's snapshot, or whether redaction reduces it to a restricted/masked value — that determines whether created TOOL issues can carry an assignee. Worth confirming against one real tick before relying on it broadly.

🤖 Generated with Claude Code

…te file

Adds phase 6 (triage-flow-create-tool-issue.md): once phase 5 posts its
assessment comment, create the corresponding Story in the configured
target project from the finalized requirements and link it back to the
source ticket as an action item. Runs unattended, same as phases 4/5.

- Extend jira-write with `create issue` / `link issues` capabilities
  (plus their mandatory preflight reads), extended dangerous-actions
  gate wording, new failure paths, and validation items.
- Add agents/jira-triage.config.json's `tool_issue_target` block
  (project, issue type, carried fields, link type/direction) — by
  name, resolved to IDs at write time via jira-write's read-before-
  write ops, never hardcoded.
- Two-state idempotency in phase 6 and a new `## Tool Issue` state
  section: a link failure after a successful create is a resumable
  state (link-only retry), never a re-create — jira-write has no
  delete, so a duplicate would be permanent.
- Add the orchestrator's resume-routing rule: a tick resuming after
  phase 5 already ran jumps straight to phase 6, skipping phases 2-5,
  so phase 2's comment-ID check never misreads phase 5's own
  assessment comment as a new requester reply.
- Rename triage-flow-state.md -> <TICKET-KEY>-TRIAGE-FLOW-STATE.md
  throughout the flow, matching the sibling REQUIREMENTS/
  TRIAGE-ASSESSMENT artifact naming convention.
- Regenerate all plugin variants (scripts/pre_commit.py); no version
  bump in this change.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@sergepr

sergepr commented Aug 28, 2026

Copy link
Copy Markdown
Author

Superseded by #334, which carries only the triage-flow workflow, jira-write skill, and tool-issue-creation source (no plugins/* regeneration or version bumps — those come from CI). Closing this in favor of #334.

@sergepr sergepr closed this Aug 28, 2026
@sergepr
sergepr deleted the feat/triage-flow-tool-issue-link branch August 28, 2026 19:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant