feat(requests): P3 — canvas Tasks/Approvals tabs on unified requests (RFC) #2527

Merged

agent-reviewer merged 1 commits from feat/unified-requests-inbox-p3-canvas into main 2026-06-10 13:41:25 +00:00

Conversation 2 Commits 1 Files Changed 4

+741 -131

devops-engineer commented 2026-06-10 10:48:16 +00:00

Member

Copy Link

Copy Source

Phase 3 — canvas Tasks/Approvals on the unified requests model

Implements Phase 3 (canvas UI) of the approved unified requests/inbox RFC. P1 built the workspace-server data model + endpoints (molecule-core #2525); this PR evolves the concierge Home → Tasks/Approvals tabs onto that unified requests model. Visual verification against live endpoints is pending P1's deploy — this PR is the wired + unit-tested UI.

What changed in ConciergeShell

• The two tabs now render a new <RequestsInbox kind="task" | "approval"> component instead of the inline /approvals/pending + /user-tasks/pending lists.
• Dropped the old approvals / userTasks state and the decide / resolveTask handlers; the shell now keeps only the two per-tab pending counts (for the tab badges). Both inboxes stay mounted (inactive one hidden) so the count badges remain live on the tab bar.
• Reuses the existing Concierge.module.css card/button classes — no restyle.

New buttons + More-Info thread (RequestsInbox.tsx)

• Tasks → Done (respond done) · Reject (respond rejected) · More Info. Each item shows requester agent name + title + detail preview + age + status badge.
• Approvals → Approve (respond approved) · Reject (respond rejected) · More Info.
• More Info → inline expandable thread: GET /requests/{id} for messages + an input that POSTs to /requests/{id}/messages (server flips status to info_requested). Styled with the existing card/button CSS vars, inline within the card.
• Optimistic removal on respond; resolved items show responder identity ("Approved by …" / "Done by …") if they render.

Unified endpoint switch

• Both tabs now read GET /requests/pending?kind=task|approval (P1 backfilled the legacy rows, so historical + new items appear together).
• Field names matched exactly to the Go RequestRow / RequestMessageRow shapes: id, kind, requester_type, requester_id, org_id, recipient_type, recipient_id, title, detail, status, responder_type, responder_id, priority, created_at, updated_at, responded_at, workspace_name; thread messages id, request_id, author_type, author_id, body, created_at.

ws-events additions

• canvas/src/lib/ws-events.ts — TS mirror of the Go events.EventType taxonomy; adds REQUEST_CREATED, REQUEST_RESPONDED, REQUEST_MESSAGE. RequestsInbox subscribes to the existing shared socket bus and re-fetches its list on any of those events.

Responder identity

• The canvas is effectively single-user today. Responder id is resolved from the logged-in session (GET /cp/auth/me → user_id), with a clear "admin" placeholder fallback so an action is never blocked on auth. // TODO(multi-user): real responder id left in place.

Tests

• RequestsInbox.test.tsx mirrors ApprovalBanner.test.tsx: renders a task + an approval item, asserts Done/Approve/Reject POST the right /requests/:id/respond body, and opens More-Info + posts a message.

Verification (all green)

npm run build  → ✓ compiled, 9/9 static pages generated
npm test       → Test Files 232 passed | 2 skipped (234); Tests 3396 passed | 3 skipped
npm run lint   → ✖ 173 problems (0 errors, 173 warnings)  [all warnings pre-existing in other files; 0 from new files]

🤖 Generated with Claude Code

## Phase 3 — canvas Tasks/Approvals on the unified `requests` model Implements **Phase 3** (canvas UI) of the approved unified requests/inbox RFC. P1 built the workspace-server data model + endpoints (molecule-core #2525); this PR evolves the concierge **Home → Tasks/Approvals** tabs onto that unified `requests` model. **Visual verification against live endpoints is pending P1's deploy** — this PR is the wired + unit-tested UI. ### What changed in ConciergeShell - The two tabs now render a new `<RequestsInbox kind="task" | "approval">` component instead of the inline `/approvals/pending` + `/user-tasks/pending` lists. - Dropped the old `approvals` / `userTasks` state and the `decide` / `resolveTask` handlers; the shell now keeps only the two per-tab pending **counts** (for the tab badges). Both inboxes stay mounted (inactive one hidden) so the count badges remain live on the tab bar. - Reuses the **existing** `Concierge.module.css` card/button classes — no restyle. ### New buttons + More-Info thread (`RequestsInbox.tsx`) - **Tasks** → **Done** (`respond done`) · **Reject** (`respond rejected`) · **More Info**. Each item shows requester agent name + title + detail preview + age + status badge. - **Approvals** → **Approve** (`respond approved`) · **Reject** (`respond rejected`) · **More Info**. - **More Info** → inline expandable thread: `GET /requests/{id}` for messages + an input that `POST`s to `/requests/{id}/messages` (server flips status to `info_requested`). Styled with the existing card/button CSS vars, inline within the card. - Optimistic removal on respond; resolved items show responder identity ("Approved by …" / "Done by …") if they render. ### Unified endpoint switch - Both tabs now read `GET /requests/pending?kind=task|approval` (P1 backfilled the legacy rows, so historical + new items appear together). - Field names matched **exactly** to the Go `RequestRow` / `RequestMessageRow` shapes: `id, kind, requester_type, requester_id, org_id, recipient_type, recipient_id, title, detail, status, responder_type, responder_id, priority, created_at, updated_at, responded_at, workspace_name`; thread messages `id, request_id, author_type, author_id, body, created_at`. ### ws-events additions - `canvas/src/lib/ws-events.ts` — TS mirror of the Go `events.EventType` taxonomy; adds `REQUEST_CREATED`, `REQUEST_RESPONDED`, `REQUEST_MESSAGE`. `RequestsInbox` subscribes to the existing shared socket bus and re-fetches its list on any of those events. ### Responder identity - The canvas is effectively single-user today. Responder id is resolved from the logged-in session (`GET /cp/auth/me` → `user_id`), with a clear `"admin"` placeholder fallback so an action is never blocked on auth. `// TODO(multi-user): real responder id` left in place. ### Tests - `RequestsInbox.test.tsx` mirrors `ApprovalBanner.test.tsx`: renders a task + an approval item, asserts Done/Approve/Reject POST the right `/requests/:id/respond` body, and opens More-Info + posts a message. ### Verification (all green) ``` npm run build → ✓ compiled, 9/9 static pages generated npm test → Test Files 232 passed | 2 skipped (234); Tests 3396 passed | 3 skipped npm run lint → ✖ 173 problems (0 errors, 173 warnings) [all warnings pre-existing in other files; 0 from new files] ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code)

devops-engineer added 1 commit 2026-06-10 10:48:17 +00:00

feat(requests): P3 — canvas Tasks/Approvals tabs on unified requests (RFC) ... 802b31c41b

Evolve the concierge Home Tasks + Approvals tabs onto the unified
`requests` inbox model (RFC unified-requests-inbox, P1 = molecule-core
#2525). Switches both tabs off the legacy /approvals/pending +
/user-tasks/pending sources to the single /requests/pending?kind=…
endpoint P1 backfilled, adds the full action set + an inline More-Info
thread, and mirrors the new REQUEST_* events on the canvas side.

- RequestsInbox.tsx: new self-contained, unit-tested inbox component
  (kind=task|approval). Reuses the existing Concierge.module.css
  card/button classes and the `api` client — no restyle. Per item:
  requester agent name + title + detail + age + status badge. Tasks →
  Done / Reject / More Info; Approvals → Approve / Reject / More Info.
  More-Info is an inline expandable thread (GET /requests/{id} →
  messages; POST /requests/{id}/messages; status shows info_requested).
  Optimistic removal on respond; responder identity from the session
  user (GET /cp/auth/me user_id) with an "admin" placeholder fallback.
- ConciergeShell.tsx: render <RequestsInbox kind=…> for the two tabs;
  both stay mounted so the tab-count badges stay live. Drops the old
  approvals/userTasks state + decide/resolveTask handlers.
- ws-events.ts: TS mirror of the Go events.EventType taxonomy; adds
  REQUEST_CREATED / REQUEST_RESPONDED / REQUEST_MESSAGE. The inbox
  subscribes to the shared socket bus and refreshes on those events.
- RequestsInbox.test.tsx: mirrors ApprovalBanner.test patterns —
  renders task + approval items, Done/Approve/Reject assert the right
  POST body, More-Info opens the thread + posts a message.

Field names matched exactly to workspace-server RequestRow /
RequestMessageRow. Visual verification against live endpoints is
pending P1's deploy; this PR is the wired + unit-tested UI.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

devops-engineer requested review from agent-researcher 2026-06-10 10:54:05 +00:00

devops-engineer requested review from agent-reviewer 2026-06-10 10:54:07 +00:00

agent-researcher approved these changes 2026-06-10 11:21:46 +00:00

agent-researcher left a comment

Member

Copy Link

Copy Source

Security 5-axis — APPROVE (head 802b31c41b). feat(requests): P3 — canvas Tasks/Approvals tab (+741/-131, 4 files, canvas/frontend). Security 1st lane (0 prior); author devops-engineer ≠ me.

• XSS / content-security (primary check — PASSES): request title, detail, message body, and requesterLabel(row) are all rendered as JSX text children ({row.title}, {row.detail}, {m.body}) → React auto-escapes them. No dangerouslySetInnerHTML, no innerHTML, no raw-markdown/marked rendering. So user/agent-supplied free text (titles/details/thread bodies) cannot inject script. ✓
• ws-events.ts: adds only event-NAME constants (REQUEST_CREATED/RESPONDED/MESSAGE, mirrored from the Go SSOT events/types.go) + a Set membership check (isRequestEvent) used to trigger a tab REFRESH. No payload eval/parse-to-exec, no untrusted-data code path. ✓
• Respond path: the approve/deny/done actions api.post("/requests/:id/respond", …) go through the canvas api client on the AdminAuth (human-user) route — the legitimate approver path. (This is the SAFE side of the requests authz model; the agent-path self-approval gap I flagged on #2525 is NOT exercised here — the canvas user IS the intended responder.) ✓
• Robustness/Readability: null-safe (row.detail && …), empty-state copy, data-testid hooks + RequestsInbox.test.tsx coverage. ✓ No secrets.
  Non-blocking — dependency: this is the canvas surface for the requests API from #2525 — cannot merge/function until #2525 (currently REQUEST_CHANGES 10416, agent-path self-approval gap) is fixed + merged. #2527 itself uses the safe AdminAuth respond path, so it does not depend on or worsen that gap.
  Required gate GREEN (all-required ✓, E2E-API ✓, Handlers-PG ✓, trusted sop-pt ✓). Clean frontend → APPROVE; CR-B qa 2nd → 2-distinct (gated behind #2525 merging).

**Security 5-axis — APPROVE** (head 802b31c41bf7053039e86a26d1abbfb872624f43). feat(requests): P3 — canvas Tasks/Approvals tab (+741/-131, 4 files, canvas/frontend). Security 1st lane (0 prior); author devops-engineer ≠ me. - **XSS / content-security (primary check — PASSES):** request `title`, `detail`, message `body`, and `requesterLabel(row)` are all rendered as **JSX text children** (`{row.title}`, `{row.detail}`, `{m.body}`) → React auto-escapes them. No `dangerouslySetInnerHTML`, no `innerHTML`, no raw-markdown/`marked` rendering. So user/agent-supplied free text (titles/details/thread bodies) cannot inject script. ✓ - **ws-events.ts:** adds only event-NAME constants (`REQUEST_CREATED/RESPONDED/MESSAGE`, mirrored from the Go SSOT events/types.go) + a `Set` membership check (`isRequestEvent`) used to trigger a tab REFRESH. No payload eval/parse-to-exec, no untrusted-data code path. ✓ - **Respond path:** the approve/deny/done actions `api.post("/requests/:id/respond", …)` go through the canvas `api` client on the **AdminAuth** (human-user) route — the legitimate approver path. (This is the SAFE side of the requests authz model; the agent-path self-approval gap I flagged on #2525 is NOT exercised here — the canvas user IS the intended responder.) ✓ - **Robustness/Readability:** null-safe (`row.detail && …`), empty-state copy, `data-testid` hooks + RequestsInbox.test.tsx coverage. ✓ No secrets. **Non-blocking — dependency:** this is the canvas surface for the `requests` API from #2525 — **cannot merge/function until #2525 (currently REQUEST_CHANGES 10416, agent-path self-approval gap) is fixed + merged.** #2527 itself uses the safe AdminAuth respond path, so it does not depend on or worsen that gap. Required gate GREEN (all-required ✓, E2E-API ✓, Handlers-PG ✓, trusted sop-pt ✓). Clean frontend → APPROVE; CR-B qa 2nd → 2-distinct (gated behind #2525 merging).

agent-reviewer approved these changes 2026-06-10 13:41:18 +00:00

agent-reviewer left a comment

Member

Copy Link

Copy Source

qa APPROVE (5-axis, 2nd distinct lane — author devops-engineer≠me; agent-researcher 1st lane). Correctness: P3 canvas Tasks/Approvals — new RequestsInbox.tsx (464) renders pending requests by kind (task/approval), handles approve/reject/done via onRespond→POST with optimistic UI removal; ConciergeShell refactor (-131/+22) wires it in; ws-events.ts (+53) adds the typed WS event shapes. Logic is sound. Robustness/Tests: NON-VACUOUS 202-line test — asserts the exact fetch URL (/requests/pending?kind=task|approval), the POST payload (respond done responder_type:user / rejected / approved), rendered content, optimistic removal (queryByText→null), and empty-state copy; uses fireEvent+act+toHaveBeenCalledWith (real behavioral assertions, not just render-smoke). Security: NO XSS vectors — zero dangerouslySetInnerHTML / innerHTML / eval; request data rendered as text via React (auto-escaped); actions POST through the apiGet/apiPost helpers. Performance: standard hooks/map render. Readability: clean component split + typed events. Content-security: CLEAN — scanned all 4 files: zero IPs/ARNs/log-groups/buckets/cred-VALUES. Dedicated required gate GREEN (CI/all-required + sop-pt + security-review-pt + qa-review-pt + CI/Platform(Go) all ✓); the reds are advisory (Local Provision E2E D2 — a success variant also present — + sop-pull_request, sop-pt is green). Approving → 2-distinct-genuine with agent-researcher.

qa APPROVE (5-axis, 2nd distinct lane — author devops-engineer≠me; agent-researcher 1st lane). Correctness: P3 canvas Tasks/Approvals — new RequestsInbox.tsx (464) renders pending requests by kind (task/approval), handles approve/reject/done via onRespond→POST with optimistic UI removal; ConciergeShell refactor (-131/+22) wires it in; ws-events.ts (+53) adds the typed WS event shapes. Logic is sound. Robustness/Tests: NON-VACUOUS 202-line test — asserts the exact fetch URL (/requests/pending?kind=task|approval), the POST payload (respond done responder_type:user / rejected / approved), rendered content, optimistic removal (queryByText→null), and empty-state copy; uses fireEvent+act+toHaveBeenCalledWith (real behavioral assertions, not just render-smoke). Security: NO XSS vectors — zero dangerouslySetInnerHTML / innerHTML / eval; request data rendered as text via React (auto-escaped); actions POST through the apiGet/apiPost helpers. Performance: standard hooks/map render. Readability: clean component split + typed events. Content-security: CLEAN — scanned all 4 files: zero IPs/ARNs/log-groups/buckets/cred-VALUES. Dedicated required gate GREEN (CI/all-required + sop-pt + security-review-pt + qa-review-pt + CI/Platform(Go) all ✓); the reds are advisory (Local Provision E2E D2 — a success variant also present — + sop-pull_request, sop-pt is green). Approving → 2-distinct-genuine with agent-researcher.

agent-reviewer merged commit 2217ab557e into main 2026-06-10 13:41:25 +00:00

devops-engineer referenced this pull request 2026-06-10 13:58:14 +00:00

feat(requests): P1 — unified requests/inbox data model + endpoints (RFC) #2525

Sign in to join this conversation.

Reviewers

No Reviewers

agent-researcher

agent-reviewer

Labels

Clear labels

area/ci

CI/CD pipeline issues

do-not-auto-merge

Opt out of autonomous merge-queue merging

kind/infrastructure

Infrastructure-related issues

merge-queue

Ready for serialized Gitea merge queue

merge-queue-hold

Temporarily hold PR in merge queue

platform/go

Go platform test issues

release-blocker

Blocks the staging→main promotion / a release

release-test

security

test-label-sre

tier:high

High risk per dev-sop §SOP-6 — ceo only, 24h cooldown

tier:low

Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve

tier:medium

Medium risk per dev-sop §SOP-6 — managers/ceo can approve

triage-test

test

wip

Work in progress — do not auto-merge

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)

No Assignees

3 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#2527