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

REQ-001 - Mailbox & Administrative Management Interface #107

New Issue
Closed
opened 2026-06-10 19:30:35 +00:00 by grimacing · 5 comments
grimacing commented 2026-06-10 19:30:35 +00:00
Owner
Copy Link
Copy Source
  • Owner: @grimacing
  • Status: Draft
  • Priority: P0
  • Linked issue: TBD
  • Roadmap milestone: TBD

User story.
As a system user (Mailbox Owner, Operator, or Administrator), I want a polished, role-based interface to manage ingested emails and monitor system health, so that I can efficiently process communications and ensure operational stability.

Acceptance criteria.

  1. Mailbox Owner View: A dedicated dashboard where owners can view a list of ingested emails, search/filter by metadata, and perform management actions (e.g., archive, mark as processed).
  2. Admin/Operator View: A distinct "Ops Console" providing a high-level observability dashboard (e.g., ingestion rates, error logs, system latency) and administrative controls (e.g., user permission management, global configuration).
  3. Role-Based Access Control (RBAC): The system must automatically route users to the correct view based on their permissions, preventing Mailbox Owners from accessing the Admin/Operator console.
  4. UI/UX Polish: The interface must adhere to the design system, ensuring responsive layouts, intuitive navigation, and clear visual feedback for all user actions.

Out of scope.

  • Implementation of the actual email ingestion engine (backend logic).
  • Integration with third-party email clients (e.g., Outlook/Gmail plugins).
  • Advanced analytics/reporting tools (e.g., custom PDF reports).

Open questions.

  • Does the CEO want a "Super Admin" view that combines both the Mailbox Owner and Operator perspectives, or should they remain strictly separated?
  • Are there specific compliance/audit logs that the Board requires to be visible within the Admin view?
- **Owner:** @grimacing - **Status:** Draft - **Priority:** P0 - **Linked issue:** TBD - **Roadmap milestone:** TBD **User story.** As a system user (Mailbox Owner, Operator, or Administrator), I want a polished, role-based interface to manage ingested emails and monitor system health, so that I can efficiently process communications and ensure operational stability. **Acceptance criteria.** 1. **Mailbox Owner View:** A dedicated dashboard where owners can view a list of ingested emails, search/filter by metadata, and perform management actions (e.g., archive, mark as processed). 2. **Admin/Operator View:** A distinct "Ops Console" providing a high-level observability dashboard (e.g., ingestion rates, error logs, system latency) and administrative controls (e.g., user permission management, global configuration). 3. **Role-Based Access Control (RBAC):** The system must automatically route users to the correct view based on their permissions, preventing Mailbox Owners from accessing the Admin/Operator console. 4. **UI/UX Polish:** The interface must adhere to the design system, ensuring responsive layouts, intuitive navigation, and clear visual feedback for all user actions. **Out of scope.** - Implementation of the actual email ingestion engine (backend logic). - Integration with third-party email clients (e.g., Outlook/Gmail plugins). - Advanced analytics/reporting tools (e.g., custom PDF reports). **Open questions.** - Does the CEO want a "Super Admin" view that combines both the Mailbox Owner and Operator perspectives, or should they remain strictly separated? - Are there specific compliance/audit logs that the Board requires to be visible within the Admin view?
grimacing added the intake label 2026-06-10 19:33:43 +00:00
saa commented 2026-06-10 19:37:47 +00:00
Collaborator
Copy Link
Copy Source

SAA Intake Acknowledgement — REQ-001Thank you for the requirement. The SAA has captured it verbatim as a new client goal for the active MAJOR v1 line.Scope-creep decision: Absorb into MAJOR v1 (default per SAA SOP §8). Once the open questions below are resolved, the SAA will draft a Roadmap revision adding a new Initiative (and supporting Epics) under the MAJOR v1 umbrella, target a MINOR Milestone, and open a Pillar I Gate PR for your approval. No technical work begins before Gate passage.**Blocker — ambiguity must be resolved upstream:**The following open questions from your intake body are Pillar I blockers. Please reply directly on this Issue:1. Super Admin view: Do you want a unified "Super Admin" view that combines both Mailbox Owner and Operator perspectives, or should they remain strictly separated?2. Compliance/audit logs: Are there specific compliance or audit logs that the Board requires to be visible within the Admin view?Traceability note (provisional):- REQ-001 → (pending Roadmap revision) → MAJOR v1 umbrella → Pillar I Gate PR → Goal 1 (core pipeline extension) or new Goal.Next action: Awaiting your answers on this Issue. The SAA will then open the Pillar I Gate PR within the same heartbeat cycle.

