Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 73 Pull Requests 9 Actions Packages Projects Releases Wiki Activity

Require canonical next-action comments on issues, PRs, and discussions #495

New Issue
Closed
opened 2026-07-08 02:02:03 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-08 02:02:03 -05:00
Owner
Copy Link
Copy Source

Problem

LLM sessions need to continue work from Gitea state, not from private chat history. Right now, issues and PRs can receive comments, reviews, blockers, or discussion without a clear canonical handoff saying who acts next and what exact prompt should be run.

This causes future LLMs to lose context, duplicate work, ask the user what to do, or make unsafe assumptions.

Goal

Make every issue, PR, and discussion self-contained inside Gitea. Any LLM should be able to open the object, read the latest canonical state/next-action comment, and continue correctly.

Core rule

Every meaningful workflow transition must leave a canonical comment that answers:

  1. What happened?
  2. What is the current state?
  3. Who is next inline?
  4. What should they do next?
  5. What exact prompt should they run?
  6. What proof or blocker matters?
  7. Why was this direction chosen?

Required behavior

  1. If an issue receives a blocker/comment that changes the work direction, a reviewer or controller must weigh in with a canonical solution comment before author work continues.
  2. If a PR review requests changes, the review or follow-up controller comment must say exactly what the author should do next.
  3. If a PR is approved, the latest PR state must say whether the next actor is merger or controller.
  4. If a PR is superseded, the latest PR state must name the canonical PR and say the next actor is reconciler.
  5. If an issue is blocked, the latest issue state must say exactly what unblocks it.
  6. If an issue is ready for work, the latest issue state must include an author prompt.
  7. If a discussion has matured, the controller must summarize it and create/link issues.
  8. Discussions should normally have at least 5 substantive comments before being converted into issues, unless marked trivial, urgent, or mechanical.
  9. The final discussion summary must include the decision, issues created, unresolved questions, and next queue action.
  10. The queue controller must prefer the latest canonical state comments over chat history.

Canonical issue comment format

## Canonical Issue State

STATE:
<ready-for-author | in-progress | blocked | PR-open | needs-review | ready-to-merge | merged | closed | superseded>

WHO_IS_NEXT:
<controller | author | reviewer | merger | reconciler | user>

NEXT_ACTION:
<one sentence>

NEXT_PROMPT:
<paste-ready prompt>

WHAT_HAPPENED:
<summary of latest meaningful event>

WHY:
<decision rationale>

RELATED_DISCUSSION:
<link or none>

RELATED_PRS:
- #...

BRANCH:
<branch or none>

HEAD_SHA:
<sha or none>

VALIDATION:
<tests/proofs or none>

BLOCKERS:
<blockers or none>

LAST_UPDATED_BY:
<identity/profile/date>

Canonical PR comment format

## Canonical PR State

STATE:
<needs-review | changes-requested | approved | stale-approval | ready-to-merge | merged | blocked | superseded>

WHO_IS_NEXT:
<controller | author | reviewer | merger | reconciler | user>

NEXT_ACTION:
<one sentence>

NEXT_PROMPT:
<paste-ready prompt>

WHAT_HAPPENED:
<summary of latest meaningful event>

WHY:
<decision rationale>

ISSUE:
#...

BASE:
<branch>

HEAD:
<branch>

HEAD_SHA:
<sha>

REVIEW_STATUS:
<none | approved | changes-requested | stale | contaminated>

VALIDATION:
<tests/proofs>

BLOCKERS:
<blockers or none>

SUPERSEDES:
<PRs or none>

SUPERSEDED_BY:
<PR or none>

MERGE_READY:
<yes/no and why>

LAST_UPDATED_BY:
<identity/profile/date>

Canonical discussion summary format

## Canonical Discussion Summary

STATE:
<needs-more-discussion | ready-for-issues | issues-created | closed>

WHO_IS_NEXT:
<controller | author | reviewer | user>

DECISION:
<what was decided>

WHY:
<reasoning and tradeoffs>

SUBSTANTIVE_COMMENTS:
<count and summary>

ISSUES_TO_CREATE_OR_CREATED:
- #...

DEPENDENCY_ORDER:
<order>

NON_GOALS:
<non-goals>

OPEN_QUESTIONS:
<questions or none>

NEXT_ACTION:
<one sentence>

NEXT_PROMPT:
<paste-ready prompt>

LAST_UPDATED_BY:
<identity/profile/date>

