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.

Scope change pending reconciliation

This page and the underlying M2 plan file pre-date the CityOS / GT Console reframe. core-svc's identity and RBAC scope has moved to GT Console integration; the service is now a slim decision broker, not an identity / RBAC owner. The underlying plan file will be reconciled in a separate pass — treat this page's Phase 1 description as superseded by the architecture pages until then.

What "done" looks like¶

A working end-to-end submission and approval platform with:

SSO and module-level RBAC via GT Console (OIDC through 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 (GT Console broker, object-level policy, audit)

Pre-reframe scope in parentheses

The original M2 plan scoped Phase 1 as a self-contained identity broker and policy store. After the CityOS / GT Console reframe, identity, tenants, and module-level RBAC move to GT Console. This description reflects the reframed scope; see the architecture pages for the current source of truth.

GT Console client (HTTP, mTLS). Policy-decision cache (Redis) invalidated by gtc.role_assignment.changed. Object-level policy resolver (department scope, sign authority, step-up gates). SISS audit stream fan-in into Pub/Sub. GT Console event consumer for role / subscription / tenant lifecycle events. Helm + Terraform deployment via ArgoCD.

Output: every other SISS service can fetch authoritative module-level decisions from GT Console and enforce SISS-specific object-level policy.

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:

Subagent-driven (recommended)Inline execution

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.