coreci/inboxos-v1
18
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases 3 Wiki Activity

docs(intake): add Client Intake Guide for requirements submission #106

Merged
grimacing merged 2 commits from docs/intake-guide into main 2026-06-10 19:34:22 +00:00
Conversation 0 Commits 2 Files Changed 1
+79
solutions-architect commented 2026-06-10 19:13:40 +00:00
Contributor
Copy Link
Copy Source

This PR answers the client question: "How do I submit requirements in Gitea in a format you will accept? Give me a step-by-step so I can try."

What changed

  • Added docs/intake-guide.md with a complete step-by-step guide.

Step-by-step summary (for the client)

  1. Choose the channel

    • Product requirement → edit docs/requirements.md and open a Pull Request.
    • Strategic goal/bug → open a Gitea Issue.

  2. Use the template
    Copy the REQ-<ID> block from docs/intake-guide.md §2 into docs/requirements.md.

  3. Open a branch & PR

    • Branch from main (e.g., req/my-feature).
    • Commit with docs(requirements): add REQ-XYZ for ....
    • Open PR against main.

  4. I (SAA) review

    • I will link it to the Roadmap, request clarifications in the PR thread if needed, and route it through Pillar I Gate.

  5. You merge the PR

    • Your merge is the Client approval (Pillar I Gate). No one else merges requirement PRs.

  6. Downstream flow

    • SAA creates the linked Issue → CTO decomposes (Pillar II) → Engineering builds (Pillar III) → Release tags (Pillar IV).

Ready to try?

  1. Merge this PR to accept the guide.
  2. Open a new branch, edit docs/requirements.md with your first requirement using the template.
  3. Open the PR — I will pick it up in the next heartbeat.

/label ~pillar-i ~documentation

This PR answers the client question: *"How do I submit requirements in Gitea in a format you will accept? Give me a step-by-step so I can try."* ## What changed - Added `docs/intake-guide.md` with a complete step-by-step guide. ## Step-by-step summary (for the client) 1. **Choose the channel** - Product requirement → edit `docs/requirements.md` and open a **Pull Request**. - Strategic goal/bug → open a **Gitea Issue**. 2. **Use the template** Copy the `REQ-<ID>` block from `docs/intake-guide.md` §2 into `docs/requirements.md`. 3. **Open a branch & PR** - Branch from `main` (e.g., `req/my-feature`). - Commit with `docs(requirements): add REQ-XYZ for ...`. - Open PR against `main`. 4. **I (SAA) review** - I will link it to the Roadmap, request clarifications in the PR thread if needed, and route it through Pillar I Gate. 5. **You merge the PR** - Your merge is the Client approval (Pillar I Gate). No one else merges requirement PRs. 6. **Downstream flow** - SAA creates the linked Issue → CTO decomposes (Pillar II) → Engineering builds (Pillar III) → Release tags (Pillar IV). ## Ready to try? 1. Merge this PR to accept the guide. 2. Open a new branch, edit `docs/requirements.md` with your first requirement using the template. 3. Open the PR — I will pick it up in the next heartbeat. /label ~pillar-i ~documentation
solutions-architect added 1 commit 2026-06-10 19:13:40 +00:00
docs(intake): add client intake guide for requirements submission
InboxOS — PR CI / Fast offline tests (pull_request) Successful in 32s
Details
InboxOS — PR CI / 100MB historical e2e (pull_request) Successful in 11m12s
Details
InboxOS — PR CI / Live Ollama extract smoke (pull_request) Successful in 48s
Details
8e3bf8be02 
- 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>
solutions-architect added 1 commit 2026-06-10 19:31:52 +00:00
docs(intake): rewrite guide for non-technical client — Issues only, no PRs
InboxOS — PR CI / Fast offline tests (pull_request) Successful in 32s
Details
InboxOS — PR CI / Live Ollama extract smoke (pull_request) Successful in 41s
Details
InboxOS — PR CI / 100MB historical e2e (pull_request) Successful in 11m22s
Details
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>
grimacing merged commit 840c40d6af into main 2026-06-10 19:34:22 +00:00
grimacing deleted branch docs/intake-guide 2026-06-10 19:34:22 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
architecture
compliance
cpo-approval-required
Item carries CPO-APPROVAL-REQUIRED flag (board approval needed before PR dual-approval)
 cpo-review
CPO review required before EXECUTE wave
 cto-approved
CTO approved — Pillar III gate passed
 debt
domain/architecture
Engineering domain: architecture
 domain/backend
Engineering domain: backend
 domain/data-model
Engineering domain: data-model
 domain/data-pipeline
Engineering domain: data-pipeline
 domain/devops
Engineering domain: devops
 domain/frontend
Engineering domain: frontend
 domain/security
Engineering domain: security
 domain/ux
Engineering domain: ux
 epic
feature
infra
initiative
intake
New requirement submitted by the Client for SAA intake
 major/v1
MAJOR v1 umbrella — all v1 Initiatives/Epics/PRs trace to this label.
 needs-cto-clarification
Ambiguity detected — reassigned to CTO for design direction
 pattern/a
Dependency pattern a
 pattern/b
Dependency pattern b
 pattern/c
Dependency pattern c
 pattern/d
Dependency pattern d
 pattern/e
Dependency pattern e
 pattern/f
Dependency pattern f
 pattern/g
Dependency pattern g
 pillar-i
Pillar I (Strategic Alignment) gate artifact — Roadmap, MAJOR Umbrella, MINOR Milestones, gate PRs.
 pillar-ii
Execution / decomposition lane (CTO)
 pillar-ii-approved
Pillar II design/spec approved by CTO
 pillar-iii
Pillar III — implementation / integration / ADR stories
 refactor
risk
status:dev
Kanban state per INB-172 rule 2.
 status:done
Kanban state per INB-172 rule 2.
 status:qa
Kanban state per INB-172 rule 2.
 status:triage
Kanban state per INB-172 rule 2.
 story
technical-debt
Tech-debt sweep per INB-172 alias command (tea issues list --label technical-debt).
 trd
type:epic
issue-hierarchy canon class (standards/issue-hierarchy.md)
 type:feature
issue-hierarchy canon class (standards/issue-hierarchy.md)
 type:needs-triage
issue-hierarchy canon class (standards/issue-hierarchy.md)
 type:project
issue-hierarchy canon class (standards/issue-hierarchy.md)
 type:task
issue-hierarchy canon class (standards/issue-hierarchy.md)
 type:user-story
issue-hierarchy canon class (standards/issue-hierarchy.md)
 v1.0
v1.4
v1.5
MINOR v1.5 — Mailbox & Administrative Management Interface
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
coreci-bot coreci-cairo (Elena Voss (CAIRO)) coreci-ceo (Alexandra Reed — CEO) coreci-coo (Marcus Wright) grimacing jonathan (jonathan)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: coreci/inboxos-v1#106
Delete Branch "docs/intake-guide"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?