Acceptance criteria

  1. Add documentation for canonical state comments on issues, PRs, and discussions.
  2. Add templates for issue, PR, and discussion state comments.
  3. Add queue-controller guidance: read latest canonical state comments before choosing work.
  4. Add final-report validator rules requiring: STATE, WHO_IS_NEXT, NEXT_ACTION, NEXT_PROMPT.
  5. Add validator tests that reject reports/comments where the next actor is missing.
  6. Add validator tests that reject vague next actions like "continue" or "handle this."
  7. Add tests for review/change-request workflows requiring an author prompt.
  8. Add tests for approved PR workflows requiring a merger prompt.
  9. Add tests for superseded PR workflows requiring a reconciler prompt.
  10. Add tests for blocked issue workflows requiring an unblock condition.
  11. Add discussion lifecycle docs requiring at least 5 substantive comments before issue creation unless explicitly waived.
  12. Add examples for: issue ready for author; issue blocked; PR needs review; PR approved; PR superseded; discussion ready for issue creation.

Non-goals

  • Do not replace Gitea as the system of record.
  • Do not rely on ChatGPT/Claude chat history.
  • Do not weaken role separation.
  • Do not require all comments to be canonical; only workflow-changing comments need canonical state.
  • Do not build the full web UI in this issue.

Duplicate note

Supersedes/expands the draft spec in issue #494 if duplicate detection links them. Prefer implementing once under the canonical tracking issue.

## Problem LLM sessions need to continue work from Gitea state, not from private chat history. Right now, issues and PRs can receive comments, reviews, blockers, or discussion without a clear canonical handoff saying who acts next and what exact prompt should be run. This causes future LLMs to lose context, duplicate work, ask the user what to do, or make unsafe assumptions. ## Goal Make every issue, PR, and discussion self-contained inside Gitea. Any LLM should be able to open the object, read the latest canonical state/next-action comment, and continue correctly. ## Core rule Every meaningful workflow transition must leave a canonical comment that answers: 1. What happened? 2. What is the current state? 3. Who is next inline? 4. What should they do next? 5. What exact prompt should they run? 6. What proof or blocker matters? 7. Why was this direction chosen? ## Required behavior 1. If an issue receives a blocker/comment that changes the work direction, a reviewer or controller must weigh in with a canonical solution comment before author work continues. 2. If a PR review requests changes, the review or follow-up controller comment must say exactly what the author should do next. 3. If a PR is approved, the latest PR state must say whether the next actor is merger or controller. 4. If a PR is superseded, the latest PR state must name the canonical PR and say the next actor is reconciler. 5. If an issue is blocked, the latest issue state must say exactly what unblocks it. 6. If an issue is ready for work, the latest issue state must include an author prompt. 7. If a discussion has matured, the controller must summarize it and create/link issues. 8. Discussions should normally have at least 5 substantive comments before being converted into issues, unless marked trivial, urgent, or mechanical. 9. The final discussion summary must include the decision, issues created, unresolved questions, and next queue action. 10. The queue controller must prefer the latest canonical state comments over chat history. ## Canonical issue comment format ```text ## Canonical Issue State STATE: <ready-for-author | in-progress | blocked | PR-open | needs-review | ready-to-merge | merged | closed | superseded> WHO_IS_NEXT: <controller | author | reviewer | merger | reconciler | user> NEXT_ACTION: <one sentence> NEXT_PROMPT: <paste-ready prompt> WHAT_HAPPENED: <summary of latest meaningful event> WHY: <decision rationale> RELATED_DISCUSSION: <link or none> RELATED_PRS: - #... BRANCH: <branch or none> HEAD_SHA: <sha or none> VALIDATION: <tests/proofs or none> BLOCKERS: <blockers or none> LAST_UPDATED_BY: <identity/profile/date> ``` ## Canonical PR comment format ```text ## Canonical PR State STATE: <needs-review | changes-requested | approved | stale-approval | ready-to-merge | merged | blocked | superseded> WHO_IS_NEXT: <controller | author | reviewer | merger | reconciler | user> NEXT_ACTION: <one sentence> NEXT_PROMPT: <paste-ready prompt> WHAT_HAPPENED: <summary of latest meaningful event> WHY: <decision rationale> ISSUE: #... BASE: <branch> HEAD: <branch> HEAD_SHA: <sha> REVIEW_STATUS: <none | approved | changes-requested | stale | contaminated> VALIDATION: <tests/proofs> BLOCKERS: <blockers or none> SUPERSEDES: <PRs or none> SUPERSEDED_BY: <PR or none> MERGE_READY: <yes/no and why> LAST_UPDATED_BY: <identity/profile/date> ``` ## Canonical discussion summary format ```text ## Canonical Discussion Summary STATE: <needs-more-discussion | ready-for-issues | issues-created | closed> WHO_IS_NEXT: <controller | author | reviewer | user> DECISION: <what was decided> WHY: <reasoning and tradeoffs> SUBSTANTIVE_COMMENTS: <count and summary> ISSUES_TO_CREATE_OR_CREATED: - #... DEPENDENCY_ORDER: <order> NON_GOALS: <non-goals> OPEN_QUESTIONS: <questions or none> NEXT_ACTION: <one sentence> NEXT_PROMPT: <paste-ready prompt> LAST_UPDATED_BY: <identity/profile/date> ``` ## Acceptance criteria 1. Add documentation for canonical state comments on issues, PRs, and discussions. 2. Add templates for issue, PR, and discussion state comments. 3. Add queue-controller guidance: read latest canonical state comments before choosing work. 4. Add final-report validator rules requiring: `STATE`, `WHO_IS_NEXT`, `NEXT_ACTION`, `NEXT_PROMPT`. 5. Add validator tests that reject reports/comments where the next actor is missing. 6. Add validator tests that reject vague next actions like "continue" or "handle this." 7. Add tests for review/change-request workflows requiring an author prompt. 8. Add tests for approved PR workflows requiring a merger prompt. 9. Add tests for superseded PR workflows requiring a reconciler prompt. 10. Add tests for blocked issue workflows requiring an unblock condition. 11. Add discussion lifecycle docs requiring at least 5 substantive comments before issue creation unless explicitly waived. 12. Add examples for: issue ready for author; issue blocked; PR needs review; PR approved; PR superseded; discussion ready for issue creation. ## Non-goals * Do not replace Gitea as the system of record. * Do not rely on ChatGPT/Claude chat history. * Do not weaken role separation. * Do not require all comments to be canonical; only workflow-changing comments need canonical state. * Do not build the full web UI in this issue. ## Duplicate note Supersedes/expands the draft spec in issue #494 if duplicate detection links them. Prefer implementing once under the canonical tracking issue.
jcwalker3 commented 2026-07-08 02:02:28 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE:
ready-for-author

