Contents
- 1. Executive summary
- 2. Blockers and decisions needed
- 3. Proposed meeting agenda
- 4. What this pack is (and is not)
- 5. Delivery sequence vs build centre of gravity
- 6. What has been delivered
- 7. Demo estate (Vercel + Neon)
- 8. Capability status snapshot
- 9. Architecture and SoR posture
- 10. Repository estate and verification
- 11. Proposed next week and asks
- 12. Sources and status language
1. Executive summary
This is the first Raisd Campus weekly progress pack. Because the group has not yet run a
recurring weekly cadence, this report covers the full baseline from the 18 September
working-group meeting through the 3 October cut — not a narrow seven-day delta. Content reflects the
campus mains pulled on 3 October 2026 (control-plane f8d54d1, design-system v0.6.1,
student/applicant portals, portal-api, docs, db-admin).
The estate is now a working Demo platform: four portal webs on Vercel (Student and Applicant with real UI; Lecturer/Staff placeholders), a dedicated Portal API service with Neon Postgres Schema v3 persistence for Demo records, a read-only DB admin, a published shared design system through 0.6.1, central AI knowledge base + SDD catalogue, LMS architecture/feature pages (Q37 Option 1), and LUCT CMS inventories for Cyberjaya, Sierra Leone, and Botswana.
Product priority remains unchanged: Cyberjaya first · Admissions before semester registration · core mobile at launch · existing CMS as this-phase system of record (ADR-1, Aslam 23 Sep 2026). Live count remains 0. Demo persistence on Neon is not CMS-acknowledged Live. CAP-53 callable surface, named owners, kickoff, and auth model for campus identity are still open.
(Demo ≠ done)
published package
Neon + policy tables
+ Neon + DB admin
(92 files, latest gate)
(M2 surface)
CBJ · SL · BW
CMS Live access
2. Blockers and decisions needed
Absorbs SDD-10 (including CS-01–CS-13 / Q37 decisions of 1 Oct) and the sequence tension in SDD-03 / SDD-13. Closing D1–D4 unblocks measurable Live progress on M2.
2.1 Blockers
| # | Blocker | What is stuck | Status |
|---|---|---|---|
| B1 | No named next-action owners | Checklist next-action owners and target weeks remain TBC. Demo work cannot graduate to Live without accountable departments. | Blocked Working group |
| B2 | Kickoff and backend commitment TBC | Timeline tab has no agreed calendar. Milestone targets cannot be planned as dates. | Blocked Working group |
| B3 | CAP-53 callable CMS surface | Dumps inventoried; Portal API Demo uses stub CMS mode. HTTP surface, credentials path, and owning team for Live writes still TBC. | Blocked Q1 / Q2 / Q26 |
| B4 | Campus auth model undecided | Demo student-number + password login exists. CMS password vs SSO vs both for applicants/students (Q3) still open for Live. | Blocked Q3 |
| B5 | Durable file store undecided | Evidence, assignments, payment proofs need a durable store for Live (Q5). Current portals use session/metadata Demo uploads. | Blocked Q5 |
| B6 | Per-campus policy confirmation | Schema v3 Demo seeds university defaults. CS-01–CS-11 must be confirmed per campus before that campus’s Live features. | Policy gate Q29–Q35 |
2.2 Decisions needed this meeting (detail)
These five decisions are the working-group agenda items that unblock Live work on Admissions (M2). Each decision states why it matters now, the options, the recommended default for discussion, and what happens if we leave it open. Record the outcome in the checklist Timeline tab and SDD-10 decision log in the same meeting if possible.
D1 — Delivery sequence: keep admissions-first?
Why now. Product priority (7 Sep) is Cyberjaya first and Admissions before semester registration. Engineering reality has been the opposite for weeks: Student Demo is deepest (M3 depth). Applicant Demo UI has now started and is deployed — so the sequence question is no longer theoretical. We must either reconfirm M2 as P0 or explicitly change product priority.
| Option | Meaning | Consequence |
|---|---|---|
| (a) Reconfirm admissions-first Recommended | Applicant journeys + CAP-53 admissions slice are P0. Student Demo continues only for shared design-system reuse, gate hygiene, and blockers that Applicant also needs. | Build aligns with M2 Live path; student polish is deprioritised. |
| (b) Promote student Demo as near-term showpiece | Accept that stakeholder walkthroughs centre on enrolled-student UX; Admissions Live slips until CAP-53/Applicant catch up. | Must update the sheet / SDD sequence so the group is not measuring against admissions-first while funding M3 depth. |
D2 — CAP-53 / old CMS API ownership and access
Why now. CAP-53 (Portal API ↔ existing Cyberjaya CMS) is the only shared item marked Partial and
gates every Live student/applicant write. We have dump inventories and api_student_* / desk evidence,
but no named owner, no granted callable HTTP surface, and Portal API still runs cms.mode = stub
with Neon Demo persistence. Without D2, Demo forever.
| Option | Meaning | Consequence |
|---|---|---|
| (a) Name owner + grant access this week Recommended | Assign a backend / old-CMS owner. Grant read (then controlled write) access for an admissions slice: apply → evidence → offer → enrol mapping to existing SPs/tables. | Engineering can start a real CAP-53 spike with evidence, not guesses. |
| (b) Time-box a paired spike | Frontend + CMS pair for 3–5 days to document callable methods, auth, and first write path; owner named by end of spike. | Faster discovery if a single owner is not ready, but still needs access credentials. |
Related open questions: Q1 (stack/access), Q2 (CMS owner / callable surface), Q26 (map api_student_* / portal_r_student_* to Portal API methods).
D3 — Cyberjaya Live login path (CAP-01)
Why now. Student Demo already has student-number + password login (gitignored credentials; Portal API validates). That is not campus identity. Applicants and enrolled students need an agreed Live path before CAP-01 can leave Demo/Placeholder. Choice also drives Portal API session design, password reset ownership, and whether applicants share the same IdP as students/staff.
| Option | Meaning | Best fit |
|---|---|---|
| (a) CMS credentials via Portal API | Portal API authenticates against existing CMS user store / login rules; issues portal session only after CMS accepts. | Fastest path if CMS login is already the campus source of truth. |
| (b) Campus SSO with CMS mapping | External IdP (SSO); Portal API maps identity to CMS person/student/staff records before authorising. | Better long-term UX; needs IdP owner + attribute mapping + fallback for applicants who are not yet “users”. |
| (c) Both, with a clear primary Likely | e.g. applicants use CMS/account-create path; enrolled students/staff use SSO (or the reverse). Document primary per audience. | Matches mixed campus reality; must avoid two conflicting passwords without a policy. |
D4 — Named department owners and kickoff week
Why now. All checklist next-action owners and target weeks remain TBC. Schema v3 also needs per-campus policy confirmation (CS-01–CS-11) from Registry / Bursary / IT before Live features. Without names and a kickoff week, weekly meetings have no calendar and “Needs checking” never closes.
| Seat to name | What they own for M1–M2 |
|---|---|
| Registry | Admissions rules, offer/enrolment decisions, academic status policy (CS-01–CS-04), CAP-05/06/07 staff path on old CMS |
| Faculty | Programme/module rules that affect registration later; training readiness toward M4 |
| Bursary / Finance | Fee items, proof-to-allocation, refund/adjustment policy (CS-08–CS-10), bank instructions (Q19) |
| QA / AQA | Acceptance criteria language; what “Live” means for campus pilot |
| Marketing | Announcements / recruitment copy only — does not issue offers (CAP-16) |
| IT / old CMS | CAP-53 access, environments, backups (CAP-38), LoginActive / RBAC mapping (CS-11) |
Also decide: a kickoff week (even if later milestone end dates stay TBC). One calendar anchor is enough to start M1/M2 tracking.
D5 — Durable file store for Live evidence
Why now. Admissions evidence (CAP-03), profile documents (CAP-09), assignment files (CAP-20), and payment proofs (CAP-46) all require a store staff workflows can open. Current portals keep session/metadata Demo uploads only. Choosing the store early avoids rebuilding Applicant upload UX twice.
| Option | Meaning | Trade-off |
|---|---|---|
| (a) Reuse existing CMS document trees / stdfile paths Recommended default | Portal API writes files through the same channels staff already use in the old CMS. | Least migration risk; constrained by legacy layout and access rules; needs owner confirm of live paths (Q25). |
| (b) Object store + CMS metadata linkage | New blob store for bytes; CMS (or Portal API) holds metadata and ACL. | Cleaner modern path; more infra + dual-read during transition; still needs CMS visibility for staff desks. |
| (c) Defer Live files; Demo metadata until M3 | Keep Applicant/Student uploads as Demo-only until after core journeys exist. | Unblocks screens faster but blocks M2 Live for any journey that legally needs evidence on file. |
2.3 Decisions already recorded
| Date | Decision | By |
|---|---|---|
| 7 Sep 2026 | Cyberjaya first; admissions before registration; core mobile; keep existing CMS; five portal groups | Product owner (sheet) |
| 22–23 Sep 2026 | Central docs/ai/ SSOT; student docs extracted; ADR-1 SoR + progressive unified CMS |
Faid / Aslam / Engineering |
| 28–29 Sep 2026 | Demo sign-in (student number + password); Vercel + Neon PoC estate deployed (not Live architecture) | Faid request / Engineering |
| 1 Oct 2026 | Canonical Schema v3 with university-default → campus-override policy hierarchy; CS-01–CS-11 are Live readiness, not schema blockers | Architecture + Engineering |
| 1 Oct 2026 | Q37 Option 1 — publish Raisd LMS pages from CAP + F01–F37 (no PPA comparison in this set) | Iman / Product architecture |
| 1–2 Oct 2026 | Design system releases through 0.6.1; Applicant Demo UI preview; campus repo sync | Engineering |
3. Proposed meeting agenda
| # | Topic | Time hint | Outcome |
|---|---|---|---|
| 01 | Demo vs Live language + PoC disclaimer | 5 min | Shared status words |
| 02 | Executive KPIs and sequence (M2 vs M3) | 5 min | Align D1 |
| 03 | Walkthrough: Student Demo + Applicant Demo (optional) | 12 min | UI awareness, not acceptance |
| 04 | Portal API / Neon Schema v3 + Vercel estate | 8 min | Understand Demo persistence limits |
| 05 | LMS pages + CMS hubs + ADR-1 reuse posture | 5 min | No accidental rebuild of desks |
| 06 | Blockers B1–B6 and decisions D1–D5 | 15 min | Named owners / votes |
| 07 | Next-week plan + Q&A | 5 min | Agreed focus |
Hard stop suggestion: 55 minutes. If D1–D4 are still open at minute 30, defer deep feature demos.
4. What this pack is (and is not)
WE WILL COVER
- Full baseline from WG start to 3 Oct (first weekly)
- Demo / Partial / Live language from the checklist glossary
- Student + Applicant Demo progress and design system 0.6.1
- Portal API + Neon Schema v3 + Vercel PoC endpoints
- LMS docs (Q37), CMS inventories, ADR-1 SoR
- Explicit decisions required to unblock Live M2
WE WILL NOT CLAIM
- That any capability is Live or campus-accepted
- That Vercel/Neon is production architecture (UltaHost/k3s remains SDD-12)
- That Neon Demo writes are CMS-acknowledged
- That Schema v3 university defaults are signed LUCT policy
- That Botswana / Sierra Leone inventories imply next Live campus
- Native-app delivery (core mobile = phone-friendly web)
5. Delivery sequence vs build centre of gravity
Milestone order follows the admissions-first decision. Bars below are order only; every target week on the sheet remains TBC.
and integration
launch
portal
pilot acceptance
remaining CMS
| Milestone | Target | Must work | Engineering now (3 Oct) |
|---|---|---|---|
| M1 Confirm rules & integration | TBC | Rules, owners, old-CMS access, operating responsibilities | Schema policy framework + CMS inventories advanced; owners/access still open |
| M2 Admissions launch | TBC | Apply → evidence → offer → enrol on real records | Applicant Demo UI started · CAP-53 still stub · Staff admissions prefer old CMS |
| M3 Core student portal | TBC | Learning, timetable, assignments, fees, registration + lecturer/staff paths | Student deep Demo · Neon-backed session state · lecturer/staff paths Not started |
| M4 Cyberjaya pilot acceptance | TBC | Integrated pilot, training, campus accept | Operating readiness only (CAP-41 Not started) |
| M5 Expansion & remaining CMS | TBC | Other campuses + progressive consolidation on verified gaps | SL/BW hubs + LMS research published; do not pull ahead of M2 Live |
5.1 Frontend started vs not started (sheet snapshot basis)
Filled = frontend started on Faid sheet detailed tab (SDD-13, 19 Sep download; status cells unchanged at last sheet pull). Engineering has since started Applicant Demo UI — sheet rows may lag; Live remains 0 either way.
6. What has been delivered (baseline to 3 Oct)
6.1 Product baseline and knowledge system
- SDD catalogue SDD-00–15 with nomenclature anchors; open questions extended for Schema CS-01–CS-13 and LMS Q37.
- Central AI knowledge base at
control-plane/docs/ai/— agents across sibling repos point here as SSOT. - Published docs site — architecture, ERD (Schema v3), LMS hubs, CMS inventories, OpenAPI HTML, PoC page, design-system catalogue, site search.
- Stack config
repositories.yaml+ shared portal CI/CD template; git/CI status tooling.
6.2 Student portal (Demo — deepest Raisd UI)
- Cyberjaya enrolled-student journeys: Academic, Profile, Online Forms, Immigration, Finance, Announcements, Policies, Services, Community.
- Demo sign-in + logout (Faid, 28–29 Sep): student number + password; credentials from gitignored control-plane file; HTTP login via Portal API.
- Responsive 375–1440px; shared portal shell from design system; Chromium + WebKit gates.
- Latest recorded gate: 727 unit tests / 92 files; ~271 Chromium / 35 WebKit with intentional skips; production build + bundle budgets.
- Pins
@raisd-campus/design-system@0.6.1. Deployed Demo:https://raisd-student-portal.vercel.app.
6.3 Applicant portal (Demo — M2 surface now started)
- Applicant UI preview with application checklist, fee/review summaries, Transfer Proof disclosure, reviewer messages (session-only).
- Uses shared design system 0.6.1 (fields, conversation, survey/accordion patterns).
- CI/CD deploys
maintohttps://raisd-applicant-portal.vercel.app. - Still Demo — no Live CMS admissions writes; automated Applicant test suite not yet established as a full gate.
6.4 Design system
- Published through v0.6.1 (GitHub Packages): portal shell, survey layout, conversation/chat presentation, standard 36px fields, record summary cards, and related patterns.
- Catalogue HTML + captures (≈89) validated; public mirror PR path documented for portal-api-docs.
- Change-triggered catalogue / Docs-Impact rules for agents and CI.
6.5 Portal API + Schema v3 Demo
- Dedicated
raisd-campus/portal-apiservice (Fastify); OpenAPI expanded in control-plane. - Schema v3 Demo: campus policy collections, university-default seeds, projections + SQL reporting views, audit events,
/v1/meta.schemaVersion, LMS meta surface. - Demo records persist in Neon across instances/cold starts;
cms.mode = stub— no Live CMS writes. - Demo passwords required on login; CI uses throwaway credentials.
6.6 LMS documentation (Q37 Option 1)
- Published:
lms.html,lms-architecture.html,lms-features.htmlfrom CAP + F01–F37. - Agent knowledge:
docs/ai/architecture/lms.md+lms-schema.md. - Student Materials alone is not an LMS (BASE-44). No PPA LMS comparison in this generate set.
6.7 LUCT / existing CMS inventories
| Campus / dump | What landed | Use in this phase |
|---|---|---|
| Cyberjaya | Source + DB dump inventoried; CAP matrix (SDD-14); E2E hub; Obsidian FSD knowledge | Primary SoR for M1–M4; reuse staff desks |
| Sierra Leone | Structure dump + E2E hub on Pages | Expansion pattern — not next Live campus |
| Botswana | Inventory, ERD/DFD, E2E hub, DTEF / TEF.gov.bw sync | Expansion / scholarship evidence — not next Live campus |
7. Demo estate (Vercel + Neon) — not production
PoC path deployed 28–29 September 2026. Not an ADR. Production remains UltaHost + k3s; existing CMS stays SoR for Live writes (ADR-1 / SDD-12).
| Target | URL / location | State |
|---|---|---|
| Student portal | https://raisd-student-portal.vercel.app |
Demo UI · CI/CD on main |
| Applicant portal | https://raisd-applicant-portal.vercel.app |
Demo UI · CI/CD on main |
| Lecturer portal | https://raisd-lecturer-portal.vercel.app |
Coming soon placeholder |
| Staff portal | https://raisd-staff-portal.vercel.app |
Coming soon placeholder |
| Portal API | https://raisd-portal-api.vercel.app |
Demo API · manual deploy; CI smoke checks |
| Neon Postgres | neondb · aws-ap-southeast-1 |
Schema v3 Demo records |
| DB admin | https://raisd-db-admin.vercel.app (team) |
Read-only browser |
| Public docs | https://raisd-campus.github.io/portal-api-docs/ |
OpenAPI · diagrams · PoC page |
control-plane/.credentials/. Never present these URLs as Live campus systems.
8. Capability status snapshot
Sheet columns from SDD-13 (19 Sep). Engineering notes reflect 3 Oct cut where they diverge. Live = 0 everywhere.
| Portal / surface | Sheet started | Live | Engineering read (3 Oct) |
|---|---|---|---|
| Applicant | 0 of 7 | 0 | Demo UI started — update sheet |
| Student | 31 of 40 | 0 | Deep Demo + Neon |
| Lecturer | 0 of 18 | 0 | Placeholder deploy only |
| Admin / staff | 0 of 37 | 0 | Prefer old CMS desks |
| Shared system | CAP-53 Partial | 0 | Portal API Demo / stub CMS |
8.1 M2 critical path
| ID | Surface | Task | Now |
|---|---|---|---|
| CAP-02 / 03 / 07 / 55 | Applicant | Apply, evidence, track/offer/accept, declarations | Demo UI in progress — not Live |
| CAP-01 | Applicant / Student | Sign-in and account | Student Demo password login · Applicant Demo · campus identity TBC |
| CAP-03/05/06/07 | Staff | Review evidence, quals, offer, first enrolment | Not started as Raisd app — use old CMS unless gap |
| CAP-53 | Shared | Portal API ↔ existing CMS | Partial / stub — gates Live |
| CAP-35 / 36 | Applicant | Accessible forms · mobile shell | Responsive work in progress via shared DS — not Live acceptance |
9. Architecture and SoR posture
| Horizon | What we deliver | System of record |
|---|---|---|
| This phase (M1–M4) | Modern portal UX via Portal API; staff ops on verified old desks unless gap proven | Existing Cyberjaya CMS |
| Demo PoC (now) | Walkable portals + API + Schema v3 on Vercel/Neon | Neon Demo only — not campus SoR |
| Longer term (M5+) | Campus expansion + progressive consolidation toward one-stop CMS | Migrate domain-by-domain after verified gap + migration strategy |
10. Repository estate and verification
| Repository | Owns | Baseline state (3 Oct pull) |
|---|---|---|
control-plane | SSOT docs, SDD, OpenAPI, stack tooling | Active SSOT · f8d54d1 |
student-portal | Enrolled-student web | Deep Demo · DS 0.6.1 · Vercel |
applicant-portal | Online registration | Demo UI started · Vercel |
portal-api | Only HTTP surface portals call | Neon Schema v3 · stub CMS |
design-system | Shared tokens/components | v0.6.1 published |
portal-api-docs | Public OpenAPI + diagram mirrors | Publishing |
db-admin | Read-only Neon browser | Deployed (team) |
lecturer-portal / staff-portal | Role webs | Placeholder + CI/CD |
10.1 Quality gates (latest recorded)
- Student: lint, 727 unit tests / 92 files, production build/isolation, bundle budgets, Chromium/WebKit matrices (some known date-dependent fixture failures on full runs; focused retries green).
- Design system: typecheck, unit + consumer fixture + browser checks per release; package published via CI.
- Portal API: CI smoke (health, meta, login, wrong password 401, portal call, logout revoke).
- Applicant: TypeScript/build + manual responsive review; automated suite still thin vs Student.
- Physical iPhone confirmation remains the final device check for some shell behaviours.
11. Proposed next week and asks
| Priority | Work | Why |
|---|---|---|
| P0 | Close D1–D4 in this meeting; write owners into the checklist Timeline tab | Unblocks calendar and accountability |
| P0 | CAP-53 admissions slice spike: map callable CMS surface → Portal API methods | Only path from Neon Demo to Live writes |
| P1 | Continue Applicant Demo toward CAP-02/03/07 completeness; add Applicant automated smoke | Aligns build with M2 |
| P1 | Auth decision write-up (CMS vs SSO) with Cyberjaya constraints | Closes B4 / Q3 |
| P2 | Refresh Faid sheet Applicant rows to Demo where engineering has started | Stops false “0 of 7” narrative |
| P2 | Keep student work limited to shared DS reuse / gate hygiene unless D1 changes | Protects sequence |
11.1 Asks of the working group
- Name owners for Registry, Faculty, Bursary, QA, Marketing, IT, and old-CMS API access.
- Reconfirm admissions-first now that Applicant Demo exists (D1).
- Pick a kickoff week even if later milestones stay TBC.
- Grant (or schedule) access to callable CMS APIs/environments for CAP-53.
- Agree file-store posture for evidence (D5).
- Confirm who should receive weekly PDFs / Vercel Demo credentials.
12. Sources and status language
| Source | Role in this pack |
|---|---|
| Faid Daily Checklist / SDD-13 | Sheet FE start counts; Live = 0 |
SDD-00…15 / docs/ai/ | Architecture, milestones, CAP catalogue, open questions |
| Student + Applicant handoff / README | Verification and Demo depth |
vercel-neon-poc.md | Demo estate endpoints and limits |
| Canonical schema LUCT readiness | Schema v3 + CS-01–CS-13 |
| Aslam WG chat 23 Sep 2026 | ADR-1 SoR confirmation |
Pulled raisd-campus/* mains 3 Oct 2026 | Engineering cut for this PDF |
12.1 Status glossary
| Term | Meaning |
|---|---|
| Demo | UI/API on sample or temporary/Neon Demo data; no Live CMS ack; no campus acceptance |
| Placeholder | Screen or control exists; intended action does not |
| Partial | Some of the capability exists; key workflow or acceptance missing |
| Live | Accepted, real data, access controls, accountable owner |
| Needs checking | Not verified with owning department or old-CMS owner |
| PoC | Vercel/Neon demonstration path — not production architecture |
Pack path: docs/reports/weekly-progress-2026-10-03/.
Subsequent weeks should keep this layout and lead with a week-over-week delta.