kevinveenbirkenbachandClaude Opus 4.8
c76c6da6a8
svc-storage-nfs-server gains a backend flavor selected by services.nfs-server.flavor (default "{{ 'ganesha' if RUNTIME in ['dev','act'] else 'kernel' }}"). The ganesha flavor installs nfs-ganesha + FSAL_VFS and renders /etc/ganesha/ganesha.conf (NFSv4, Pseudo == Path so clients mount the real paths unchanged, Root_Squash on the export base and No_Root_Squash on the state subdir), reloaded via systemctl restart. It runs in the dev/act DinD swarm-test, where the host kernel nfsd is not network-namespaced and a privileged node driving exportfs would wedge it into a D-state. The kernel flavor keeps nfs-kernel-server + exportfs -ra for production and every non-dev/act runtime. 01_core dispatches on the flavor, 03_prepare holds the shared export preparation, flavor/{kernel,ganesha}/main.yml hold the per-backend install/render/service steps, and handlers gains the ganesha restart.
docs/agents/action/iteration: role.md renamed to compose.md (Compose Loop); new swarm.md for the swarm deploy loop split out of workflow.md; workflow.md trimmed to GitHub Actions workflow iteration; all cross-references updated; the duplicated README gotcha removed; the NFS gotcha rewritten to the ganesha design.
Also drops a retired-flag history comment in group_vars/all/01_modes.yml and a redundant comment in the init selection script, and allows WebFetch(repology.org) used during ganesha packaging research.
Co-Authored-By: Claude Opus 4.8 <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 Compose 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