Core Module — Sprint & Scrum Board
Daily owner-based timetable, dependencies, feature milestones, QA evidence and conditional release checklist.
Overall team work progress
All assigned work, across all three sprints and working days.
Shared team progress
Everyone who opens this link sees the same board. When anyone changes a status or types a pending reason, it is saved to Cloudflare and appears on every other laptop within a few seconds — no setup needed.
If the internet drops, your edits stay on this laptop and are sent automatically when you’re back online. Two people can work at the same time: each task is saved separately, so one person’s update never wipes out another’s.
Sprint-wise execution
Day-wise delivery calendar
Select a day to see its individual time slots, or use the sprint filter for an entire sprint.
Time-wise task board
Daily time slots are shown in IST. Lunch: 13:00–14:00; the 16:30–19:00 block includes daily progress update, evidence and handoff. Status and pending reasons are shared live with the whole team through Cloudflare. Export task CSV is an additional backup.
| Task ID | Date / Time | Assignee | Assigned work | Function | Status | Pending reason / blocker details |
|---|
Dependencies, blockers and go/no-go gates
The requirement and architecture documents identify the following unresolved items. Do not label features “production complete” while their input or verification is missing.
Approve initial UI inventory and API schemas; test PostgreSQL 16 migrations and tenant RLS. Decide owner for pending architecture questions.
Master-data CRUD + identity vertical slice, tenant isolation tests, first regression cycle, contract freeze.
B1 broker choice; B4 canonical 12 request types; B5 credential retirement dates/session default; B6 plan tier names and Stores mapping; B8 P&M equipment 15→4 mapping. Pending decisions restrict acceptance.
Security findings triaged, load baseline recorded, backup/restore and rollback rehearsed, UAT signed. Unresolved critical defects require no-go.
Only deploy to approved pilot/production environment after gates pass; otherwise release staging demo and publish blocker/repair report.
RTO/RPO targets, full event catalogue, retry parameters, session limit, cross-module contract changes, legal/privacy decisions and mismatch between §16 vs §18 change counts.
Scrum cadence & QA strategy
Vishnu and Saraswathi share completed work, today's commitments, risks, and blocked decisions. This is a 15-minute coordination period at the start of the first task block.
Confirm scope, acceptance criteria, dependencies, test data and next delivery slices. Plan during the first work block.
Demonstrate working functions, attach API/UI test results, classify defects, rerun smoke/regression and capture approval.
Review decision log and exit checklist, capture lessons, provide release notes and owner handover.
Testing ownership
Mr Vishnu performs frontend manual testing (UI smoke, forms, accessibility, integration and regression) alongside frontend development. Ms Saraswathi performs backend development plus manual and automated QA. Testing her own code does not replace independent peer review or business acceptance: arrange a product-owner review and optional independent security check before external rollout. Test categories: positive/negative CRUD, RLS/tenant leakage, RBAC/step-up, passkeys, approvals, event idempotency/order, UI responsiveness, WCAG smoke, API load, cache/search isolation, rollback and recoverability.
Approved stack reference and release handover
| Layer | Technology / rule | Reference and decision note |
|---|---|---|
| Frontend | React + TypeScript. Vite, Tailwind and shadcn/UI are optional UI implementation choices, not mandated by this stack table. | Technology rows, module documents 01–05 |
| Backend | Node.js + Express + TypeScript. | Technology rows, module documents 01–05 |
| Database | PostgreSQL 16 (16.15 used for validation); one database per module: vq_core, vq_hrms, vq_pm, vq_stores, vq_pms. | ADR-01; DDL validation notes |
| Database access | node-postgres (pg), one pool per database; generated TypeScript types using kysely-codegen or pg-to-ts. No Drizzle ORM dependency. | Section 13 of each module document (recommendation, not mandatory decision) |
| Migrations & roles | Version-controlled SQL bootstrap and schema scripts, executed under a dedicated per-module migrator role. Do not use application credentials for migrations. | vq_*_00bootstrap.sql and vq_*_01_schema.sql companion files |
| Password handling | Argon2id for password-based / legacy migration paths. PMS Django-format Argon2id hashes remain valid; primary Core access should follow the approved passkey identity policy. Never create plaintext passwords. | Core §4, security sections and backfill plan |
| Secrets | Managed secret store; no role passwords or tokens committed to source. AWS Secrets Manager is a deployment option. | Security sections of modules 01–05 |
| Files | Central document service backed by object storage (ADR-11); PMS keeps bytea storage in phase 1. AWS S3 is an object-storage option, not independently required. | ADR-11 / CORE-10 / PMS phase-1 exception |
| Encryption & backup | Encryption at rest; TLS on every connection; PostgreSQL point-in-time recovery (PITR) 7 days; daily snapshots retained for 35 days. | Module security sections |
| Messaging | Transactional PostgreSQL outbox + relay. LISTEN/NOTIFY with polling fallback is the selected initial approach. Keep Publisher interface and event idempotency; B1 broker decision owner remains unassigned. | Architecture v2 §6.5; user's updated decision |
| Cache & search | Tenant-scoped PostgreSQL search as baseline. Cache provider and expiry policy require separate approval; Redis/ElastiCache is not a confirmed platform requirement. | Proposed implementation choice |
| Cloud & CI/CD | Cloudflare Pages and Cloudflare DNS / TLS / WAF for frontend and edge; AWS-hosted Node.js API and PostgreSQL; automated CI/CD, logging and rollback. ECS/Fargate, ALB, RDS and GitHub Actions are proposed deployment choices. | AWS + Cloudflare deployment plan; not mandated by uploaded Core architecture |
Verify per-tenant RLS, passkey authentication, session handling, Argon2id legacy verification where relevant, least-privilege migrator, TLS, secret storage, audit redaction, PITR and snapshots.
Tagged React and API source, tested SQL scripts and role grants, generated DB types, OpenAPI contract, relay/polling tests, manual and automation results, UAT approval, rollback runbook and blocker list.