yisroelbaum/Attainly
1
0
Fork 0
Code Issues 1 Pull requests Projects 1 Releases Packages Wiki Activity Actions

Merge branch 'docs/approval-discipline'

Browse source
This commit is contained in:
Yisroel Baum 2026-07-31 11:11:25 +03:00
commit fbc47ee6b5
Signed by: yisroelbaum
GPG key ID: 0FA60884F75520A9
1 changed files with 27 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

29
ai/shared.md
View file

@ -39,14 +39,39 @@ Use judgment for changes that cannot meaningfully be test-driven, such as
documentation-only edits or declarative environment configuration. Validate documentation-only edits or declarative environment configuration. Validate
those changes with the most relevant parser, formatter, dry run, or check. those changes with the most relevant parser, formatter, dry run, or check.
## Approval discipline
- Treat dependency installation, tests, static analysis, formatting, linting,
type checking, and builds as routine project operations. Run them without
asking for advance approval when they stay within the requested scope and
sandbox boundaries.
- If an essential operation is blocked by sandbox or network policy, batch the
necessary provisioning or validation into one narrowly scoped approval
request. Prefer a reusable command prefix when it can be safely limited to
the required tool and operation.
- Do not request repeated approvals for commands that fit a previously
approved scope.
- Do not prefix routine commands with per-command cache environment overrides.
Configure cache locations once in Codex, direnv, or the project environment.
Use temporary overrides only to diagnose a cache-specific problem.
- Truly destructive actions, external writes, main-stack control, and
operations outside the workspace still require explicit approval.
## Running processes ## Running processes
- The main checkout owns the canonical stack on the default ports. Assume it - The main checkout owns the canonical stack on the default ports. Assume it
is the user's stack. Do not start, restart, or stop it unless the user asks. is the user's stack. Do not start, restart, or stop it unless the user asks.
- A worktree owns its own isolated stack. The flake shell hook assigns a - A worktree owns its own isolated stack. The flake shell hook assigns a
deterministic port offset and creates worktree-local PostgreSQL state. deterministic port offset and creates worktree-local PostgreSQL state.
- Start a worktree stack from its root. For non-interactive use, start it - Start a worktree stack only when runtime or integration validation requires
detached and stop it when finished, as shown below. it. Start it once from the worktree root, reuse it throughout validation,
and stop it once when finished.
- Do not start any service for PHPUnit, frontend formatting, linting, type
checking, or production builds.
- When authorized worktree stack control is necessary, operate it directly.
Do not ask the user to start or stop worktree services.
- For non-interactive use, start the stack detached and stop it when finished,
as shown below.
- Do not use `process-compose -t=false` for a detached stack. It can leave an - Do not use `process-compose -t=false` for a detached stack. It can leave an
orphaned PostgreSQL process holding the data directory. orphaned PostgreSQL process holding the data directory.
- Non-interactive agent shells do not automatically load direnv. Bare project - Non-interactive agent shells do not automatically load direnv. Bare project