mathias/hyperguild
1
0
Fork 0
Code Issues 30 Pull Requests 3 Actions Packages Projects Releases Wiki Activity

Caveman declarations in ntfy approval messages for HIGH/CRITICAL ops (Phase 3 — GATED) #41

New Issue
Open
opened 2026-06-12 20:39:53 +00:00 by mathias · 0 comments
mathias commented 2026-06-12 20:39:53 +00:00
Owner
Copy Link
Copy Source

Context

Phase 3 of the ubiquitous-language system. The risk-tier approval middleware already sends ntfy messages for HIGH/CRITICAL operations. This change: the agent's caveman declaration becomes the headline of the approval message, so the human approves the declared intent, not a raw tool call. A declaration that fails the rubric is grounds for denial before reading the payload.

Motivating example: the 2026-04-27 ip rule flush incident. A rubric-valid declaration ("caveman: me restart kube-router, not touch Tailscale routes") would have surfaced the misdiagnosis at approval time.

GATED — do not start until: Phase 1 pilot (mathias/tapir#18) shows caveman declarations are meaningful in practice. Check with the human before picking this up.

Spec

  1. Approval middleware accepts an optional caveman field on HIGH/CRITICAL operation requests.
  2. ntfy message format: caveman line as title, tool + args summary as body. Missing caveman on HIGH/CRITICAL → message is prefixed [NO DECLARATION] (flag, do not block — blocking is a later decision pending evidence).
  3. LOW/MEDIUM tiers: untouched, no caveman expected (F3 bureaucracy guard).
  4. Log every (tier, caveman-present, approved/denied) tuple — this is the dataset for deciding whether to ever hard-require declarations.

Acceptance criteria

  • HIGH/CRITICAL ntfy messages lead with the caveman line when present
  • [NO DECLARATION] prefix on missing declarations, never a block
  • LOW/MEDIUM paths byte-identical to current behavior (regression test)
  • Decision log emitted (format: jsonl, location per existing middleware conventions)

Out of scope

Automated rubric validation (human judges validity at approval time for now), any change to tier classification itself.

## Context Phase 3 of the ubiquitous-language system. The risk-tier approval middleware already sends ntfy messages for HIGH/CRITICAL operations. This change: the agent's **caveman declaration** becomes the headline of the approval message, so the human approves the declared intent, not a raw tool call. A declaration that fails the rubric is grounds for denial before reading the payload. Motivating example: the 2026-04-27 `ip rule flush` incident. A rubric-valid declaration ("caveman: me restart kube-router, not touch Tailscale routes") would have surfaced the misdiagnosis at approval time. **GATED — do not start until:** Phase 1 pilot (mathias/tapir#18) shows caveman declarations are meaningful in practice. Check with the human before picking this up. ## Spec 1. Approval middleware accepts an optional `caveman` field on HIGH/CRITICAL operation requests. 2. ntfy message format: caveman line as title, tool + args summary as body. Missing caveman on HIGH/CRITICAL → message is prefixed `[NO DECLARATION]` (flag, do not block — blocking is a later decision pending evidence). 3. LOW/MEDIUM tiers: untouched, no caveman expected (F3 bureaucracy guard). 4. Log every (tier, caveman-present, approved/denied) tuple — this is the dataset for deciding whether to ever hard-require declarations. ## Acceptance criteria - [ ] HIGH/CRITICAL ntfy messages lead with the caveman line when present - [ ] `[NO DECLARATION]` prefix on missing declarations, never a block - [ ] LOW/MEDIUM paths byte-identical to current behavior (regression test) - [ ] Decision log emitted (format: jsonl, location per existing middleware conventions) ## Out of scope Automated rubric validation (human judges validity at approval time for now), any change to tier classification itself.
mathias added the risk/highsize/stype/feat labels 2026-08-27 05:25:41 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agent/ready
Meets the agent-ready contract; authorizes unattended execution
 blocked/client
Waiting on the client
 blocked/supplier
Waiting on a supplier
 blocked/upstream
Waiting on an upstream project or vendor
 risk/high
Irreversible, security-relevant, or control plane
 risk/low
Reversible, local, test-covered
 risk/medium
Touches shared state, deploys or data
 size/l
Too big - split it
 size/m
Under two days
 size/s
Under half a day
 size/xs
Under an hour
 status:dispatch
status:dispatched
status:review
status:reviewing
type/chore
Maintenance, no behaviour change
 type/decision
Human decision required; never agent/ready
 type/docs
Documentation only
 type/feat
New capability
 type/fix
Corrects broken behaviour
 type/ops
Infrastructure, deploy, runtime
 type/research
Investigate; output is a finding, not code
 type/test
Test coverage only
No labels risk/high size/s type/feat
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
renovate-bot mathias
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mathias/hyperguild#41