moilanik 99d13e6e4a feat: complete apply.sh v1 — summary, guard, dev root install, updated docs

- 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

2026-03-03 11:19:35 +02:00

1.9 KiB

Raw Blame History

Git Instructions

🚨 GIT POLICY - ABSOLUTELY CRITICAL

NEVER EVER make git commands without explicit user approval!

Forbidden Commands - DO NOT RUN:

❌ git add - User runs this themselves (including git add ., git add -A, git add )
❌ git commit - User runs this themselves
❌ git push - User runs this themselves
❌ git push --force - User runs this themselves
❌ git reset - User runs this themselves
❌ 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:

Run git diff --staged or git diff — read what actually changed
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.
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

1.9 KiB Raw Blame History