docs(intake): add client intake guide for requirements submission

- Step-by-step guide for submitting requirements via Gitea PR.
- Requirement template block (REQ format) with user story, acceptance criteria,
  out-of-scope, and open questions.
- Channel matrix: PR for requirements, Issue for goals/bugs.
- Quick checklist and escalation path.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

docs/intake-guide.md

@@ -0,0 +1,69 @@
+# Client Intake Guide — How to Submit Requirements to InboxOS
+
+> **Owner:** [SAA](/CIA/agents/saa)
+> **Project:** InboxOS (`/INB/projects/inboxos`)
+> **Source of truth:** this document on `main`
+
+## 1. Choose the right channel
+
+| What you want to submit | Where to submit it | Who approves |
+|---|---|---|
+| A **product requirement** (a testable behavior) | Edit `docs/requirements.md` and open a **Pull Request** | Client (CPO) merges after SAA review |
+| A **strategic goal, initiative, or epic** | Open a **Gitea Issue** | Client approves the Issue after SAA structures it |
+| A **bug or technical-debt report** | Open a **Gitea Issue** with label `debt` or `risk` | Client triages with SAA |
+
+## 2. Requirement format (for `docs/requirements.md`)
+
+Every requirement must follow this exact block. Copy the template, fill in the blanks, and append it to the `## Initial requirements` section (or a named section the CPO has created).
+
+```markdown
+### REQ-<ID> - <Title>
+
+- **Owner:** CPO
+- **Status:** Draft
+- **Priority:** P0 | P1 | P2 | P3
+- **Linked issue:** INB-<n> (auto-created by SAA after intake)
+- **Roadmap milestone:** M<n>
+
+**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. Open the PR
+
+1. Create a branch from `main` (e.g., `req/my-new-feature`).
+2. Edit `docs/requirements.md`.
+3. Commit with a message like `docs(requirements): add REQ-XYZ for <short description>`.
+4. Open a Pull Request against `main`.
+5. The SAA will review, link the requirement to the Roadmap, and request any clarifications directly in the PR thread.
+6. **You (the Client/CPO) merge the PR** — this is the Pillar I Gate approval. No merge happens without your explicit action.
+
+## 4. What happens next
+
+- SAA creates the linked Gitea Issue (`INB-<n>`), assigns it to the correct Initiative/Epic, and updates the Roadmap if needed.
+- The CTO picks it up for technical decomposition (Pillar II).
+- Engineering implements it (Pillar III).
+- The Release agent tags and deploys it (Pillar IV).
+
+## 5. 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).
+
+## 6. Need help?
+
+If the requirement spans multiple Initiatives, touches a new MAJOR version boundary, or you are unsure which Milestone it belongs to, open a Gitea Issue titled `[Intake] <short description>` and @-mention the SAA. The SAA will route it through the correct Pillar I Gate.