bchanot
5cf049d235
Run C1 of manual-push mode (BDR-111/BDR-112).
- lib/gitflow.sh: `gitflow.sh push-mode` prints auto | manual | invalid
(rc 0; an invalid value is named on stderr). It is the one reader a
skill may call: the bare `git config … gitflow.*` read is denied to
Claude since run B. Ignores GITFLOW_NO_PUSH by design (documented).
- skills/capitalize/SKILL.md STEP 5C: the explicit `git push origin
develop` is gone — `finish` has pushed develop itself since BDR-095,
mode-aware since run A. 5C is now three separate read-only calls
(finish; push-mode; `git rev-list --count origin/develop..develop`)
and prose outcomes keyed on the real ahead count: pushed / manual push
mode, you push / not on origin / push FAILED / invalid value named,
plus a finish-failure outcome (merge vs delete rc distinguished).
STEP 6 closing lines and the recap carry every outcome; the
`--no-push` line reads the branch's own ahead count ("this disk only"
only when true). Invariant: no `git push` inside any Bash call; the
user hints are prose.
- skills/close/SKILL.md, lib/gitflow-aiguillage.md: "push" claims
qualified "in auto-push mode".
- lib/gitflow-test.sh T11b: six cases for the verb (default, true,
false, non-boolean with stderr + rc 0, corrupt config, usage).
Polish items from the gates are listed in TODO.md (C1 polish).
2.7 KiB
Gitflow aiguillage — branch on a protected base before writing
Flows that WRITE — code, OR standalone memory/doc work — must NEVER commit on a
protected base (main/develop). Run this check before editing any file.
bash "$HOME/.claude/lib/gitflow.sh" protected-base && echo PROTECTED || echo WORKING
- WORKING (
feature/*,bugfix/*,hotfix/*,chore/*, or any non-protected branch) → proceed; you commit in place on this branch. Nothing changes. - PROTECTED (
main/develop) → branch first, do NOT commit here:bash "$HOME/.claude/lib/gitflow.sh" start <YOUR-TYPE> <short-kebab-name><short-kebab-name>derived from the request. Then do the work on the new branch.
The caller passes its TYPE:
| Caller | TYPE | Base |
|---|---|---|
/feat |
feature |
develop |
/bugfix |
bugfix |
develop |
/hotfix |
hotfix on main · bugfix on develop |
main · develop |
/seo aggressive · /web-validate --fix |
feature |
develop |
/capitalize · /close · /prune-memory · /reconcile |
chore |
develop |
/doc · /refactor |
chore |
develop |
/commit-change |
asks the user (feature / bugfix / chore) before start — a branch name is a public name |
develop |
The chore rows = standalone memory/doc/hygiene work: the registry / TODO /
doc reconciliation & curation skills (+ /refactor), run OUTSIDE an assistance flow. Inside /feat
/bugfix /hotfix /ship-feature a working branch already exists (this check
returns WORKING) and the memory commit rides it. The aiguillage only fires when
such a skill is invoked directly on main/develop — i.e. memory IS the work,
with no code branch to follow. That is the leak it closes: the .claude/** hook
exemption still lets a manual memory commit through on a protected base, but a
skill-driven one now branches to chore/* first.
Integration is human-gated by default — these flows commit, they do not merge.
EXCEPTION: /capitalize + /close auto-persist their memory-only commit (finish → develop; the lib pushes develop in auto-push mode only)
when THEY branched a chore/* off develop this run (BDR-068 — a
scoped LRN-069 exception; see the capitalize skill's STEP 5C). /prune-memory
/reconcilestay fully human-gated: never rungitflow finishfrom them.
Note: a hotfix/* branch forks off main (prod) and fans out to main + develop
at finish — that is the gitflow definition of a hotfix. Invoked from develop,
/hotfix therefore starts a bugfix/* (off develop): a hotfix/* there would
miss develop's code and later merge to prod. The small-fix routing is unchanged;
only the branch type follows the base.