mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 19:01:54 +00:00
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>
48 lines
2.0 KiB
Markdown
48 lines
2.0 KiB
Markdown
# 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](../agents/action/requirements.md) and [Compose Loop](../agents/action/iteration/compose.md), 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](https://project.infinito.nexus/)
|
|
- Bug reports and feature requests: [s.infinito.nexus/issues](https://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:
|
|
|
|
```markdown
|
|
# 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](../agents/action/requirements.md)
|