eric/notarius
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Align general policies and contributor guidance

Browse Source
This commit is contained in:
Eric Rakestraw
2026-09-28 01:32:50 +00:00
parent d9f8ff8179
commit 21c07d4ef0
7 changed files with 145 additions and 153 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/policy/agents.md
View File

@@ -1,20 +1,17 @@
# Agent Policy
**Base Policy Version:** 1.1
**Base Policy Version:** 1.3
**Last Updated**: 2026-09-26
**Last Updated**: 2026-09-28
Notarius adaptations preserve operator choice, existing explicit contracts, and
the deployment-permissions example below.
**Upstream Source**: https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/agents.md
## Purpose
Agents working in this repository must read and adhere to the following house rules.
Agents must read and follow these rules.
## Implementation Discipline
Simplify the mechanism, not the user's choices.
**KEY PRINCIPLES:** Write the simplest idiomatic code that satisfies the user's
request. Do not implicitly strengthen requirements, restrictions, or guarantees
beyond what the user actually requested.
@@ -44,25 +41,19 @@ idiomatic approach unless another path is expressly requested by the user.
**An implementation detail is not repository policy.** Tests and documentation
must not elevate incidental behavior into a durable guarantee or restriction
unless that behavior was expressly selected as part of the contract. Existing
explicit contracts remain authoritative; changing or weakening one requires a
deliberate decision rather than being inferred from these principles.
[ADR-0017](../adr/0017-defer-cache-access-policy-to-deployment.md) illustrates
why Unix deployments own cache access policy through permissions, umask, setgid,
and default ACLs. Notarius retains its separately adopted correctness boundaries.
unless that behavior was expressly selected as part of the contract.
## Git Commit Policy
By default, create a commit after completing each coherent unit of work, using a
By default, commit each completed, nonempty unit of work using a
concise, plain-English message describing what changed. This policy is standing
authorization to create those local commits; a separate user request is not
required. An explicit user instruction to leave work uncommitted takes precedence.
A unit of work is a focused, reviewable outcome, including its relevant tests and
documentation. Do not commit after every intermediate edit or create empty commits.
documentation.
Complete the appropriate validation before committing. If work is incomplete or
validation is blocked, report that state rather than presenting it as completed.
validation is blocked, report that state accurately.
Before committing:
@@ -70,10 +61,10 @@ Before committing:
changes. Identify changes that predate the current unit of work.
2. Exclude secrets, local environment files, generated junk, and unrelated changes.
3. Stage only the files or hunks belonging to the completed unit. Use `git add .`
only when every included change belongs to that unit. Do not disturb unrelated
staged or unstaged work.
4. Review `git diff --staged` and run appropriate checks for the change. Do not
repeat checks already passed for unchanged content merely to create a commit.
only when every included change belongs to that unit. Preserve unrelated
staged and unstaged work.
4. Review `git diff --staged` and run appropriate checks for the change. Reuse
successful checks for unchanged content.
5. Review `git log --oneline -n 10` and use
`git commit -m "<concise plain-English commit message>"`.
6. Report the commit identifier and any remaining uncommitted work.