WHO_IS_NEXT:
author

NEXT_ACTION:
Claim issue #495, implement docs/templates/validator rules and tests for canonical next-action comments on issues, PRs, and discussions.

NEXT_PROMPT:

You are the author LLM for Scaled-Tech-Consulting/Gitea-Tools on prgs.

Target: issue #495 — Require canonical next-action comments on issues, PRs, and discussions.

Preflight:
1. gitea_activate_profile → prgs-author
2. gitea_whoami + gitea_resolve_task_capability(task="work_issue")
3. gitea_lock_issue(495) from a clean branches/ worktree on prgs/master
4. Read issue #495 body and related draft #494; implement without duplicating scope

Deliverables:
- Documentation for canonical state comments (issue/PR/discussion)
- Templates with WHO_IS_NEXT, WHAT_HAPPENED, WHY fields
- Queue-controller guidance preferring latest canonical comments
- final_report_validator rules + tests (STATE, WHO_IS_NEXT, NEXT_ACTION, NEXT_PROMPT; reject vague actions; review/merge/supersede/blocked workflows)
- Discussion lifecycle docs (≥5 substantive comments unless waived)
- Examples for each workflow state listed in AC12

Validation: pytest for new/changed validator tests; full suite if practical.
Open PR when ready. Post canonical PR state comment when PR opens.

Do not weaken role separation. Do not build web UI. Do not touch /private/tmp/gitea_issue_lock.json.

WHAT_HAPPENED:
Durable workflow issue #495 filed with expanded operator spec for canonical next-action comments across issues, PRs, and discussions.

WHY:
Future LLM sessions must continue from Gitea state without chat memory; workflow-changing transitions need explicit handoff with paste-ready prompts.

RELATED_DISCUSSION:
none

RELATED_PRS:

  • none

BRANCH:
none

HEAD_SHA:
none

VALIDATION:
none (spec issue only)

BLOCKERS:
none

LAST_UPDATED_BY:
jcwalker3 / prgs-author / 2026-07-08

