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

Adopt standard policy guidance and document provenance

Browse Source
This commit is contained in:
Eric Rakestraw
2026-09-28 01:33:03 +00:00
parent b24c9a8fdf
commit 6547a8abd3
12 changed files with 687 additions and 213 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
docs/policy/agents.md
View File

@@ -1,12 +1,14 @@
# Agent Policy
**Base Policy Version:** 1.1
**Base Policy Version:** 1.3
**Last Updated**: 2026-09-25
**Last Updated**: 2026-09-28
**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
@@ -14,8 +16,6 @@ Agents working in this repository must read and adhere to the following house ru
request. Do not implicitly strengthen requirements, restrictions, or guarantees
beyond what the user actually requested.
Simplify the mechanism, not the user's choices.
**Keep implementation machinery proportionate.** Use straightforward,
idiomatic code and introduce only the machinery needed to support the requested
behavior and flexibility. Optimize for conceptual simplicity and
@@ -29,11 +29,6 @@ operator and caller choice where policy has not been established. If an
additional restriction appears advisable, present it as a decision rather than
silently implementing it.
A correctness constraint must follow from the requested behavior or an
established invariant, not from the convenience of the chosen implementation.
Explain the specific failure it prevents and why a less restrictive
implementation cannot satisfy the contract.
**Do not invent guarantees.** Do not strengthen public contracts, guarantees,
or invariants beyond those expressly requested by the user.
@@ -46,30 +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 this principle.
Agent-authored plans, tests, documentation, and prior implementations are not
evidence that an additional restriction was deliberately approved. Identify the
authorizing requirement or decision; when that authority is unclear, surface
the ambiguity rather than treating repetition as approval.
Standard-library guidance does not authorize weakening Narratio's established
filesystem, manifest, or publication contracts. Preserve them unless a deliberate
decision changes them.
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:
@@ -77,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.