bchanot/claude
1
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(memory): BDR-113 + LRN-197..199 + journal — feat manual-push-mode run C

Browse Source
This commit is contained in:
bchanot
2026-10-07 14:48:07 +02:00
parent 3881f462c6
commit 0b08ceda97
8 changed files with 220 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/tasks/plans/2026-10-07-manual-push-skills-c1-1304.md
+79
View File
@@ -0,0 +1,79 @@
# PLAN — manual-push-skills-c1 — REVISED r2 (3 lenses + correctness confirmation)
Contract: .claude/tasks/contracts/2026-10-07-manual-push-skills-c1-1304.md
## Context
`/close` STEP 5C runs `gitflow.sh finish chore <name>` then `git push origin develop`. Since BDR-095 (9da5d8d, 2026-09-22) `finish` already pushes develop itself (`_gitflow_merge_into` → `_gitflow_push_branch`, mode-aware since run A), so the explicit push has been redundant for two weeks; in manual mode push-guard (run B) would deny it, and a shell gate `[ "$mode" = auto ] && git push …` is denied as a whole by the text-only guard while `$mode` does not survive between Bash calls. Fix = remove the push text entirely and REPORT from facts read after finish. Skills can no longer read `gitflow.autopush` via `git config` (BDR-112) → the lib verb `push-mode` is the sanctioned reader. Invalid value: lib/hooks still push (fail-open until run D), so the wording must not claim "not pushed" — the ahead count tells the truth.
## Checklist
- [ ] lib/gitflow.sh — `gitflow_push_mode()` in the predicates section (after `gitflow_release_open`):
```
# gitflow_push_mode → stdout auto | manual | invalid, rc 0 always. The ONE
# reader skills may call: `git config … gitflow.*` is statically denied to
# Claude (BDR-112). manual = key reads false; auto = true or unset; invalid =
# anything else (unparseable value, git failure) — the raw value goes to
# stderr so the caller can name it. Reads only. Ignores GITFLOW_NO_PUSH (a
# test-repo switch, not a mode): a caller that pushes must not rely on this
# verb alone — the lib's own push sites use _gitflow_push_off.
gitflow_push_mode() {
local val rc raw
val=$(git config --bool gitflow.autopush 2>/dev/null); rc=$?
case "$rc:$val" in
0:false) echo manual ;;
0:true|1:*) echo auto ;;
*) raw=$(git config gitflow.autopush 2>/dev/null)
if [ -n "$raw" ]; then
echo "gitflow.sh push-mode: gitflow.autopush='$raw' is not a boolean (git rc $rc)" >&2
else
echo "gitflow.sh push-mode: could not read gitflow.autopush (git rc $rc)" >&2
fi
echo invalid ;;
esac
return 0
}
```
CLI dispatcher: `push-mode) gitflow_push_mode ;;` after `merged`; add `push-mode` to the usage string. `_gitflow_push_off` UNCHANGED (run D).
- [ ] lib/gitflow-test.sh — NEW block after T11, own repo (hooks on from init, irrelevant: config reads/writes only): `echo "T11b — push-mode verb (the sanctioned reader for skills, BDR-112)"`; `newrepo pm; echo a>a; bash "$HERE/gitflow.sh" init >/dev/null 2>&1`;
`chk "cli push-mode default auto" '[ "$(bash "$HERE/gitflow.sh" push-mode)" = auto ]'`;
`git config gitflow.autopush true` → `chk "cli push-mode true auto" …= auto`;
`git config gitflow.autopush false` → `chk "cli push-mode manual" …= manual`;
`git config gitflow.autopush flase` → `pm_out=$(bash "$HERE/gitflow.sh" push-mode 2>"$WORK/pm.err"); pm_rc=$?` (same line) → `chk "cli push-mode invalid, rc 0, value on stderr" "[ $pm_rc -eq 0 ] && [ \"$pm_out\" = invalid ] && grep -q flase \"$WORK/pm.err\""`;
corrupt config: `printf '[gitflow\n' >> .git/config` → `pm2_out=$(bash "$HERE/gitflow.sh" push-mode 2>/dev/null); pm2_rc=$?` → `chk "cli push-mode corrupt config → invalid, rc 0" "[ $pm2_rc -eq 0 ] && [ \"$pm2_out\" = invalid ]"`;
`chk "cli usage lists push-mode" 'grep -q push-mode <<<"$(bash "$HERE/gitflow.sh" nope 2>&1)"'`.
Variables read in double-quoted assertions (no SC2034 suppression). Config writes live in the test FILE only.
- [ ] skills/capitalize/SKILL.md — STEP 5C (heading UNCHANGED; repo-wide grep shows no citer; the citers census does not cover skill headings). Body rewrite below the three fire-conditions:
"Skip this step entirely (go to STEP 6, which prints the hold note) on `--no-push`, on a WORKING branch, or when STEP 5B returned rc 3.
Otherwise, from the `chore/<name>` branch, THREE separate Bash calls, never combined. INVARIANT: no `git push` inside any Bash call of this skill (push-guard reads command text; the lib pushes develop itself in auto-push mode). The hints that tell the USER what to type (`! git push …`) are prose, kept on single lines.
1. `bash "$HOME/.claude/lib/gitflow.sh" finish chore <name>` — merge → develop, delete branch, push develop in auto-push mode. rc≠0 → skip calls 2-3, go to STEP 6 with the `finish failed` line: rc 4 = conflict, develop mid-merge, `chore/<name>` kept, NOT merged; rc 1 = checkout failed, NOT merged; rc 5/2/6 come from the delete AFTER the merge: check `git merge-base --is-ancestor chore/<name> develop` and report `merged, branch not deleted (rc <n>)` when it holds, `NOT merged` otherwise. Never say "merged" without that check.
2. `bash "$HOME/.claude/lib/gitflow.sh" push-mode` → `auto | manual | invalid` (stderr names an invalid value).
3. `git rev-list --count origin/develop..develop 2>/dev/null || echo unknown` → `ahead` (0 = on origin; `unknown` = no origin/develop ref, e.g. no origin remote).
Outcomes, evaluated IN THIS ORDER (all require finish rc 0):
- push mode `invalid` → `merged to develop — gitflow.autopush=<value from stderr> is not a boolean: the lib and hooks still push on an invalid value until run D (origin/develop is <ahead> commit(s) behind, or unknown); fix the value by hand`.
- `ahead` = 0 → `develop <short> pushed` (auto-push mode did it).
- `ahead` = unknown → `merged to develop — not on origin (no origin/develop ref; no remote or never fetched)`; push mode manual → add `You: ! git push origin develop once a remote exists`.
- `ahead` > 0, push mode `manual` → `merged to develop — manual push mode: not pushed. You: ! git push origin develop`.
- `ahead` > 0, push mode `auto` → `merged to develop — push FAILED (see finish stderr); push manually`. Do NOT retry or reset the merge."
Keep the three existing bullets' intent inside the list above (the first qualified as auto-push mode). Recap line ~358 `persisted :` values → `develop <short> pushed | merged, manual push mode: not pushed | merged, not on origin (no origin/develop) | merged, push FAILED | merged, gitflow.autopush invalid (<ahead> behind) | finish rc <n>, not merged | merged, branch not deleted (rc <n>) | on chore/<name>, not merged (--no-push)`.
STEP 6 (lines ~366-368): `<mode>` stays the session label (`Context flushed` / `Session closed`); the conditions below say "push mode". On the `--no-push` path (and on any 5B-committed path where 5C did not run) read TWO facts, each its own call: `bash "$HOME/.claude/lib/gitflow.sh" push-mode` and `git rev-list --count origin/chore/<name>..chore/<name> 2>/dev/null || echo unknown` (`branch_ahead`). Lines (single-line bullets, as the existing ones):
- auto-persisted (ahead 0) — unchanged.
- `--no-push`, `branch_ahead` = 0 → `✅ <mode> + committed on chore/<name> — pushed to origin by the hooks (auto-push mode), NOT merged (--no-push). Merge when ready.`
- `--no-push`, `branch_ahead` > 0 or unknown → `✅ <mode> + committed on chore/<name> — this disk only, not pushed (<push mode manual | no origin/chore ref>), NOT merged. You: ! git push -u origin chore/<name>; merge when ready.` With push mode `invalid`, append ` gitflow.autopush=<value> is not a boolean: fix it by hand`.
- manual (merged, `ahead` > 0) → `✅ <mode> + merged to develop — manual push mode: not pushed. You: ! git push origin develop`.
- not on origin (merged, `ahead` unknown) → `✅ <mode> + merged to develop — not on origin (no origin/develop ref).`
- invalid (merged) → `⚠️ <mode> + merged to develop — gitflow.autopush=<value> is not a boolean; lib/hooks still push on it until run D (origin/develop <ahead> behind). Fix the value by hand.`
- push failed — unchanged.
- finish failed → `⚠️ <mode> + finish rc <n>: <stderr> — chore/<name> kept, NOT merged (or: merged, branch not deleted); resolve by hand.`
argument-hint (line 13): `pushed to origin by the hooks` → `pushed to origin by the hooks in auto-push mode`. Rules line ~403: append ` — the lib pushes develop in auto-push mode only; manual mode merges and leaves the push to the user`.
- [ ] skills/close/SKILL.md — argument-hint (line 12): same `in auto-push mode` wording; line 31 `STEP 5C auto-persist: finish + push, BDR-068` → `STEP 5C auto-persist: finish (push rides it in auto-push mode), BDR-068`.
- [ ] lib/gitflow-aiguillage.md — lines 40-42: `(finish → develop + push)` → `(finish → develop; the lib pushes develop in auto-push mode only)`. One line.
## Edge cases
- INVARIANT: no `git push` inside any Bash CALL of capitalize/close (the user-facing `! git push …` hints are prose on single lines) → push-guard never fires on /close. The verifier judges it by reading; a negative grep would itself carry `git push` and be denied in manual mode (LRN-194 b).
- `origin/develop` ref absent (no origin, never fetched) → `unknown` → its own outcome ("not on origin"), never "push FAILED" (in auto mode without origin the lib is silently a no-op, lib/gitflow.sh:90).
- Invalid value: truth comes from `ahead`, not from the mode; wording never says "not pushed" without `ahead` > 0.
- The verb ignores GITFLOW_NO_PUSH by design (documented in its comment); 5C never runs in a test repo; C2 callers that push must gate on the verb AND respect push-guard (they will not contain `git push` text in manual mode anyway).
- Heading kept → no citer risk; BDR-100 census does not apply to skill headings (manual repo-wide grep done: none).
## Disposition
- honors BDR-068 (auto-persist: merge always, push rides finish in auto mode) and BDR-111/BDR-112 (verb = sanctioned reader; zero `git config` in skills; zero `git push` inside Bash calls).
- honors BDR-095 (truth from the remote state, never from intent: `ahead` count) and LRN-104 (every new output string lives in the skill text; the verb's outputs locked in T11b incl. stderr and rc).
- honors LRN-191 (`grep -q … <<<"$(…)"`), LRN-194 (fixtures in files), LRN-193 (fresh confirmation pass after this revision).
.claude/tasks/plans/2026-10-07-manual-push-skills-c2-1325.md
+33
View File
@@ -0,0 +1,33 @@
# PLAN — manual-push-skills-c2 — REVISED r2 (3 lenses + correctness confirmation)
Contract: .claude/tasks/contracts/2026-10-07-manual-push-skills-c2-1325.md
## Context
Same pattern as C1: since BDR-095 the hooks push every commit in auto-push mode, so a skill's own `git push` (and the question that gates it) gates nothing in auto mode, and in manual/invalid mode push-guard denies it. Truth about "on origin" comes from a FACT read after the fact — `git rev-list --count origin/<br>..<br>` (0 = on origin; >0 = not; `unknown` = no remote-tracking ref) — never from the mode word (the lib still pushes on an invalid value until run D). The verb `gitflow.sh push-mode` (C1) only WORDS the explanation (manual vs push FAILED) and is read in its own Bash call; no shell variable crosses calls. Where a user must push, the hint is a complete `! git …` command with `-u` and, for multi-repo flows, `-C <abs path>`.
## Checklist
- [ ] agents/client-handover-writer.md — define ONE reusable paragraph "PUSH STATE READ" (insert it once, right after the commit-change dispatch in STEP 5, and REFER to it elsewhere): "Three separate Bash calls, never combined, read-only: `git branch --show-current` → `<br>`; `git remote get-url origin >/dev/null 2>&1 && echo origin || echo no-origin`; `git rev-list --count origin/<br>..<br> 2>/dev/null || echo unknown` → `ahead`. If `ahead` ≠ 0 and origin exists: `bash "$HOME/.claude/lib/gitflow.sh" push-mode` → anything other than `auto` is treated like `manual` (stderr line kept verbatim when `invalid`). State: `ahead` = 0 → `on origin`; no commits were made this run or the gitflow fallback left changes uncommitted → `nothing to push (no commits this run)` / `uncommitted changes (no gitflow model): publish by hand`; `no-origin` → `not on origin (no origin remote: add one first)`; `ahead` > 0 or `unknown` → `pending — you: ! git push -u origin <br>` + reason: push mode `manual` → `(manual push mode)`, `auto` → `(not on origin: no remote-tracking ref or the hook push did not land)`, `invalid` → `(<verb stderr line verbatim>)`. The pipeline never runs `git push` itself." Then:
STEP 5: replace ONLY lines ~570-578 (from "Then, **before pushing, STOP and ask for an explicit GO**" through the "Only on **A** … then continue." paragraph) with the PUSH STATE READ paragraph followed by: "`pending` → tell the user NOW: `Commits are local only. Push first: ! git push -u origin <br>`." KEEP the red-flag box (~580-582) and reword it (multi-line old_string, exact current text: `> **Red flag — STOP:** never \`git push\` without option-A GO; never\n> \`gitflow finish\`/\`merge\`. This pipeline commits and (on GO) pushes a working\n> branch — it never integrates into a protected branch.`) → `> **Red flag — STOP:** never \`git push\` (the hooks push in auto-push mode;\n> otherwise the user does); never \`gitflow finish\`/\`merge\`. This pipeline\n> commits a working branch — it never integrates into a protected branch.` Then DELETE lines ~584-598 (the `CURRENT_BRANCH=…/git push origin` bash block and the "If push fails …" AskUserQuestion block).
STEP 6: FIRST line of STEP 6 (before "Skip if PROJECT_TYPE != web"): "Re-run PUSH STATE READ (every path reaches STEP 6, some without STEP 5's read)." Deploy brief (lines ~626-631, multi-line anchors: `"Push has been\n done. The platform deploys automatically — usually 1-3 min. Watch the\n dashboard.`): when the state is `pending` the brief OPENS with `First push: ! git push -u origin <br>`; the Vercel/Netlify/Cloudflare line reads "The platform deploys automatically after your push (a working branch gives a preview at most; production builds from the production branch) — usually 1-3 min…"; the CI line "Workflow `<file>` runs on your push…"; when `on origin`, keep "Push has been done. …". After option A "Deployed" (~648): "Re-run PUSH STATE READ; still `pending` → ask again (the live site cannot hold these commits)."
Reports: PIPELINE STOPPED template (~795-810) gains a line at column 0 `Push: <state>` after the Score table; the 9.7 user report gains a bullet `- Push: <state>`; both re-run PUSH STATE READ right before printing (never a STEP 5 snapshot). Line ~65 `3. Commit + push if files changed.` → `3. Commit if files changed (the hooks push in auto-push mode; the push state is read, never assumed).`; lines ~686-687 `(mini-commit\n+ push)` → `(mini-commit; push state read, never assumed)`.
- [ ] skills/client-handover/SKILL.md step 4 — `run /commit-change (atomic logical commits) then \`git push\`.` → `run /commit-change (atomic logical commits); the gitflow hooks push in auto-push mode, otherwise (manual push mode, or a hook push that failed) the agent tells the user to push with \`! git push -u origin <branch>\` BEFORE the deploy pause.`
- [ ] skills/release-candidate/SKILL.md STEP 6 — replace the paragraph from "`main` and `develop` are already on origin" through the `hold` line (lines ~96-108) with:
"Read the state, separate Bash calls: `git rev-list --count origin/main..main 2>/dev/null || echo unknown`, `git rev-list --count origin/develop..develop 2>/dev/null || echo unknown`, `bash "$HOME/.claude/lib/gitflow.sh" push-mode`.
- anything other than `auto` from the verb (manual, invalid, empty, usage error) OR either count ≠ 0 or `unknown` → Claude pushes nothing (push-guard would refuse it in manual mode; a failed lib push is the user's call, BDR-095). Print ONE command for the user and STOP, no question: `! git push --atomic origin main develop v<X.Y.Z>` (invalid: quote the verb's stderr line verbatim; auto with a count ≠ 0 or unknown: say `main/develop not on origin (no remote-tracking ref or the lib's push did not land)`; no origin remote (`git remote get-url origin` fails): say `add an origin remote first`).
- push mode `auto` and both counts 0 → main and develop are on origin; only the tag is left. STOP. On explicit go only ([[LRN-069]]) — run the tag push HERE, never delegated: `AskUserQuestion: Push tag v<X.Y.Z> to origin? — go / hold`. Go → ```bash\ngit push origin v<X.Y.Z>\n```. `hold` → stop; the release is on origin (main + develop), the tag stays local until the next push of main (`--follow-tags` on every lib and hook push)."
Overview lines ~27-28 (multi-line anchor `and the two human gates (when to release, and\nthe tag push).`) → append " (auto-push mode; in manual push mode the user pushes main, develop and the tag in one command)". Common-mistakes bullet list: add `- Pushing anything in manual push mode → print the one user command, push nothing.` Frontmatter description ("tag it, and push") and the STEP 6 heading stay (frozen, residuals).
- [ ] agents/release-executor.md — lines ~80-82 (multi-line anchor: `Finish has already pushed \`main\` and\n \`develop\` through the lib's hooks (BDR-095); the tag stays local until\n the dispatcher's tag-push gate.`) → "In auto-push mode finish has already pushed `main` and `develop` through the lib (BDR-095); in manual push mode they stay local. The tag stays local"; lines ~85-86 (anchor `\`main\`/\`develop\` ride the lib's hook\npushes during finish;`) → "`main`/`develop` ride the lib's pushes during finish in auto-push mode".
- [ ] skills/tour/SKILL.md — Rules (lines ~273-275, multi-line anchor: ` The chore branch's own commits are pushed by the gitflow hooks\n (BDR-095); a \`push FAILED\` hook warning is a report residual, fixed\n with a plain \`git push -u origin chore/tour-<date>\`.`) → " The gitflow hooks push the chore branch in auto-push mode only; when it is not on origin (manual push mode, or a `push FAILED` warning) the USER pushes it — `! git -C <abs project> push -u origin <branch>` — the tour never pushes or retries." STEP 3 per-project closing list (~228-239): add item 5 AFTER the `docs(tour): report` commit (3.3, the last commit): "5. Push state, one read-only call: `git -C <abs project> rev-list --count <branch> --not --remotes 2>/dev/null || echo unknown` (`<branch>` = the name `gitflow start` returned, suffixed `-2`/`-3` on a same-day re-run — never the bare `chore/tour-<date>`). 0 → `on origin`; else `local only → ! git -C <abs project> push -u origin <branch>` (no origin remote → `local only (no origin remote)`)." Summary row format (~258-259): after `<branch>, <n> commits` append ` | on origin` or ` | local only → ! git -C <abs project> push -u origin <branch>`. Runner prompt (~92-100) unchanged: the row format carries the field and the runner already returns `BRANCH: <name>`. No verb read in the tour.
## Edge cases
- `unknown` (never fetched) → "not on origin (no remote-tracking ref)"; no origin remote → "add an origin remote first" (the `! git push … origin …` hint would fail); never "push FAILED". `ahead` = 0 → "on origin" with no claim about WHO pushed (in manual mode it was the user).
- Every `Push:`/deploy-brief statement re-reads the fact right before it prints (a STEP 5 snapshot is stale once the user pushed); STEP 6 reads it first because three paths reach STEP 6 without STEP 5's read (no pending changes; gitflow fallback; `--skip-audits`).
- AC substrings must each sit on ONE physical line (line-based greps); `Push:` at column 0 inside the PIPELINE STOPPED fence; `auto-push mode` on two distinct lines in release-executor.md.
- Invalid value: never "not pushed" from the mode; the counts decide; the verb's stderr is quoted verbatim (it may say "could not read" without a value).
- Release command is `--atomic`: a non-fast-forward on main rejects the whole set, so the tag never lands without its merge.
- client-handover-writer runs INLINE in the main loop (SKILL.md:29-33): the prose reaches the pusher. commit-change and handover-doc-writer never push.
- Tour runners are sub-agents using `git -C <abs project>`: the fact call uses `-C` too; the user hint carries the path (same branch name across projects).
- Removed gates (client-handover GO question, release "on origin" claim) were gating nothing in auto mode: the hooks had pushed already (same redundancy C1 removed in /close). LRN-069's push gate now means: Claude never pushes in these flows except the release tag on explicit go in auto mode.
- Residual (frozen by AC6): release-candidate frontmatter "tag it, and push", STEP 6 heading "Tag push GATE (ASK)" — true in auto mode; listed in the CHANGELOG at doc-sync.
## Disposition
- honors BDR-095 (truth from the remote state; a failed push is the user's decision), BDR-111/BDR-112 (verb for wording only, read in its own call; zero `git config` in skills; zero `git push` inside a Bash call reachable in manual mode), BDR-042 (tag + its gate stay in the dispatcher), LRN-069 (explicit go kept for the one push Claude still makes: the tag, auto mode), LRN-193 (fresh confirmation pass after this revision), LRN-104 (every user-facing string is in the skill text; no runtime test exists for prose — AC6 is the reading gate).