## Canonical Issue State STATE: ready-for-author WHO_IS_NEXT: author NEXT_ACTION: Claim issue #495, implement docs/templates/validator rules and tests for canonical next-action comments on issues, PRs, and discussions. NEXT_PROMPT: ```text You are the author LLM for Scaled-Tech-Consulting/Gitea-Tools on prgs. Target: issue #495 — Require canonical next-action comments on issues, PRs, and discussions. Preflight: 1. gitea_activate_profile → prgs-author 2. gitea_whoami + gitea_resolve_task_capability(task="work_issue") 3. gitea_lock_issue(495) from a clean branches/ worktree on prgs/master 4. Read issue #495 body and related draft #494; implement without duplicating scope Deliverables: - Documentation for canonical state comments (issue/PR/discussion) - Templates with WHO_IS_NEXT, WHAT_HAPPENED, WHY fields - Queue-controller guidance preferring latest canonical comments - final_report_validator rules + tests (STATE, WHO_IS_NEXT, NEXT_ACTION, NEXT_PROMPT; reject vague actions; review/merge/supersede/blocked workflows) - Discussion lifecycle docs (≥5 substantive comments unless waived) - Examples for each workflow state listed in AC12 Validation: pytest for new/changed validator tests; full suite if practical. Open PR when ready. Post canonical PR state comment when PR opens. Do not weaken role separation. Do not build web UI. Do not touch /private/tmp/gitea_issue_lock.json. ``` WHAT_HAPPENED: Durable workflow issue #495 filed with expanded operator spec for canonical next-action comments across issues, PRs, and discussions. WHY: Future LLM sessions must continue from Gitea state without chat memory; workflow-changing transitions need explicit handoff with paste-ready prompts. RELATED_DISCUSSION: none RELATED_PRS: - none BRANCH: none HEAD_SHA: none VALIDATION: none (spec issue only) BLOCKERS: none LAST_UPDATED_BY: jcwalker3 / prgs-author / 2026-07-08
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
allocator
Controller-owned work allocator
 anti-stomp
Prevent concurrent LLM session stomping
 architecture
Architecture / structural design
 bug
chore
codex
OpenAI Codex client / workflow session surface
 concurrency
Concurrent session safety
 contamination
Workflow or session contamination incident
 control-plane
MCP control-plane coordination and allocation authority
 dashboard
MCP operational dashboard/queue view
 database
Internal coordination storage (SQLite/Postgres)
 design
Design / investigation, no implementation
 documentation
Docs / runbooks
 enhancement
New feature or improvement
 gitea
Gitea MCP workflow
 glitchtip
GlitchTip integration
 important
incident
Operational or process incident requiring durable audit trail
 incident-bridge
Sentry-to-Gitea incident bridging
 integration
Integration testing
 jenkins
Jenkins integration
 labels
Label taxonomy management
 leases
Lease adopt/release/expire lifecycle
 mcp
MCP server / tooling
 mcp-health
MCP namespace and runtime health
 mcp-menu
MCP menu surface
 multi-project
Work spanning multiple monitoring projects or Gitea repos
 mutating
Mutating action; requires gating
 nice-to-have
observability
Observability, metrics, traces, error reporting
 portability
Cross-platform / portability
 preflight
Shared preflight gates before mutation
 protected-branch
Protected branch / stable-branch policy concern
 queue
Work queue visibility and allocation
 read-only
Read-only, no mutation
 reconnect
MCP client reconnect/reload recovery path
 recovery
Recovery paths for stale/foreign leases
 refactor
Code refactor / restructure
 release
Release / versioning
 reliability
Reliability / failure handling
 resumable-review
Persist and resume prepared review verdicts across sessions
 reviewer
Reviewer workflow tooling
 roadmap
Roadmap / umbrella issue
 safety
Safety rails and fail-closed mutation guards
 security
Security / trust boundary
 self-hosted
Self-hosted infrastructure integration
 sentry
Sentry error monitoring integration
 stale-runtime
Stale backend daemon / runtime-vs-master parity failures
 status:blocked
Issue is blocked
 status:in-progress
Issue is being worked on
 status:pr-open
Issue has an open pull request
 status:ready
Issue is ready for work
 terminal-lock
Terminal review lock (#332) path
 testing
Tests / test coverage
 tracker
Issue tracker hygiene / meta
 type:bug
Bug or defect
 type:feature
Feature or enhancement
 type:feature
Feature or enhancement
 type:guardrail
Safety gate or guardrail
 visibility
Workflow state visibility for LLMs/operators
 workflow
Cross-tool workflow
 workflow-hardening
LLM workflow coordination hardening
 workflow-hardening
LLM workflow coordination hardening
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#495