Compare commits
1 Commits
feature/is
...
feature/is
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
1210c17989 |
45
docs/agent-constraints.md
Normal file
45
docs/agent-constraints.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
# Agent Constraints
|
||||||
|
|
||||||
|
This document records **persistent behavioral constraints** for agents working on this repository.
|
||||||
|
It is distinct from `docs/requirements-log.md`, which records **project/product requirements**.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
- Applies to all AI agents and automation that modify this repo.
|
||||||
|
- Supplements (does not replace) `docs/agents.md` and `docs/workflow.md`.
|
||||||
|
|
||||||
|
## Persistent Rules
|
||||||
|
|
||||||
|
1. **Workflow enforcement**
|
||||||
|
- Follow `docs/workflow.md` for all changes.
|
||||||
|
- Create a Gitea issue before any code or documentation change.
|
||||||
|
- Work on a feature branch `feature/issue-{N}-{short-description}` and open a PR.
|
||||||
|
- Never commit directly to `main`.
|
||||||
|
|
||||||
|
2. **Document-first routing**
|
||||||
|
- When performing work, consult relevant `docs/` files *before* making changes.
|
||||||
|
- Route decisions to the documented policy whenever applicable.
|
||||||
|
- If guidance conflicts, prefer the stricter/safety-first rule and note it in the PR.
|
||||||
|
|
||||||
|
3. **Docs with code**
|
||||||
|
- Any code change must be accompanied by relevant documentation updates.
|
||||||
|
- If no doc update is needed, state the reason explicitly in the PR.
|
||||||
|
|
||||||
|
4. **Session-persistent user constraints**
|
||||||
|
- If the user requests that a behavior should persist across sessions, record it here
|
||||||
|
(or in a dedicated policy doc) and reference it when working.
|
||||||
|
- Keep entries short and concrete, with dates.
|
||||||
|
|
||||||
|
## Change Control
|
||||||
|
|
||||||
|
- Changes to this file follow the same workflow as code changes.
|
||||||
|
- Keep the history chronological and minimize rewording of existing entries.
|
||||||
|
|
||||||
|
## History
|
||||||
|
|
||||||
|
### 2026-02-08
|
||||||
|
|
||||||
|
- Always enforce Gitea workflow: issue -> feature branch -> PR before changes.
|
||||||
|
- When work requires guidance, consult the relevant `docs/` policies first.
|
||||||
|
- Any code change must be accompanied by relevant documentation updates.
|
||||||
|
- Persist user constraints across sessions by recording them in this document.
|
||||||
@@ -6,7 +6,6 @@
|
|||||||
|
|
||||||
1. **Create Gitea Issue First** — All features, bug fixes, and policy changes require a Gitea issue before any code is written
|
1. **Create Gitea Issue First** — All features, bug fixes, and policy changes require a Gitea issue before any code is written
|
||||||
2. **Create Feature Branch** — Branch from `main` using format `feature/issue-{N}-{short-description}`
|
2. **Create Feature Branch** — Branch from `main` using format `feature/issue-{N}-{short-description}`
|
||||||
- After creating the branch, run `git pull origin main` and rebase to ensure the branch is up to date
|
|
||||||
3. **Implement Changes** — Write code, tests, and documentation on the feature branch
|
3. **Implement Changes** — Write code, tests, and documentation on the feature branch
|
||||||
4. **Create Pull Request** — Submit PR to `main` branch referencing the issue number
|
4. **Create Pull Request** — Submit PR to `main` branch referencing the issue number
|
||||||
5. **Review & Merge** — After approval, merge via PR (squash or merge commit)
|
5. **Review & Merge** — After approval, merge via PR (squash or merge commit)
|
||||||
|
|||||||
Reference in New Issue
Block a user