Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

investigate: audit confirm gates against the reversible and destructive split (slice 93)

Aperta
#7,005 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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

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

needs-human needs-triage

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-outward and cross-boundary row carries a verifier agree or disagree.
  • Approved classes: and Exceptions: 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

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di melodic-software/claude-code-plugins

Tutte le issue di melodic-software/claude-code-plugins

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.