**SAA Intake Acknowledgement — REQ-001**Thank you for the requirement. The SAA has captured it verbatim as a new client goal for the active MAJOR v1 line.**Scope-creep decision:** Absorb into MAJOR v1 (default per SAA SOP §8). Once the open questions below are resolved, the SAA will draft a Roadmap revision adding a new Initiative (and supporting Epics) under the [MAJOR v1 umbrella](https://git.cloudinit.dev/jc-capital/inboxos/issues/99), target a MINOR Milestone, and open a Pillar I Gate PR for your approval. No technical work begins before Gate passage.**Blocker — ambiguity must be resolved upstream:**The following open questions from your intake body are Pillar I blockers. Please reply directly on this Issue:1. **Super Admin view:** Do you want a unified "Super Admin" view that combines both Mailbox Owner and Operator perspectives, or should they remain strictly separated?2. **Compliance/audit logs:** Are there specific compliance or audit logs that the Board requires to be visible within the Admin view?**Traceability note (provisional):**- REQ-001 → (pending Roadmap revision) → MAJOR v1 umbrella → Pillar I Gate PR → Goal 1 (core pipeline extension) or new Goal.**Next action:** Awaiting your answers on this Issue. The SAA will then open the Pillar I Gate PR within the same heartbeat cycle.
grimacing commented 2026-06-10 19:39:49 +00:00
Author
Owner
Copy Link
Copy Source
  1. strictly separated
  2. keep the observability basic for the first round
1. strictly separated 2. keep the observability basic for the first round
saa commented 2026-06-10 19:51:01 +00:00
Collaborator
Copy Link
Copy Source

SAA Intake Resolution — REQ-001

The SAA has absorbed REQ-001 into MAJOR v1 as MINOR v1.5 — Mailbox & Administrative Management Interface.

What changed:

  • Goal 5 added to the Strategic Roadmap (docs/roadmap.md).
  • Initiative INTV-5 declared with four Epics (A-D).
  • Requirement recorded in docs/requirements.md.
  • Open questions resolved (strictly separated views; basic observability).

Pillar I Gate PR opened: #108

No technical work begins before the Client approves and merges PR #108. Once merged, the SAA will create the v1.5 Milestone, INTV-5 Issue, and Epic sub-issues.

Traceability:

  • REQ-001 → Goal 5 → INTV-5 → MAJOR v1 umbrella → PR #108.
**SAA Intake Resolution — REQ-001** The SAA has absorbed REQ-001 into MAJOR v1 as MINOR **v1.5 — Mailbox & Administrative Management Interface**. **What changed:** - Goal 5 added to the Strategic Roadmap (`docs/roadmap.md`). - Initiative **INTV-5** declared with four Epics (A-D). - Requirement recorded in `docs/requirements.md`. - Open questions resolved (strictly separated views; basic observability). **Pillar I Gate PR opened:** [#108](https://git.cloudinit.dev/jc-capital/inboxos/pulls/108) No technical work begins before the Client approves and merges PR #108. Once merged, the SAA will create the v1.5 Milestone, INTV-5 Issue, and Epic sub-issues. **Traceability:** - REQ-001 → Goal 5 → INTV-5 → MAJOR v1 umbrella → PR #108.
saa commented 2026-06-10 20:13:45 +00:00
Collaborator
Copy Link
Copy Source

REQ-001 intake absorbed into MAJOR v1 — Gate passed

  • Pillar I Gate PR #108 merged by Client.
  • Goal 5, Initiative INTV-5, and Epics A–D created under MINOR v1.5.
  • Open questions (strictly separated views; basic observability) resolved on this thread.

Decision: Scope absorbed into active MAJOR v1 as in-scope creep per SAA policy.
Next owner: CEO for Pillar II routing to CTO.

## REQ-001 intake absorbed into MAJOR v1 — Gate passed - Pillar I Gate PR [#108](https://git.cloudinit.dev/jc-capital/inboxos/pulls/108) merged by Client. - Goal 5, Initiative INTV-5, and Epics A–D created under MINOR v1.5. - Open questions (strictly separated views; basic observability) resolved on this thread. **Decision:** Scope absorbed into active MAJOR v1 as in-scope creep per SAA policy. **Next owner:** CEO for Pillar II routing to CTO.
saa closed this issue 2026-06-10 22:06:10 +00:00
saa commented 2026-06-10 22:06:23 +00:00
Collaborator
Copy Link
Copy Source

Intake complete — REQ-001 absorbed into MAJOR v1

  • Roadmap revision merged via Pillar I Gate PR #108.
  • Initiative INTV-5 and Epics A–D created under MINOR v1.5.
  • Open questions resolved (strictly separated views; basic observability).
  • Pillar II Gate PR #136 is open and awaiting Client review.

Next owner: CEO for downstream routing (Pillar II → CTO).

## Intake complete — REQ-001 absorbed into MAJOR v1 - Roadmap revision merged via Pillar I Gate PR [#108](https://git.cloudinit.dev/jc-capital/inboxos/pulls/108). - Initiative INTV-5 and Epics A–D created under MINOR v1.5. - Open questions resolved (strictly separated views; basic observability). - Pillar II Gate PR [#136](https://git.cloudinit.dev/jc-capital/inboxos/pulls/136) is open and awaiting Client review. **Next owner:** CEO for downstream routing (Pillar II → CTO).
coreci-coo added type:needs-triage and removed intake labels 2026-10-19 22:41:48 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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 type:needs-triage
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
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: coreci/inboxos-v1#107
Delete Branch "%!s()"

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?