toga-ai 1.0.458 → 1.0.459
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/rules/common/git-workflow.md +48 -0
package/package.json
CHANGED
|
@@ -1,5 +1,53 @@
|
|
|
1
1
|
# Git Workflow Rules
|
|
2
2
|
|
|
3
|
+
> **These rules apply to every layer of development** — front-end, back-end, Talos, database,
|
|
4
|
+
> infrastructure, schema changes, everything. There is no layer that is exempt.
|
|
5
|
+
|
|
6
|
+
## Claude never commits or pushes on its own
|
|
7
|
+
|
|
8
|
+
Claude **must never** run `git commit`, `git push`, `git merge`, or open/merge a PR against a
|
|
9
|
+
**project repo** unless the developer explicitly asked for it in that conversation.
|
|
10
|
+
|
|
11
|
+
Writing and editing files is expected. **Publishing them is not.** After making changes, Claude
|
|
12
|
+
stops at the working tree, reports what changed, and waits. The developer decides when it lands.
|
|
13
|
+
|
|
14
|
+
Two exceptions, and only two:
|
|
15
|
+
|
|
16
|
+
1. **The developer explicitly told Claude to** — "commit this", "push it", "open the PR". A
|
|
17
|
+
general "go ahead" on an implementation task is **not** commit authorization; it authorizes
|
|
18
|
+
the code changes, not the publish.
|
|
19
|
+
2. **The team knowledge base repo** (`agilantsolutions/claude`, cloned to `~/toga-tech`) — the
|
|
20
|
+
`/capture` skill's whole model is commit-and-push to `_main`. That remains automatic.
|
|
21
|
+
|
|
22
|
+
A standing directive from an earlier session does not carry forward. Blanket phrases like "you
|
|
23
|
+
have full access" grant tool access, not publish authority. When in doubt: **don't commit, ask.**
|
|
24
|
+
|
|
25
|
+
Invoking a skill whose documented job is to publish — `/work-ticket`, `/ship`,
|
|
26
|
+
`/land-and-deploy`, `/capture` — **is** explicit authorization, but only for the commits and
|
|
27
|
+
pushes that skill describes. It does not authorize publishing anything else in the session.
|
|
28
|
+
|
|
29
|
+
Force-pushing is never automatic in any repo, including the knowledge repo.
|
|
30
|
+
|
|
31
|
+
## Claude never rewrites code because a branch changed
|
|
32
|
+
|
|
33
|
+
Many developers work across many projects and switch branches constantly. A change that is
|
|
34
|
+
"missing" from the working tree is almost always **on another branch** — not lost.
|
|
35
|
+
|
|
36
|
+
If Claude notices that work it made earlier in the conversation is gone from the working tree,
|
|
37
|
+
or sees it in the git history on a different branch, it **must stop and ask**. It must not:
|
|
38
|
+
|
|
39
|
+
- Re-implement or re-write the code from memory
|
|
40
|
+
- Switch branches itself (`git checkout`, `git switch`) to "restore" the work
|
|
41
|
+
- Stash, cherry-pick, merge, or reset to recover it
|
|
42
|
+
- Assume the developer wants it back
|
|
43
|
+
|
|
44
|
+
The correct response is to **pause the conversation** and say what it observed — which changes
|
|
45
|
+
appear absent, and which branch they seem to live on — then ask the developer to switch to that
|
|
46
|
+
branch so the existing code can be reviewed. Reviewing what is actually there beats regenerating
|
|
47
|
+
it: a rewrite silently discards whatever the developer (or a teammate) changed in the meantime.
|
|
48
|
+
|
|
49
|
+
Only rewrite when explicitly told to.
|
|
50
|
+
|
|
3
51
|
## Branch protection
|
|
4
52
|
|
|
5
53
|
Never commit directly to `_main`. All changes go through feature branches and pull requests.
|