M2 plan¶
Milestone M2 — KM Digital Backbone — is the foundational slice of SISS. Target delivery: 14 August 2026 (UAT / SIT sign-off).
This page is a condensed view. The full, task-by-task plan lives at
docs/superpowers/plans/2026-04-13-siss-m2-km-digital-backbone.md.
What "done" looks like¶
A working end-to-end submission and approval platform with:
- RBAC + SSO via GCP Identity Platform
- Pre-consultation checklist (admin + planning validation)
- AI-assisted KM compliance checking with human-in-the-loop officer review
- Temporal-orchestrated KM workflow
- Digitally signed Kertas Perakuan + SIGL
- Email, SMS, and in-app notifications
- Submission dashboard for CMU officers
Out of scope at M2: comment inline markup (M3), comment library (M3), full BIM pipeline (M4–M5). Those services exist as deployable skeletons only.
Phase dependencies¶
flowchart LR
P0[Phase 0<br/>Repo & tooling]
P1[Phase 1<br/>core-svc]
P2[Phase 2<br/>notification-svc]
P3[Phase 3<br/>submission-svc]
P4[Phase 4<br/>workflow-svc + Temporal]
P5[Phase 5<br/>ai-svc]
P6[Phase 6<br/>signing-svc]
P7[Phase 7<br/>Frontend]
P8[Phase 8<br/>Cross-cutting<br/>verification]
P0 --> P1 --> P2
P2 --> P3
P2 --> P4
P2 --> P5
P3 --> P4
P4 --> P6
P5 --> P6
P6 --> P7
P7 --> P8
Execution phases¶
Nine phases (0 through 8) covering repo setup, all eight services, and cross-cutting verification.
Phase 0 — Repository & tooling scaffolding
Turn the repo into a pnpm + uv monorepo. Bring up a docker-compose stack
for local development (Postgres, Redis, Pub/Sub emulator, Temporal, fake
GCS, OTEL collector, MailHog). Build shared Python library libs/py/sisscommon
(config, IDs, events, logging, OTEL, DB, errors, auth context). Build
event schema library libs/events with JSON Schemas and codegen.
Output: working local stack; any service can be bootstrapped against it.
Phase 1 — core-svc (identity, RBAC, audit)
Alembic schema + ORM for orgs, users, roles, permissions, role assignments,
audit log. RBAC policy store with Pub/Sub-invalidated cache. GCP Identity
Platform OIDC / SAML broker. Policy-decision endpoint
(POST /v1/auth/authorize). JWT bootstrap endpoint. Seed data: CMU tenant,
admin user, seven seed roles. Helm + Terraform deployment via ArgoCD.
Output: every other service can authenticate and check permissions.
Phase 2 — notification-svc (cross-cutting)
Template + delivery schema. Seed templates per event type in en-MY and
ms-MY. Jinja2 rendering with variable validation. Pub/Sub consumer +
channel dispatcher (email via SendGrid / aiosmtplib, SMS stub, in-app
inbox). In-app API + WebSocket stream.
Output: every event in the catalog can drive a delivery.
Phase 3 — submission-svc (intake, files, pre-consult, dashboard)
Submission aggregate schema (submissions, revisions, files, pre-consult, service-local event log). Submission CRUD API. Direct-to-GCS upload via V4-signed URLs (request-upload / confirm handshake). Pre-consultation checklist with per-item rules. Dashboard read endpoints with metrics.
Output: PSPs can submit; officers can review pre-consult; dashboard reflects state.
Phase 4 — workflow-svc + Temporal
Temporal client + worker bootstrap on task queue siss-km. Implement
KMSubmissionWorkflow exactly per spec §6.1 (5 stages, parallel
department branches, SLA reminder child workflow). Human-task API
(GET /v1/tasks?assignee=me, POST /v1/tasks/{id}/complete). Replay
tests gating every workflow code change.
Output: end-to-end orchestration, replayable history, SLA timers.
Phase 5 — ai-svc (extraction, RAG, HITL, drafts)
Document ingestion pipeline (PDF via Document AI, DWG via ezdxf, Borang via templated extraction). SIRP rule corpus + Vertex Matching Engine indexer / retriever. Compliance-verdict prompt with schema-validated output and eval harness (CI gates on F1, accuracy, malformed-output rate). HITL review API. Kertas Perakuan + Surat Sokongan draft generation.
Output: AI produces auditable, human-reviewable compliance reports and certificate drafts.
Phase 6 — signing-svc + certificate issuance
PAdES signing via pyHanko with Cloud KMS-backed signer. RFC 3161 TSA
client. Certificate chain from Secret Manager. Endpoints for multi-signer
perakuan, SIGL issuance, and public verification. Step-up auth enforced
on perakuan.sign.
Output: signed, timestamped, verifiable Kertas Perakuan and SIGL.
Phase 7 — Frontend (PSP portal + Officer console)
OpenAPI → typed TS client generation in CI. SPA shell with Firebase JS SDK auth against Identity Platform, role-gated routes. PSP portal: submissions list, new-submission wizard with direct-to-GCS upload, detail page, comment response. Officer console: dashboard, submission review (HITL), task inbox, Kertas Perakuan signing UX.
Output: complete PSP and officer flows end-to-end.
Phase 8 — Cross-cutting verification
End-to-end workflow test (docker-compose happy path). Pact contract tests between FE ↔ BE and between services. k6 load tests (200 concurrent uploads, 50 concurrent dashboard reads, workflow throughput). Security checks (trivy, tfsec, gitleaks, nightly ZAP baseline). M2 readiness checklist against the Release Gate Milestone CSV.
Output: M2 sign-off report with every release-gate criterion marked green.
Execution modes¶
The plan can run in two modes:
A fresh subagent per task, with review between tasks. Fastest feedback, easiest to parallelise independent tasks (notification-svc, submission-svc, the later AI phases).
Executed in-session using superpowers:executing-plans, with manual
checkpoints between tasks.
Key decisions carried into M2¶
- Monorepo (pnpm + uv) for unified dependency management and shared libs.
- Real dependencies in tests — no mocks for AlloyDB, Pub/Sub, Redis, Temporal.
- Direct-to-GCS uploads — large files never enter FastAPI.
- AlloyDB per service + RLS — tenant / department scoping at DB level.
- Provisional trust anchor — interim self-signed org certs for M2 dev / UAT; CA upgrade before production is a milestone gate.
Authoritative source
Anything this page and the full plan disagree on — the full plan at
docs/superpowers/plans/2026-04-13-siss-m2-km-digital-backbone.md wins.