/ship: fix-or-skip questions omit each finding's severity, because the shared decision-brief template has no slot for it
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 72/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- tooling
Direzione di ricerca
Inizia dal modello condiviso per il briefing decisionale in ship/sections/preamble.md e confrontalo con i requisiti di gravità in ship/sections/review-army.md e ship/SKILL.md. Aggiorna il modello e il relativo autocontrollo in modo che le domande sui rilievi della revisione indichino la gravità e specifichino se bloccano la distribuzione; verifica se esiste un lint per l’output renderizzato di AskUserQuestion se vuoi implementare il lint facoltativo. Il lavoro è completo quando le domande su correggere o ignorare seguono la politica di revisione documentata e identificano i rilievi informativi come non bloccanti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
gstack v1.91.324.0 (53db038c), Claude Code (Claude Opus 5.5).
What happened
During /ship's pre-landing review (Step 9, pass 1), the agent asked four fix-or-skip questions, one finding or group per question.
Every one of the findings was INFORMATIONAL: none would fail a test, break production, or lose data or secrets.
None of the four questions said so.
Each followed the shared decision-brief format: D<N> title, ELI10, "Stakes if we pick wrong", Recommendation "A) Fix", Completeness (Fix 10/10 against Skip 5–6/10), pros and cons, Net.
To the reader, each one looked like a defect that had to be fixed before shipping.
The user had to stop the run and ask what each finding's severity was before answering.
The agent missed a rule the skill states.
But the skill's own structure makes that miss the likely one, so it is reported here rather than only as a model error.
Where the rule is, and where it gets lost
The rule is stated in three places:
ship/sections/review-army.md:45-46: "Every finding MUST include a severity, CRITICAL (blocks shipping) or INFORMATIONAL (lower severity, still actioned)".ship/sections/review-army.md:520: the rendered finding line,[SEVERITY] (confidence: N/10, specialist: name) path:line — summary.ship/sections/review-army.md:712-714: "present them in ONE AskUserQuestion (or one per item for 3 or fewer): each item's number, severity, problem and recommended fix with A) Fix B) Skip".
The question itself is written from the shared preamble's format (ship/sections/preamble.md, the D<N> template near line 57), and every AskUserQuestion has to use that format.
The template has no severity line, and its "Self-check before emitting" list checks the D<N> header, ELI10, Recommendation, Completeness, pros and cons and Net:, but not severity.
So the one checklist the agent runs right before asking passes a fix-or-skip question with no severity.
The template also pushes against the review policy.
ship/SKILL.md says "only a finding that would fail a test, break production, or lose data or secrets blocks a pass; the rest is a PR-body note".
But "Stakes if we pick wrong" and a Completeness score that rates Skip at 5–6/10 make a non-blocking finding read like a blocking one.
A user answering a stream of these questions without the severity has no way to tell a note from a blocker.
Suggested fix
- Give fix-or-skip questions a required first line, before ELI10:
Severity: CRITICAL|INFORMATIONAL (confidence: N/10) — blocks shipping: yes|no, and add it to the self-check list whenever the question is about a review finding. - When every finding in a question is INFORMATIONAL, say so in the title or ELI10 (for example "non-blocking; Skip makes it a PR-body note").
Score Completeness on what the fix covers, not as if Skip ships a defect. - Optionally, have a lint over a rendered AskUserQuestion refuse a review-finding question that has no severity token, the same way the
(recommended)marker is already parsed.
- Lingua principale
- TypeScript
- Stelle
- 138k
- Fork
- 20.5k
- Merge medio
- 8h 37m
- PR unite (30g)
- 320
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un 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 garrytan/gstack
-
ubicloud: usage is an awk syntax error on macOS, which also disables the vCPU quota preflightAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di garrytan/gstack
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
Northeastern-Electric-Racing/FinishLine#4660 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
excaliburjs/Excalibur#3895 ·
I maintainer di solito rispondono entro 3 giorni
-
infer_audio_type only recognises one MPEG Layer III frame header, so most MP3 files are rejectedForse già presa @Steve-20-ai l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Earn report crashes with "RangeError: Invalid time value" when a report row has an unparsable timestampForse già presa @Gurkaran18 l’ha presa oggi. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
joinmarket-webui/jam#1588 ·
I maintainer di solito rispondono entro 3 giorni
-
BeOS .json missingAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
mihaip/infinite-mac#475 ·