feat(project-discipline): v0.2.0 — Rule 4 push freely, local gate override

Operator correction (2026-08-12): the ask-before-push ban accidentally became
global; the real gate belongs only to books (push to master = Gitea Actions
auto-deploy). New Rule 4: ordinary fast-forward push needs no confirmation by
default; a project with a local push-gate skill (convention push-gate, e.g.
books) overrides this in that project; force/delete/non-ff/other-remote always
ask. books/.claude/skills/push-gate + books/.agents/skills/push-gate carry the
old gate semantics (per-session grant / manual ask / session reset / summary
commit for Gitea Actions table).
This commit is contained in:
2026-08-12 16:15:48 +03:00
parent ff68762516
commit 42ed5ea8a4

View File

@@ -1,15 +1,18 @@
---
name: project-discipline
author: ours
version: 0.1.2
version: 0.2.0
description: >
Codifies five cross-project discipline rules: (1) project CLAUDE.md /
.wiki/CLAUDE.md / .tasks/ override defaults from any other skill (specs
go to .wiki/concepts/, tasks to .tasks/); (2) all work on master/main, no feature
branches without explicit user approval; (3) bump semver on every edit
of versioned artifacts (SKILL.md frontmatter, package.json,
pyproject.toml) per MAJOR/MINOR/PATCH rules, recorded in commit message;
(4) commit freely, never push without explicit per-session user approval
.wiki/CLAUDE.md / .tasks/ override defaults from other skills (specs
.wiki/concepts/, tasks .tasks/); (2) master-only, no feature branches
without approval; (3) semver bump on every edit of versioned artifacts
(SKILL.md, package.json, pyproject.toml), recorded in commit;
(4) push freely by default — no confirmation needed;
a local push-gate skill (e.g. books — auto-deploy)
overrides per project; force/delete/non-ff always ask;
(5) transit/brainstorm workspaces — artifacts to .brainstorm/ or global wiki
only via explicit user direction.
— grant via "разреши автопуш" / "allow auto-push", revoke via "отзови"
/ "revoke", session end resets to ask-mode; force/delete/non-ff push
always asks; (5) transit-zone / brainstorm workspaces — artifacts
@@ -76,36 +79,26 @@ The bump is recorded in the commit message: `feat(<artifact>): … [vX.Y.Z]` or
**Does not apply to:** artifacts with no semver field and no potential for one (wiki concept pages, README.md, shell scripts without a public interface).
## Rule 4 — Commit yes, push no (session-scoped)
## Rule 4 — Push freely, gate only where a local gate exists
**Every session starts in ask-before-push mode.** On every `git push`, ask:
**Default: push freely.** An ordinary fast-forward `git push` to the configured
upstream needs no per-push confirmation. No ask-before-push mode by default.
> Готов push'нуть в `<remote>/<branch>` (N коммитов: <subjects>). Ок?
**Per-project push gate.** A project whose push triggers side effects carries a
LOCAL project-scope skill (convention: `push-gate`) that replaces this default
with ask-before-push for that project. Example: `books` — push to master runs
Gitea Actions auto-deploy. Respect the local gate over this rule: if the project
has a `push-gate` skill, its semantics win for that project; this rule's
free-push default does not apply there.
(or its English equivalent if the user is communicating in English) and wait for explicit `yes` / `да` / `push` / equivalent. Without confirmation — do not push.
**Granting auto-push within a session.** When the user says:
- "разреши автопуш" / "allow auto-push" / "автопуш ок" / equivalent
— push without further confirmation until the end of the session or until revoked.
**Revoking auto-push within a session.** When the user says:
- "отзови автопуш" / "revoke auto-push" / "снова спрашивай" / equivalent
— return to ask-before-push mode.
**Session end resets to ask-mode.** The next session starts asking again, regardless of what was granted in the previous one. This is intentional: a grant is given for the current context (user nearby, consciously decided pushes are safe), and should not survive a context switch.
**Always ask, even with active grant:**
**Always ask, regardless of any grant:**
- `git push --force` / `--force-with-lease` (history rewrite);
- `git push origin --delete <branch>` (branch deletion);
- push to a remote/branch other than the current tracked upstream (`git push other-remote ...`, `git push origin other-branch`);
- push to the main branch that would require non-fast-forward (i.e. would need force).
A grant covers ordinary fast-forward push to the configured upstream. Anything else is a separate class of operation and needs its own decision.
Anything else is an ordinary fast-forward push and proceeds without a gate.
**What counts as "push":** only `git push` family commands. Local commits, `git stash push`, etc. are not push; the grant does not apply.