investigate: audit confirm gates against the reversible and destructive split (slice 93)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 15/100
- Tipo di issue
- Documentazione
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Stack tecnologico
- markdown, shell
- Ambito
- devtools, documentation
Direzione di ricerca
Start by pinning a commit SHA and running the count step, since the issue depends on a local, untracked confirm-gates.sh that the contributor must write. The grep pattern is given in the issue and should cover plugins/*/skills, plugins/*/agents, AGENTS.md, docs/conventions, hook files, and .claude/settings.json. Done means a table with one row per hit, every non-reversible row checked by a verifier, and no tracked file changed.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Why
The 2,000-PRs talk Brief (Q27) asks that confirm gates follow the reversible and destructive split: an agent checks before deleting data or changing a shared or production system, and proceeds on reversible local work. The marketplace's skills, agents, conventions, hooks and settings carry many confirm gates that were never classified against that split, so some likely ask where they could proceed and a probe would answer the question. This slice (93) was planned in the integration branch's WS-O plan, Phase 17, and deferred out of the integration PR.
What
A read-only inventory of every confirm gate at one pinned commit, one table row per hit (no sampling), each classed reversible-local, destructive, visible-outward or cross-boundary with a keep-confirm, may-proceed or probe-first proposal, checked by a fresh-context verifier, then a user gate by class. Approved classes become new slices; this audit edits no tracked file. Changes to destructive-action confirms and AGENTS.md "When to stop" are the user's call (HITL).
Deferred plan text
Copied from the integration branch's local plan (WS-O.md Phase 17), which is not in the repository. <S> was the local work folder; put the untracked outputs in any scratch folder. "C16", "O20", "O5" and "DA F11" refer to local planning records.
### Phase 17: Confirm gates against the reversible and destructive split (slice 93) [TODO]
Q27; O20, O5 (the probe-rule wording change); DA F11. HITL (changes to destructive-action confirms and AGENTS.md "When
to stop" are the user's). No blocker; runs in the main session from plan approval [EXEC-SHAPE]. Commits nothing.
- [ ] `<S>/ws-o/confirm-gates.sh <sha>` (local, untracked; read-only): reads the tree of one commit through
`git grep -n -E <pattern> <sha> -- <paths>` and `git show <sha>:.claude/settings.json`, never the working tree, so
the count cannot drift while the table is built; one fixed pattern,
`AskUserQuestion|explicit (yes|go-ahead|approval|confirmation)|(ask|confirm)( with)?( the user)? before|wait(s)? for (the user|approval|a yes)|only on the user's (yes|go-ahead)`,
over `plugins/*/skills/**/*.md`, `plugins/*/agents/*.md`, `AGENTS.md` and `docs/conventions/**/*.md`, plus hook
gates (`plugins/*/hooks/**` files emitting an `ask` or `deny` permission decision) and `.claude/settings.json`
`permissions.ask` entries; prints one `<source>` TAB `<file>:<line>` TAB `<text>` row per hit, `source` one of
`skill`, `agent`, `convention`, `hook`, `settings`; the text is data and is never evaluated.
- [ ] Count first: the main session writes `git -C <worktree> rev-parse HEAD` to `<S>/ws-o/confirm-gates-sha.txt`,
runs the script once against that SHA, writes the row count to `<S>/ws-o/confirm-gates-count.txt`, and shows the
count and its per-source split to the user before any classification.
- [ ] `<S>/ws-o/confirm-gates.md`: one table row per script row, no sampling, columns
`| # | source | file:line | gate | class | proposal | verifier |`; `class` is one of `reversible-local`,
`destructive`, `visible-outward`, `cross-boundary` against the vendor statement (output-styles "Proactive": check
before deleting data or changing a shared or production system); `proposal` is one of `keep-confirm`,
`may-proceed`, `probe-first`; a `|` inside the gate text is escaped. Hook and settings gates are classified like
the rest; if the user excludes them, a line `Hook gates excluded: <reason>` replaces their rows. Below the table:
per-class toggle proposals with homes (the owning plugin's `docs/conventions/<plugin>.md` block plus `userConfig`,
a policy floor: the repository wins, a user only tightens); the probe-not-question rule's placement (fable-5
"Decide, or ask" beside planning:interview's existing probe; an operator default is reported in plain words with
no shorthand reply token); proposed AGENTS.md wording, not applied; the WS-P Phase 15 entries any relaxation
would add.
- [ ] Fresh-context verifier (C16): checks every row classed `destructive`, `visible-outward` or `cross-boundary`
and a sample of `reversible-local` rows; it writes `agree` or `disagree` in the last column and `not-sampled`
for rows it did not check; the summary line `sampled: <n>; disagree: <m>` counts sampled rows only. A disagreed
row goes to the user with the table [FALLBACK].
- [ ] User gate: the user approves by class, naming exceptions by row number; the main session records
`Approved classes:` and `Exceptions:` lines; each approved class or row becomes a new WS-O slice through the
decomposition, never an edit in this phase.
| File | Action | What changes |
|---|---|---|
| `<S>/ws-o/confirm-gates.sh`, `<S>/ws-o/confirm-gates-sha.txt`, `<S>/ws-o/confirm-gates-count.txt`, `<S>/ws-o/confirm-gates.md` | Create (local, untracked) | inventory, pinned SHA, count, table |
**Sanity Check** (with `SHA=$(cat <S>/ws-o/confirm-gates-sha.txt)`):
`git -C <worktree> cat-file -e "$SHA^{commit}"` exits 0 (the pinned commit exists);
`[ "$(cat <S>/ws-o/confirm-gates-count.txt)" -eq "$(bash <S>/ws-o/confirm-gates.sh "$SHA" | wc -l)" ]` exits 0 (count taken first against the pinned SHA, unchanged);
`N=$(bash <S>/ws-o/confirm-gates.sh "$SHA" | wc -l); R=$(grep -cE '^\| [0-9]+ \|' <S>/ws-o/confirm-gates.md); X=0; grep -q '^Hook gates excluded: ' <S>/ws-o/confirm-gates.md && X=$(bash <S>/ws-o/confirm-gates.sh "$SHA" | grep -cE '^(hook|settings)[[:space:]]'); [ "$N" -eq $((R + X)) ]` exits 0 (every hit at the pinned SHA has a row, or its source is excluded with a reason);
`grep -E '^\| [0-9]+ \|' <S>/ws-o/confirm-gates.md | grep -cvE '\| (reversible-local|destructive|visible-outward|cross-boundary) \| (keep-confirm|may-proceed|probe-first) \| (agree|disagree|not-sampled) \|$'` prints `0` (anchored on the last three cells);
`grep -cE '\| (destructive|visible-outward|cross-boundary) \| [a-z-]+ \| not-sampled \|$' <S>/ws-o/confirm-gates.md` prints `0` (every non-reversible row checked);
`[ "$(grep -cE '\| (agree|disagree) \|$' <S>/ws-o/confirm-gates.md)" -eq "$(sed -nE 's/^sampled: ([0-9]+);.*/\1/p' <S>/ws-o/confirm-gates.md)" ]` exits 0 (counts over sampled rows only);
`grep -cE '^(Approved classes|Exceptions): ' <S>/ws-o/confirm-gates.md` prints `2` after the user gate;
`git -C <worktree> status --porcelain -- plugins AGENTS.md docs scripts .claude` prints nothing (no tracked change).
Acceptance
- The gate count and its per-source split are shown to the user before any classification, taken against a pinned SHA.
- Every script hit at that SHA has a table row, or its source is excluded with a
Hook gates excluded: <reason>line. - Every
destructive,visible-outwardandcross-boundaryrow carries a verifieragreeordisagree. -
Approved classes:andExceptions:lines are recorded after the user gate, and each approved class or row is filed as its own slice. - No tracked file changes as part of the audit.
Refs: #6085
- Lingua principale
- Shell
- Stelle
- 22
- Fork
- 2
- Merge medio
- 8h 27m
- PR unite (30g)
- 957
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di melodic-software/claude-code-plugins
-
priority: medium
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
melodic-software/claude-code-plugins#7351 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
agent-ready priority: high work-class: scoped
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
melodic-software/claude-code-plugins#7312 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
priority: medium
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
melodic-software/claude-code-plugins#7288 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
knowledge: docpage-digest dual verification defines no verdict vocabulary or pass/fail thresholdApertaneeds-human
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
melodic-software/claude-code-plugins#7286 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
priority: low
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
melodic-software/claude-code-plugins#7282 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di melodic-software/claude-code-plugins
Issue simili
-
netbox status: backlog topic: testing type: housekeeping
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
netbox-community/netbox#23395 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
ajeetdsouza/zoxide#1323 ·
I maintainer di solito rispondono entro 1 giorno
-
e2e-failure ready-to-code
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
redhat-developer/rhdh-plugin-export-overlays#4391 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
pbakaus/impeccable#1028 ·
I maintainer di solito rispondono entro 1 giorno