Skip to content

Document required priorities for active issues #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
kirkmarple-clockgrove merged 1 commit into from
Oct 14, 2026
Merged

Document required priorities for active issues #20

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,14 @@ Set the native GitHub issue type explicitly:

Use labels for independent information such as area, priority, phase or Factory role. Do not add redundant `bug`, `enhancement`, `feature` or `task` classification labels. Preserve required role labels such as `factory:objective` and `factory:work-item`.

Maintainers and agents must assign exactly one existing priority when creating an issue or triaging the active backlog. The Clockgrove convention is:

- `P0`: urgent security/data loss, duplicate effects or stranded work.
- `P1`: current critical-path delivery or incorrect behavior with a supported workaround.
- `P2`: low-impact bugs, optional improvements, cleanup or deferred qualification.

Work Items normally inherit their parent's priority unless their own impact justifies a difference. Verify priority after issue creation or Factory projection, and preserve an existing priority unless evidence supports a change. Native type and blocked status do not determine priority. If the target has no configured priority labels, have its maintainer establish the approved convention rather than inventing a fallback.

Issue forms must set their top-level `type`. When creating an issue through a CLI or API, supply the type explicitly and verify the returned issue's type and labels. Do not assume a title or label assigned the type, and do not leave issues untyped when an appropriate native type is available.

An issue's type or Project placement does not authorize execution, spending or deployment. Follow the target repository's existing approval and delivery rules. Keep credentials, private source and raw agent transcripts out of public issues.
Loading