99d13e6e4a
- apply.sh: direct-run guard (only curl | bash allowed) - apply.sh: DEV_ROOT passed as explicit arg from bootstrap - apply.sh: .ai/ copied to dev root as real folder; projects symlink there - apply.sh: counters + detailed summary (version prev→new, templated, refreshed, no-docs) - apply.sh: find errors silenced, no crash on empty dev root - .ai-superpower: added warning comment about deletion side effects - .gitignore: .ai-instructions.conf → .ai-superpower.version - scripts/: removed (hello.sh, scan-projects-with-git.sh, verify-docs-folder.sh, add-ai-context-to-docs-folder.sh) - templates: monorepo sections split into AI instructions + developer instructions - README.md: rewritten to match current architecture and behaviour - docs/apply-requirements.md: FR-2.4, FR-3, FR-5, FR-6, FR-7, FR-8 updated - docs/apply-usecases.md: full detailed Mermaid flowchart replacing placeholder
59 lines
1.9 KiB
Markdown
59 lines
1.9 KiB
Markdown
# Git Instructions
|
|
|
|
## 🚨 GIT POLICY - ABSOLUTELY CRITICAL
|
|
|
|
**NEVER EVER make git commands without explicit user approval!**
|
|
|
|
### Forbidden Commands - DO NOT RUN:
|
|
1. ❌ **git add** - User runs this themselves (including git add ., git add -A, git add <file>)
|
|
2. ❌ **git commit** - User runs this themselves
|
|
3. ❌ **git push** - User runs this themselves
|
|
4. ❌ **git push --force** - User runs this themselves
|
|
5. ❌ **git reset** - User runs this themselves
|
|
6. ❌ **ANY command that modifies git repository or server state**
|
|
|
|
### What You CAN Do:
|
|
- ✅ `git status` - Show current state
|
|
- ✅ `git diff` - Show changes
|
|
- ✅ `git log` - Show history
|
|
- ✅ Show the command user should run
|
|
- ✅ Explain what the command will do
|
|
|
|
### Exception:
|
|
Only if user explicitly says:
|
|
- "commit this now"
|
|
- "push this now"
|
|
- "go ahead and commit"
|
|
|
|
Otherwise: **SHOW the command, WAIT for user to run it**
|
|
|
|
---
|
|
|
|
## Best Practices
|
|
|
|
- Always show `git diff` before suggesting commits
|
|
- Show `git status` to verify what will be committed
|
|
- Explain impact of each git operation
|
|
- User controls git commands, you analyze and advise
|
|
- Never assume user wants to commit
|
|
- Production platform infrastructure: Stability > Speed
|
|
|
|
---
|
|
|
|
## Commit Message Workflow
|
|
|
|
When the user asks for a commit message:
|
|
|
|
1. **Run `git diff --staged` or `git diff`** — read what actually changed
|
|
2. **Documentation check** — scan the changed files and ask: does any `docs/` or `README.md` need updating based on these changes? If yes, flag it clearly before writing the message. Do not block the commit — just surface it.
|
|
3. **Write the commit message only** — one short subject line, optionally a blank line and brief body if the change needs context. Output just the message text in a code block. Do NOT wrap it in a `git commit` command.
|
|
|
|
Format:
|
|
```
|
|
<type>: <what changed>
|
|
|
|
<optional: why, or what is not obvious from the diff>
|
|
```
|
|
|
|
Types: `feat`, `fix`, `docs`, `refactor`, `chore`
|