saa
840c40d6af
- The client is non-technical; the previous guide asked for Pull Requests. - Rewrote the guide so the only action is 'open a Gitea Issue and paste the template'. - Added the 'intake' label for SAA discovery. - Documented SAA post-submission workflow: review → approve → commit to requirements.md → update Issue. - Pillar I Gate is now an explicit Issue approval comment. Co-Authored-By: Paperclip <noreply@paperclip.ing>
2.8 KiB
2.8 KiB
Client Intake Guide — How to Submit Requirements to InboxOS
Owner: SAA Project: InboxOS Source of truth: this document on
main
1. The only thing you need to do: open a Gitea Issue
You do not need to edit files, create branches, or open Pull Requests.
Just open a Gitea Issue and paste the template below.
- Go to Issues → New Issue in the InboxOS repo.
- Copy the template in section 2 and paste it into the description box.
- Fill in every blank.
- (Optional) Add the label
intake— this helps the SAA find it faster. - Click Create Issue.
That is the entire submission. The SAA takes over from here.
2. Requirement template
### REQ-<ID> - <Title>
- **Owner:** CPO
- **Status:** Draft
- **Priority:** P0 | P1 | P2 | P3
- **Linked issue:** (leave blank — SAA will fill this)
- **Roadmap milestone:** (leave blank — SAA will fill this)
**User story.**
As a <user>, I want <capability>, so that <outcome>.
**Acceptance criteria.**
1. <Observable behavior 1>
2. <Observable behavior 2>
3. <Observable behavior 3>
**Out of scope.**
- <What this requirement explicitly does not cover>
**Open questions.**
- <Anything the CPO needs the CEO or the board to decide>
3. Does the Issue need an assignee?
No. The SAA discovers new requirements by polling open Issues.
If you add the intake label, discovery is instant. Without it, the SAA still finds it within the next heartbeat.
4. What the SAA does after you submit
- Reviews the Issue and asks clarifications in the Issue thread if anything is ambiguous.
- Approves the requirement once it is clear and traces to the Roadmap.
- Commits the approved requirement into
docs/requirements.mdonmain(or the active release branch). - Updates the Issue with the linked requirement ID and closes it.
5. Pillar I Gate (Client approval)
The Pillar I Gate is recorded in the Issue itself:
- The Client posts a comment: "Approved — ".
- No merge action, no branch creation, no file editing is required from the Client.
6. Quick checklist before submitting
- Title is descriptive (
REQ-... - <verb-led summary>). - User story follows
As a ..., I want ..., so that .... - Acceptance criteria are observable (not implementation hints).
- Out-of-scope is explicit.
- Priority is set (P0 = blocking, P1 = next MINOR, P2 = backlog, P3 = nice-to-have).
7. Bugs, strategic goals, or help
| What you want to submit | What to do |
|---|---|
| Bug or technical-debt | Open a Gitea Issue with label debt or risk. |
| Strategic goal, initiative, or epic | Open a Gitea Issue titled [Intake] <short description> and @-mention the SAA. |
| Not sure which channel | Open any Issue and @-mention the SAA. |