Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#7,005 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
15/100
Tipo de issue
Documentación
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
markdown, shell

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Shell
Estrellas
22
Forks
2
Merge medio
8 h 24 min
PR fusionados (30 d)
947

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de melodic-software/claude-code-plugins

Todos los issues de melodic-software/claude-code-plugins

Issues similares

Más issues de Shell/Bash

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.