Add cli/contributing/changelog/archive: a CLI that trims CHANGELOG.md
to the last N entries (default 7) and writes every older release to
its own file under docs/changelog/ named <padded-semver>-<date>.md
(7.0.0 → 007.000.000-2026-05-08.md). The padded form makes a directory
listing already chronological, and the index in CHANGELOG.md is
rebuilt from the archive directory listing on every run, so it never
drifts away from what is on disk. The tool is idempotent and never
overwrites an existing archive file.
Run the migration once to split the 44-entry CHANGELOG.md into 7
inline entries plus 37 archived per-release files, with the index at
the bottom of CHANGELOG.md linking each archive in descending order.
Add docs/contributing/actions/release.md as the contributor-facing
release procedure (versioning, active window vs. archive, cutting a
release end-to-end, CI hand-off on tag push) and add a docs README
under docs/changelog/ that explains the archive directory layout and
filename schema. Cross-link release.md from pipeline.md and add
"releases" to the actions/ scope description.
Documentation cleanup pass on every page touched in the previous
mapping refactor:
- Remove "is the SPOT for X" / "Single Point of Truth" self-labels
across docs/contributing/, docs/agents/, and docs/changelog/. The
rule in documentation.md forbids self-declared SPOT status; status
is conferred by readers cross-linking, not by the page asserting
it. Rephrase to descriptive phrasing ("This page covers X",
"describes X", "lists X") throughout.
- Drop the orphaned docs/contributing/tools/actions.md duplicate
(101 lines paralleling tools/github/actions/workflows.md, with no
inbound links).
- Fix em-dashes used as thought breaks in dockerfile.md, origin.md,
agents/style.css.md, and suppression.md per documentation.md.
- Unwrap soft-wrapped sentences in iam/common.md, iam/ldap.md,
iam/oidc.md, image/origin.md, requirements.md, and dockerfile.md
so each logical line carries one full sentence.
Add a unit test for the archive CLI under
tests/unit/cli/contributing/changelog/archive/test_main.py covering
_pad_version, _split_into_entries, idempotency, dry-run, no-overwrite
of existing archives, and the multi-run index rebuild.
Quote `# noqa:` in CHANGELOG.md prose with backticks so the
noqa-only-ruff-codes lint does not parse "for" as a non-ruff code.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.0 KiB
Requirements 📋
Requirements live under docs/requirements/ and define what the project must do.
Their primary purpose is to drive AI-agent-assisted development: a contributor creates a requirement file and then instructs the agent to iterate by following requirements.md and Role Loop, continuing until every Acceptance Criterion is fulfilled.
Creating a requirement is not mandatory to work on a task. For normal work items, bugs, or feature requests, use the project tools directly:
- Internal planning and work items: project.infinito.nexus
- Bug reports and feature requests: s.infinito.nexus/issues
Writing a requirement file is RECOMMENDED when you want an AI agent to autonomously implement and validate a feature end to end, because it gives the agent a structured, checkable definition of done.
File Naming
Every requirements file MUST follow the pattern NNN-topic.md, where NNN is a zero-padded three-digit sequence number (e.g. 000-template.md, 001-auth.md).
File Structure
Every requirements file MUST follow this template exactly:
# NNN - Title
## User Story
As a <role>, I want <goal> so that <benefit>.
## Acceptance Criteria
- [ ] Criterion one.
- [ ] Criterion two.
- The User Story MUST follow the "As a / I want / so that" format.
- Each Acceptance Criterion MUST be written as a Markdown task list item (
- [ ]). - Criteria MUST be independently verifiable, with one observable outcome per item.
- Completed criteria MUST be checked off (
- [x]) once the corresponding work is merged.
Cross-linking
- You MUST cross-link from the requirement to any PR or issue that implements it.
- You MUST cross-link from the implementing PR template back to the requirement file.
See Also
- How agents process requirements: requirements.md