docs: AGENTS.md -- MANDATORY treatment for structurally-enforced rules #62
No reviewers
Labels
No labels
Agent
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
joshtronic/igor!62
Loading…
Reference in a new issue
No description provided.
Delete branch "docs/mandatory-rules-loud"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Same pattern as the PR_BODY.md fix: rules that are NOT suggestions
should not read like suggestions. Strengthened the load-bearing
ones with MANDATORY + NOT OPTIONAL framing, plus the actual
consequence ("harness HARD-BLOCKS", "harness REFUSES to push and
BLOCKS the issue") so the rule connects to the real effect.
Targeted:
Left as soft preferences (still bold but not MANDATORY):
PR_BODY.md section intentionally left alone -- handled by the
separate fix/pr-body-mandatory PR. The two branches don't conflict.
Going all-caps everywhere would dilute the signal. The point of
MANDATORY is to identify the rules with structural consequences,
not to yell at every preference.
Same pattern as the PR_BODY.md fix: rules that are NOT suggestions should not read like suggestions. Strengthened the load-bearing ones with MANDATORY + NOT OPTIONAL framing, plus the actual consequence ("harness HARD-BLOCKS", "harness REFUSES to push and BLOCKS the issue") so the rule connects to the real effect. Targeted: - Scope cap (~400 lines): harness hard-blocks larger - Tests + lint before exit: branch state IS the PR state - /security-review: shipping leaked-secret/injection bugs - Never commit to main/master/qa: harness refuses push - Don't push/fetch directly: harness owns remote ops, racing breaks - CI workflows off-limits: harness refuses push + blocks issue Left as soft preferences (still bold but not MANDATORY): - One issue, one outcome - Treat issue body as authoritative - No in-tick clarifying questions (no human present anyway) PR_BODY.md section intentionally left alone -- handled by the separate fix/pr-body-mandatory PR. The two branches don't conflict. Going all-caps everywhere would dilute the signal. The point of MANDATORY is to identify the rules with structural consequences, not to yell at every preference.