Scola V1 Production Baseline — E2E Workflow Catalog

Document control

Item	Value
Purpose	Product-level catalog of the end-to-end journeys that must be intentionally accepted, secured, and tested before the Scola V1 Production Baseline can be frozen
Scope	W00 platform prerequisite and W01–W20 product-workflow candidates
Mode / workspace	Server development; /home/scola/odoo
Frontend baseline inspected	scola-fe-v2 develop@68b77d88f78b3d32f0ede3a54b665e067b014062
Backend baseline inspected	custom_addons_scola/gcgscola main@2ff6ac7cb41810bbc3b66821cdad004b52d1658a
Evidence method	Static trace from canonical route/component to service, controller/model, state effect, and existing reconnaissance/planning; no runtime or database mutation was performed
Product-contract source	docs/release-readiness/01-product-contract.md:242-262
Authorization invariant	Effective access must satisfy capability, record scope, tenant/company/school scope, domain ownership, state policy, and audit; frontend visibility is not authority (docs/release-readiness/04-authorization-readiness.md:20-31,73-88)
Status	Proposed auditable catalog; not product approval and not proof of E2E readiness

This file does not turn code presence into approved behavior. “Canonical” below means the proposed single route/page identity for test traceability; aliases and shared components are not counted as separate workflows. A completion criterion is a release-test target only when its business owner has approved the related state and ownership decisions.

1. Evidence and confidence rules

Label	Meaning in this catalog
Confirmed from code	The named route, API, field/action, state, or side effect is directly visible at the cited baseline. It still needs runtime verification.
Inferred from code	Multiple code paths imply an ordering or relationship, but there is no single authoritative workflow contract.
Requires runtime verification	Static code is insufficient to prove permissions, tenant isolation, transactionality, integration propagation, or the served build.
Requires product decision	Ownership, state meaning, approval, recovery, privacy, or supported-surface policy is not approved by code.
Blocked by defect	A known defect or security gap prevents the workflow from being certified or exposed.
Not in supported surface	The route/component may exist, but V1 must hide or remove it unless its classification changes through DEC-001.

All supported mutations inherit AUTH-001–AUTH-014. In particular, active role is not yet a proven enforcement boundary, assignment scope is not reusable and mandatory, approval/post/configure separation is incomplete, and menu → route → action → API parity is not guaranteed (docs/release-readiness/04-authorization-readiness.md:43-55).

2. Contract and dependency normalization

2.1 Workflow status ledger

Contract status	Workflows	Release treatment
Core V1 (platform prerequisite)	W00	Core contract status; must pass before any product journey can be certified and is not a separately sold commercial workflow
Core V1	W01, W02, W16	Mandatory baseline domain journeys
Controlled Pilot	W05, W12, W19	May run only under the approved pilot boundary and explicit entry/exit criteria
Optional Supported	W03, W04, W06, W07, W09, W10, W11, W13, W14, W15, W20	Certified independently for an enabled SKU; disabled packages expose no menu, route, or API promise
Incomplete / Remove from Product Surface	W08	Hide/remove; do not count as a supported E2E journey
Requires Product Decision	W17, W18	Hide internal/operator surface until scope, owner, security, and package decisions close

The ledger is copied exactly from the proposed product contract, not derived from navigation presence (docs/release-readiness/01-product-contract.md:242-262).

2.2 Dependency order

W00 platform/RBAC/package/navigation
 ├─ W16 canonical news publication
 ├─ W01 academic master → timetable/session
 │   └─ W02 student/parent identity and roster
 │       ├─ W05 manual daily attendance (pilot)
 │       │   ├─ W07 report-card inputs (optional downstream bridge)
 │       │   └─ W15 permit/student-affairs effects (optional cross-domain bridge)
 │       ├─ W20 RFID ingestion (optional sibling; shares approved attendance semantics but does not require W05 PASS)
│       ├─ W10 billing (optional)
│       └─ W14 library borrower identity (optional)
 ├─ W06 employee attendance (optional; may feed W09 only through a separately approved bridge)
 ├─ W09 payroll (optional; its authoritative attendance/input source remains a product decision)
└─ W11 finance + W13 inventory → W12 BOS/RKAS procurement pilot

W19 Dapodik pilot ↔ W01/W02 master ownership (decision boundary; no implicit order)
W03 admissions → W02 only when SC-ADM is enabled; manual W02 remains independently core
W04 CBT and W07 assessment/reporting consume W01/W02 assignments and enrollment

The core dependency W00 → W01 → W02 → W05 is supported by the roadmap’s master/session and roster prerequisites (docs/release-readiness/10-implementation-roadmap.md:21-27,126-177). W16 is core but does not statically require W01/W02, so it can be certified in parallel after W00. W19 exposes direct sync endpoints that can mutate the same masters; its source-of-truth decision must precede integration rather than being silently placed before or after W01/W02.

3. Core V1 platform prerequisite

W00 — Login, session, active role, application and navigation

Dimension	Catalog entry
Contract / business outcome	Core V1 (platform prerequisite). A fresh supported-role user authenticates, receives a server-owned session and effective active-role/package context, lands in the one canonical application shell/home, navigates only to authorized supported tasks, can switch only among assigned roles, and logs out with the session invalidated. This is not a separately sold commercial workflow.
Actors	Every fresh supported role; Identity/RBAC administrator for provisioning; Platform and Security owners. Superadmin is excluded from normal positive journeys.
Prerequisites / starting state	Golden Tenant and package entitlements exist; a fresh user has explicit assigned roles, one valid active role, company/school scope, and no legacy privilege residue. Starting state is anonymous for login, or an authenticated server session for refresh/switch/logout. The exact active-role semantics remain Requires product decision DEC-002.
Canonical pages/routes	/login and /apps; then one canonical role home from the approved role/app catalog. Route construction is centralized in src/router/index.js:1-15; public/auth and app-selector routes are src/router/sharedExperienceRoutes.js:14-22,263-271. Role-specific aliases must redirect and are not separate pages.
API/service chain	FE login/session/logout: src/services/auth/auth.service.js:9-42; store role switch: src/stores/auth.store.js:600-666. The shared client prefixes the relative logout path with /api (src/api/apiServices.js:35-42,195-221), so /auth/logout resolves to the controller’s /api/auth/logout. Backend login/profile/session-probe/logout/session/switch-role: ../custom_addons_scola/gcgscola/scola_core/controllers/auth.py:291-518. Protected-route registry resolver: ../custom_addons_scola/gcgscola/scola_platform_support/api_route_access.py:19-20,482-528. Route resolution is Confirmed from code; logout invalidation behavior still requires runtime evidence.
Steps and state transitions	Anonymous → login request → authenticated session with actor/company/roles/capabilities → canonical home; session refresh preserves the same server-owned context; assigned role A → switch request → active role B with recalculated effective authority; logout → anonymous and protected routes/API denied. The FE guard’s role, permission, portal-boundary, and home rules are visible in src/router/routerGuardPolicy.js:25-143,148-181,206-287; backend enforcement parity is not proven by that guard.
Downstream / completion criteria	Completion requires: every fresh supported role lands on an existing authorized home; enabled packages expose only their approved leaves; each visible leaf loads; unsupported leaves are absent; direct hidden-route/API access is denied; role switch removes the previous role’s exclusive capability; logout and expired session deny subsequent calls. W00 outputs the trusted identity/tenant/role context consumed by every later workflow.
Correction, reversal, and recovery	Invalid credentials return a safe denial; expired sessions return to login without exposing stale data; invalid home uses an approved safe fallback; failed switch leaves the previous context intact; logout is idempotent. Account unlock/password-reset/break-glass are missing from this bounded journey and require separately owned recovery contracts.
Security / privacy / integration	Deny by default; no forged role/company; no capability union after switching; audit principal and acting role; package flag, installed addon, entitlement, menu, route, registry, controller, and record rule must agree. Session/profile payload must expose only necessary identity and scope.
Evidence / readiness	Confirmed from code for route and endpoint presence; Blocked by defect / decision for enforcement and canonical homes: STAB-007, STAB-008, STAB-024, STAB-025, STAB-026, STAB-028, STAB-041 (docs/release-readiness/08-stabilization-backlog.md:48-49,65-69,87). Runtime evidence must cover AUTH-001–AUTH-014 and QG-02–QG-07.

4. Core V1 workflows

W01 — Academic master to timetable/session

Dimension	Catalog entry
Contract / business outcome	Core V1, SC-CORE. Academic Operations creates an internally consistent, tenant-scoped academic structure and a usable timetable/session consumed by teaching, attendance, learning, and reporting. Code confirms the pieces; the end-to-end ownership/locking contract is Inferred from code.
Actors	Academic/curriculum administrator or approved data steward; teacher/student are read-only downstream consumers where supported. Workflow owner proposed in 01: Curriculum/Academic Operations (docs/release-readiness/01-product-contract.md:243). Exact create/edit/archive/delete/assign roles require DEC-003/004/008.
Prerequisites / starting state	W00 passed; company/school exists; timezone and academic-calendar convention approved. Starting state is a tenant with no active period, or approved existing masters that need a timetable. Required master ownership, effective dates, locking, and referenced-delete policy are unresolved.
Canonical pages/routes	/academic-year, /grade-levels, /subjects, /classrooms, /study-groups, /schedule-slots, /teacher-assignments, then /schedule; related class detail/create/list routes share the class domain and aliases are not separate journeys. Route evidence: src/router/academicCoreRoutes.js:3-178.
API/service chain	Academic years, grade levels, subjects, study groups, lesson-hour/profile options: src/services/admin/academics/academicMaster.service.js:10-232 → ../custom_addons_scola/gcgscola/scola_core/controllers/academic_master_api.py:220-2174. Classroom/faculty/student references and session list/count/save/delete: src/services/admin/academics/scheduleClass.service.js:101-168 → ../custom_addons_scola/gcgscola/scola_timetable/controllers/academic_session_api.py:58-165. Generate/auto-generate: ../custom_addons_scola/gcgscola/scola_timetable/controllers/timetable_api.py:113-214.
Steps and state transitions	Approve/create academic year and term → create level/subject/batch or study group/classroom → configure lesson slots → assign teacher/course/class → generate or save sessions → inspect collision/coverage → publish or otherwise make sessions consumable. Current code exposes create/update/archive/delete and session generate/save/delete actions; it does not prove one canonical aggregate state machine or publication/lock semantics.
Downstream / completion criteria	Completion target: one approved in-company master graph produces deterministic, non-overlapping sessions visible to the intended teacher/student and consumable by W02/W05/W04/W07. Academic masters and sessions are prerequisite to attendance, LMS, and reporting (docs/recon/page-relationships.md:16-27). The owner must approve what “active/published/locked” means before this criterion is final.
Correction, reversal, and recovery	Invalid or cross-company references must be rejected atomically; collisions and stale assignments must have actionable errors. Correction may edit/regenerate/delete only under an approved state/effective-date policy and must not orphan downstream records. No safe universal rollback is proven; deletion of referenced masters requires DEC-005/007/008.
Security / privacy / integration	Separate view/create/edit/delete/assign/generate/publish; validate company on every foreign key; teacher sees only assigned sessions; student sees only own enrollment; audit before/after. Date/time boundaries must use the school timezone. Integration tests must prove W02 roster and W05 session consumption without hidden cross-package dependencies.
Evidence / readiness	Confirmed from code for routes/services/APIs; Inferred from code for sequence; Requires product decision/runtime verification for ownership, lock, collision, correction, and propagation. Roadmap units and acceptance are docs/release-readiness/10-implementation-roadmap.md:143-149; QG-05/QG-08–QG-10 apply.

W02 — Student onboarding and identity linkage

Dimension	Catalog entry
Contract / business outcome	Core V1, SC-CORE. Student Administration creates a tenant-safe student identity, assigns the approved academic roster, links only the correct parent/account identities, and makes the student available to downstream services. Manual onboarding is core; bulk import is supported only if its separate gate passes.
Actors	Student/identity administrator; parent-account administrator where separated; student and parent as downstream account holders. Proposed owner: Student Administration (docs/release-readiness/01-product-contract.md:244).
Prerequisites / starting state	W00 and W01 passed; company, academic year, level/batch/class are valid. Starting state may be a new person or an existing person/account candidate. Matching keys, duplicate policy, source of truth, required identity fields, account activation, and parent-link ownership require DEC-008/009.
Canonical pages/routes	/students, /students/create, /students/:id, conditional /students/import; /parents, /parents/create, /parents/:id, /parents/create-user, and /parents/import-relations. Route evidence: src/router/studentDataAdminRoutes.js:3-94. Detail/create aliases using the same domain component are not separate workflows.
API/service chain	Student list/classes/check/save/detail: src/services/admin/student.service.js:4-49 → ../custom_addons_scola/gcgscola/scola_core/controllers/student_admin_api.py:271-428. Parent save/detail/linkage: src/services/admin/parent.service.js:4-54 → ../custom_addons_scola/gcgscola/scola_core/controllers/parent_admin_api.py:292-516. Bulk import uses async create/poll with sync fallback in src/views/AdminViews/StudentDatabase/UploadSiswa.vue:769-835 and backend ../custom_addons_scola/gcgscola/scola_core/controllers/admin_import_api.py:210-246.
Steps and state transitions	Search/check for an existing identity → create or safely update student → assign company and current roster → create/link parent/person/account → optionally provision login → verify role-specific self/child visibility. Bulk path: validate file → start job → poll terminal result → reconcile per-row outcomes; sync fallback is a separate implementation path and must not create different semantics. There is no proven unified “onboarding status” state machine.
Downstream / completion criteria	Completion target: one canonical student/person record, one valid current roster assignment, and approved account/parent linkage; student authenticates to self-scope and parent authenticates only to linked child; the student appears exactly once in W05, W10, W14, W15, LMS/report-card consumers as enabled. Account activation and mandatory parent linkage are Requires product decision.
Correction, reversal, and recovery	Duplicate/match conflicts must stop before mutation or enter an owned reconciliation queue; interrupted/retried import must be idempotent; row errors must be downloadable without leaking other tenants. Unlink, merge, deactivate, roster transfer, and mistaken parent-link reversal require approved, audited recovery. Deletion is not assumed safe.
Security / privacy / integration	View and manage/import capabilities must be distinct; user-supplied company, batch, parent, child, or account IDs require same-tenant validation; PII projection/retention/export must be role/purpose scoped. Parent-child and student-self scope must be backend authoritative.
Evidence / readiness	Confirmed from code for pages and APIs; Inferred from code for onboarding sequence; Blocked by defect for route/action/import guard drift STAB-023 (docs/release-readiness/08-stabilization-backlog.md:64); matching, idempotency, account activation, and propagation Require runtime/business confirmation.

W16 — Canonical news publication

Dimension	Catalog entry
Contract / business outcome	Core V1, SC-CORE / scola_news. An authorized author creates an audience-targeted item, an independent approver approves it where required, and intended readers see one canonical publication during its valid window. Legacy announcement is excluded as a competing writable source.
Actors	Author/editor, approver/publisher, intended student/parent/employee readers; Communications owner. Exact maker-checker exceptions and audience ownership require DEC-004/010.
Prerequisites / starting state	W00 passed; category, audience and any audience target exist; publish window is valid. Starting state is a new draft. Code validates selected fields, but the approved audience/approval matrix and notification SLA are unresolved.
Canonical pages/routes	Admin /admin/news, /admin/news/create, /admin/news/:id/edit, /admin/news/:id; reader /news and /news/detail/:newsId. Route evidence: src/router/communicationAdminRoutes.js:64-98; src/router/sharedExperienceRoutes.js:86-95. Role aliases redirect to these identities; /announcement is legacy, not a second workflow.
API/service chain	Manage endpoints: ../custom_addons_scola/gcgscola/scola_news/controllers/news_manage_api.py:17-172; portal read endpoints: ../custom_addons_scola/gcgscola/scola_news/controllers/news_portal_read_api.py:497-852; authoritative model/state and validations: ../custom_addons_scola/gcgscola/scola_news/models/scola_news.py:102-208.
Steps and state transitions	draft → submitted → approved → published → archived; rejection uses rejected. Create/edit audience and window → submit → approve/reject → publish/schedule → reader access/read tracking as implemented → archive. Code confirms these labels and actions; who may skip a state, self-approve, recall, or republish requires business approval.
Downstream / completion criteria	Publish can create circular, portal notifications, audit, and realtime bus effects (../custom_addons_scola/gcgscola/scola_news/models/scola_news.py:1045-1174). Completion target: exactly one canonical published record is visible during its window to intended audience only, excluded readers receive neither content nor notification, and delivery failure is observable.
Correction, reversal, and recovery	Draft/submitted correction and reject/archive paths exist. Published correction/recall, notification correction, schedule failure, and legacy-history migration are not a signed recovery contract. Retry must not duplicate circulars/notifications.
Security / privacy / integration	Separate author/approve/publish/configure; enforce audience and tenant scope in reads and notification recipients; prevent draft/target leakage; audit state actor/time. Notification delivery inherits DEC-010, and canonicalization inherits DEC-011.
Evidence / readiness	Confirmed from code for model states/routes/APIs/side effects; Requires product decision/runtime verification for approval/audience matrix, retry, and reader propagation. Blocked by defect until STAB-033 removes the legacy writable competitor (docs/release-readiness/08-stabilization-backlog.md:79).

5. Controlled Pilot workflows

W05 — Daily student attendance

Dimension	Catalog entry
Contract / business outcome	Controlled Pilot, SC-CORE attendance domain. A teacher or homeroom teacher records daily student attendance, completes the attendance sheet; an authorized attendance administrator monitors or corrects under an approved policy; student/parent sees the resulting record. Employee attendance, RFID, face, geofence, pickup, and analytics are explicitly outside this workflow.
Actors	Assigned teacher or homeroom teacher; attendance administrator/operator; student self; linked parent-child reader. Principal/vice-principal default to read-only unless DEC-006 explicitly grants a distinct mutation capability. Attendance owner, School SME, Security, and DPO must sign the pilot.
Prerequisites / starting state	W00, W01, W02 passed; school-local date, active session or dated batch, exact event-date enrollment roster, assigned teacher/homeroom scope, attendance status glossary, proof policy, and correction window are approved. Starting state is no sheet for that canonical session/date, or an existing done sheet for an authorized correction.
Canonical pages/routes	Teacher /faculty/attendance and /faculty/attendance/sheet/:id; operator /attendance/home, /attendance/sheets, /attendance/session/:sheetId, /attendance/sheets/create; readers /student/attendance, /parent/attendance. Legacy teacher redirects and shared components are aliases, not separate pages (docs/documentation-planning/pilot-attendance-plan.md:86-99).
API/service chain	Teacher today sessions/session sheet/save: src/services/attendance/studentAttendance.service.js:397-450; student and parent daily/period reads: src/services/attendance/studentAttendance.service.js:312-387; admin list/detail/save/create surfaces: src/services/attendance/adminAttendance.service.js:52-125. Backend lifecycle and regular save are in ../custom_addons_scola/gcgscola/scola_attendance/controllers/attendance_api_mixin.py:3335-3422,4238-4334.
Steps and state transitions	Resolve school date and assigned session/batch → load exact roster or virtual all-present roster → set each student status and permitted evidence/notes → validate completeness/scope → save. Current regular-save code creates the sheet/lines and writes done; editing a done sheet uses the same save path and remains done (docs/documentation-planning/pilot-attendance-plan.md:118-132). This is observed code, not an approved completion/correction design.
Downstream / completion criteria	Target completion: exactly one tenant/session/date sheet with one line per eligible roster student, approved statuses preserved round-trip, actor/reason/time audited, and authorized student/parent/admin views show the same result. Report-card, promotion and permit bridges are potential consumers (docs/documentation-planning/pilot-attendance-plan.md:275-292); each must be tested, not assumed. No per-session push notification is proven; portal refresh is the observed visibility path.
Correction, reversal, and recovery	DEC-006 must define teacher/admin correction window, reason, approval, cancellation and downstream propagation. Failed initial save must be atomic; duplicate/retry must reuse one sheet; partial roster, stale assignment and concurrent edit must reject safely. Cancellation notification parameter behavior is unresolved (STAB-029). There is no approved user-facing reversal to teach.
Security / privacy / integration	Enforce exact teacher assignment, event-date roster, company/school, student self and parent-child scope. Proof files require type/size/signature/storage/download/retention controls and minimal portal projection. Leadership mutations require explicit policy; UI hiding is not authority. School-local date conversion must be deterministic.
Evidence / readiness	Confirmed from code for current pages, save behavior and portal reads; Blocked by defect/decision: STAB-017–STAB-022 and STAB-027, plus DEC-006 (docs/release-readiness/08-stabilization-backlog.md:58-63,68,107). Pilot cannot enter execution until those acceptance criteria and W05 positive/negative/scope/tenant/state/retry/propagation/privacy tests pass.

W12 — BOS/RKAS procurement

Dimension	Catalog entry
Contract / business outcome	Controlled Pilot, SC-BOS with SC-FIN and SC-OPS dependencies. An approved budget/RKAS line funds a purchase request through maker-checker approval, purchase order, receipt and one auditable commitment/realization effect. Code confirms subdomain actions but not a safe full pilot contract.
Actors	BOS/budget administrator, requester, procurement officer, approver, receiver, inventory/finance downstream roles. Proposed owner: BOS/Procurement; final approver and maker-checker/delegation are Requires product decision DEC-004.
Prerequisites / starting state	W00 passed; enabled SC-BOS and required finance/operations addons; tenant-scoped budget period/RKAS line, product, vendor, location, company, accounts and approval policy exist. Starting state is approved/available budget and no purchase request. Budget source, commitment timing, attachment policy, and over-budget exception must be signed.
Canonical pages/routes	Budget and RKAS pages followed by procurement requests, purchase orders, receipts and invoice pages under the inventory/BOS shell; current route definitions are src/router/inventoryRoutes.js:139-270. Shared budget/procurement components or alternate menu groups are not extra workflows.
API/service chain	Budget list/detail/actions: ../custom_addons_scola/gcgscola/scola_bos_rkas/controllers/budget_admin_api.py:64-191. Procurement requests/orders/receipts: src/services/admin/procurement.service.js:147-318 → ../custom_addons_scola/gcgscola/scola_bos_rkas_procurement/controllers/procurement_admin_api.py:78-378. Purchase-request state/effects: ../custom_addons_scola/gcgscola/scola_bos_rkas_procurement/models/purchase_request.py:54-186.
Steps and state transitions	Select valid RKAS/budget line → create draft request with lines/attachments → submitted → independent approve or rejected → rfq → po → receive → done; cancel is also modeled. Current approval creates a budget commitment and cancellation creates a cancellation ledger (../custom_addons_scola/gcgscola/scola_bos_rkas_procurement/models/purchase_request.py:137-186). Repeated approval safety is not proven and must not be normalized as expected behavior.
Downstream / completion criteria	Target completion: approved request becomes one PO; receipt updates intended stock/asset; budget has exactly one commitment and one approved realization; optional accounting entry reconciles; all IDs remain one company. The precise point of realization and invoice/posting ownership require Finance/BOS approval.
Correction, reversal, and recovery	Reject/cancel actions exist for some states, but correction after PO/receipt/posting and compensating budget/stock/accounting actions are not certified. Interrupted approval/retry must not duplicate commitment or PO. Invalid attachment, unavailable budget, partial receipt and integration failure need owned recovery queues and audit.
Security / privacy / integration	Split request/approve/order/receive/post/configure; maker cannot approve own request unless explicitly approved; validate company for every budget/vendor/product/location/account FK; restrict quotations/invoices/attachments; audit before/after and financial effects. Integration chain is SC-BOS → SC-FIN/SC-OPS, not implicit core.
Evidence / readiness	Confirmed from code for states and current commitment/cancel effects; Inferred from code for full chain; Blocked by defect STAB-012, including idempotency, attachment and maker-checker gaps (docs/release-readiness/08-stabilization-backlog.md:53). Pilot entry requires approved DEC-004/005/007/009 and all cross-module recovery tests.

W19 — Dapodik sync

Dimension	Catalog entry
Contract / business outcome	Controlled Pilot, SC-DAP. An authorized Dapodik operator configures one tenant-scoped connector, previews a bounded change set, executes only approved domains, reviews conflicts/errors, and can recover without corrupting authoritative Scola masters. The required preview/rollback behavior is a target; current traced API does not prove it.
Actors	Dapodik operator, data steward for academic/student/employee masters, integration support; Dapodik/Operations owner. No generic settings viewer may configure credentials or execute sync.
Prerequisites / starting state	W00 passed; SC-DAP enabled only for the pilot tenant; approved external source, credential secret storage, company/school mapping, matching keys, field ownership and conflict policy. Starting state is a known local-master snapshot plus connector configuration. Whether Dapodik or W01/W02 owns each field is Requires product decision DEC-008.
Canonical pages/routes	/settings/dapodik; optional report-card overlay /admin/report-card/dapodik-sync only if separately contracted. Route evidence: src/router/settingsRoutes.js:71-77 and src/router/academicProgressRoutes.js:182-190. The overlay does not create a second connector workflow.
API/service chain	Current controller exposes configuration read/write, connection test, logs/detail, and direct students/GTK/rombel sync in ../custom_addons_scola/gcgscola/scola_dapodik_connector/controllers/dapodik_api.py:22-571. Static search did not identify a distinct preview/dry-run or rollback endpoint at this baseline; the prior candidate’s “preview” is therefore Missing or unclear, not confirmed behavior.
Steps and state transitions	Intended safe pilot: configure secret/scope → test connection → generate non-mutating preview → data steward resolves conflicts → execute selected domain with idempotency key → inspect per-record result/log → reconcile. Current code proves configuration/test/log/direct sync surfaces, not that safe sequence or a unified state machine. Direct sync must remain unavailable until preview/execute authority is split.
Downstream / completion criteria	Sync can create/update student, faculty and academic/rombel masters consumed by W01/W02 and all their dependants. Completion target: approved preview equals applied changes, no cross-company or unowned-field mutation, deterministic match counts, every conflict/error visible, rerun produces no duplicate. This target requires implementation and runtime evidence.
Correction, reversal, and recovery	No supported rollback is proven. Required recovery is restore/reconcile by external ID and per-field ownership, with before/after audit and resumable batches; retry must not rematch another tenant’s identity. A backup alone is not a user/process recovery contract.
Security / privacy / integration	Dedicated view/configure/test/preview/execute capabilities; secrets never returned/logged; same-company matching; no unrestricted elevation; sensitive student/employee payload minimized and retained under DPO policy. Treat remote service failure and schema drift as explicit integration states.
Evidence / readiness	Confirmed from code only for current config/test/log/sync endpoints; Blocked by defect STAB-004 and Requires product decision for source ownership, dry-run, matching, conflict, rollback, and privacy (docs/release-readiness/08-stabilization-backlog.md:40,109-110). The pilot must be isolated until its writes are compatible with certified W01/W02.

6. Optional Supported workflows

An Optional Supported workflow is not “green by default.” It is absent when its SKU is disabled and must pass its own package, authorization, tenant, positive, negative, state, recovery, integration, and regression matrix before enablement.

W03 — SPMB applicant to enrolled student

Dimension	Catalog entry
Contract / business outcome	Optional Supported, SC-ADM. A candidate applies during an approved admission period, supplies required evidence, is assessed and decided by authorized staff, and—only at the approved transition—becomes one tenant-scoped student/onboarding input. The full ordering remains Inferred from code.
Actors	Public/registered applicant and family; admission staff/verifier; test/proctor/grader when CBT is enabled; final admission approver; Student Administration downstream. Admissions owner must approve the actor/action matrix.
Prerequisites / starting state	W00 for internal actors; enabled SC-ADM; configured period, program/quota, fee/discount rules where used, document requirements and optional exam schedule. Starting state is no application or a registered applicant. Required config ownership/effective date and final student-creation point remain open.
Canonical pages/routes	Applicant /spmb, /spmb/register, /spmb/admission/new, application detail and document/achievement/test/enrollment steps; internal admissions pages from the admissions app. Public route definitions are src/router/spmbRoutes.js:8-166; internal menu/route ownership is src/config/apps/appFragments/admissionsApp.js:13-142. Reused detail/step components are one application journey.
API/service chain	Registration, discount check, lifecycle completion, family summary and discount endpoints: ../custom_addons_scola/gcgscola/scola_admission/controllers/spmb_lifecycle_api.py:13-323; admission configuration mutations are traced in ../custom_addons_scola/gcgscola/scola_admission/controllers/admission_config_api.py:31-58,268-295,327-352,393-476.
Steps and state transitions	Configure/open period → register applicant/application → complete required identity/family/document data → verify/block evidence → optional test/CBT → admission decision → approved enrollment handoff to W02. Applicant model includes current state fields/actions (../custom_addons_scola/gcgscola/scola_admission/models/spmb_applicant.py:57-69,165-223,394-406), but application/result states are separate; no single approved state glossary is inferred.
Downstream / completion criteria	Completion target: one approved decision, one audit trail, one idempotent W02 handoff, and no student creation for rejected/duplicate applications. Fee enrollment and CBT are package integrations, not unconditional effects. Final approver, quota behavior and exact creation moment require product approval.
Correction, reversal, and recovery	Applicant can correct only fields/states allowed by approved window; staff block/reopen/reject/withdraw paths and decision reversal must define who, reason and downstream cleanup. Duplicate registration, failed upload/test, interrupted enrollment and student-creation retry need deterministic reconciliation. No deletion-based recovery is assumed.
Security / privacy / integration	Explicit public abuse/rate controls; server file allowlist/size/signature/scan; applicant-self scope; internal assignment/company scope; config view vs configure; sensitive family/identity data purpose and retention. SC-ASSESS and W02 integration must use stable application/external IDs.
Evidence / readiness	Confirmed from code for routes/endpoints/model actions; Inferred from code for full journey; Blocked by defect STAB-013 configuration authority and Requires product decision for states, final approver and idempotent W02 handoff (docs/release-readiness/08-stabilization-backlog.md:54).

W04 — CBT exam lifecycle

Dimension	Catalog entry
Contract / business outcome	Optional Supported, SC-ASSESS. Authorized staff build an exam from governed questions, schedule it for an eligible participant set, proctor attempts, accept one safe submission, grade all required responses, and publish the approved result to intended consumers.
Actors	Question author/reviewer, exam manager, proctor, eligible student/applicant, grader, result viewer. Exact publish/reopen/override and separation-of-duty roles require Assessment owner approval.
Prerequisites / starting state	W00 passed; SC-ASSESS enabled; W01/W02 assignment/enrollment or SC-ADM applicant context; valid question bank, participant set, exam window/token/config and grading rules. Starting state is governed questions and a draft exam.
Canonical pages/routes	Faculty question bank/exam/detail/proctor/grading/analytics/integrity routes: src/router/teacherRouteFragments/assessment.js:83-199; student exam/runner routes: src/router/studentRouteFragments/learning.js:66-123; admissions/public runners remain context-specific entries to the same attempt lifecycle, not duplicate exam products.
API/service chain	Question sets/questions: ../custom_addons_scola/gcgscola/scola_cbt/controllers/question_set_api.py:279-408 and ../custom_addons_scola/gcgscola/scola_cbt/controllers/question_api.py:578-851; lifecycle: ../custom_addons_scola/gcgscola/scola_cbt/controllers/exam_lifecycle_api.py:16-174,252-334; runner start/heartbeat/state/answer/sync/submit: ../custom_addons_scola/gcgscola/scola_cbt/controllers/runner_start_api.py:17-154 and ../custom_addons_scola/gcgscola/scola_cbt/controllers/runner_attempt_api.py:17-256; proctor: ../custom_addons_scola/gcgscola/scola_cbt/controllers/proctor_action_api.py:11-66; grading/result: ../custom_addons_scola/gcgscola/scola_cbt/controllers/grading_read_api.py:26-82, ../custom_addons_scola/gcgscola/scola_cbt/controllers/grading_write_api.py:25-81, ../custom_addons_scola/gcgscola/scola_cbt/controllers/report_results_api.py:16-38.
Steps and state transitions	Create/review questions → create draft exam and participants → schedule/publish → start attempt → heartbeat/save/sync answers → proctor action if required → submit → manual/automatic grading → approve/publish result. Current exam transition map permits draft/schedule/held/done/cancel movements at ../custom_addons_scola/gcgscola/scola_cbt/controllers/exam_lifecycle_api.py:322-334; its permissive reopen paths are current code, not approved policy.
Downstream / completion criteria	Completion target: each eligible participant has at most one intended attempt/version, final answers are durable, all grading requirements resolve, and authorized result consumers receive the exact published score once. Optional gradebook/report-card and SPMB propagation must be separately asserted.
Correction, reversal, and recovery	Define resume after disconnect, late submit, duplicate submit/idempotency, proctor termination, reopen, regrade and result correction. A retried answer or submit must not create conflicting attempts. Published-result reversal needs audit and downstream recomputation. These rules remain unresolved.
Security / privacy / integration	Enforce exam/participant/assignment/company and time-window scope; protect questions/answers/results; token cannot replace authorization; proctor and grader actions are separate; immutable attempt/audit timeline; accommodation and integrity data are sensitive.
Evidence / readiness	Confirmed from code for routes/APIs/current transition map; Requires product decision/runtime verification for retry, late/reopen, result publication and downstream grade integrity (docs/release-readiness/01-product-contract.md:246). Optional enablement is blocked until those contracts and concurrent/offline tests pass.

W06 — Employee self-attendance

Dimension	Catalog entry
Contract / business outcome	Optional Supported, SC-ATTEND+. An employee records one policy-compliant check-in/check-out for the intended work period, sees own history, and requests an auditable correction that only an authorized HR/attendance actor resolves.
Actors	Employee self; HR attendance operator/reviewer/approver; manager only if explicitly scoped. HR/Attendance owner plus DPO owns location/biometric policy.
Prerequisites / starting state	W00; enabled SC-ATTEND+; user linked to one employee/company; schedule/shift and attendance policy; device/location/face enrollment only when approved. Starting state is no open attendance for the work period, or one open check-in. Fallback and remote-work policy are unresolved.
Canonical pages/routes	Employee /employee/self-attendance; HR attendance dashboard/list/detail/corrections/report/period controls under /hr/attendance/*. Route evidence: src/router/teacherRouteFragments/attendance.js:49-56; src/router/hrAdminRoutes.js:179-204,372-409. Device or smart-ingestion pages belong to W20, not this manual/self journey.
API/service chain	Employee location/face/status/check-in/check-out/lock/history: ../custom_addons_scola/gcgscola/scola_hr_attendance/controllers/hr_attendance_checkin_api.py:130-594; HR list/detail/save/delete/correction/approve: ../custom_addons_scola/gcgscola/scola_hr_attendance/controllers/hr_attendance_admin_api.py:245-689; current/history/summary/period lock: ../custom_addons_scola/gcgscola/scola_hr_attendance/controllers/hr_attendance_reports_api.py:300-714.
Steps and state transitions	Resolve employee, schedule and current status → validate required location/device/face evidence → create open attendance at check-in → close at check-out → employee reviews own history → correction request/review/approve where applicable → period lock. Code confirms actions; the one authoritative correction/lock sequence is Inferred from code.
Downstream / completion criteria	Completion target: exactly one in-scope attendance record has valid timestamps and derived late/work duration under approved timezone policy; self view and authorized HR view agree; approved data becomes an explicit W09 input only when that bridge is enabled.
Correction, reversal, and recovery	Failed GPS/face/device, missed checkout, duplicate tap, offline/retry, overnight shift, locked-period correction and false biometric match require approved alternatives. Correction must preserve original values, reason, actor and approval. No silent HR overwrite is accepted.
Security / privacy / integration	Employee self-scope; HR company/assignment scope; separate biometric enrollment, attendance mutation, correction approval and period lock; minimize precise location/face templates/device identifiers; retention/consent and sensitive audit require DPO.
Evidence / readiness	Confirmed from code for current check-in/out and admin actions; Inferred from code for full path; Requires product decision/runtime verification for fallback, lock, correction, privacy and payroll propagation (docs/recon/workflow-candidates.md:23).

W07 — Gradebook to report card

Dimension	Catalog entry
Contract / business outcome	Optional Supported, SC-REPORT standalone; SC-LEARN optional bridge. Assigned teachers enter authoritative grades/comments, submit the required reports, authorized reviewers approve them, and a complete report card is finalized and visible only to the intended student/parent. Product must approve SC-REPORT's standalone grade source; a combined SC-LEARN bridge profile certifies integration only, never either SKU independently.
Actors	Subject teacher, homeroom teacher, curriculum/reviewer/approver, student and linked parent readers. Assessment/Curriculum owners must decide source of truth, self-approval and finalization.
Prerequisites / starting state	W00, W01 and W02 passed; SC-REPORT enabled; term, teacher assignment, enrolled roster, approved standalone assessment/grade source and report template. SC-LEARN is enabled only for the separately named bridge profile. Starting state is an open grade/report period with no finalized report card.
Canonical pages/routes	SC-REPORT baseline uses weekly report and report-card pages in teacher assessment routes, admin report-card workflow pages, and student/parent report-card readers. /faculty/lms/gradebook is a conditional SC-LEARN bridge entry, not the standalone SC-REPORT source. Route evidence: src/router/teacherRouteFragments/lmsAnalytics.js:70-78; src/router/teacherRouteFragments/assessment.js:46-77; src/router/studentRouteFragments/learning.js:77-83; src/router/parentRouteFragments/academic.js:69-78; src/router/academicProgressRoutes.js:170-218.
API/service chain	Standalone target chain: report-card generate/workflow/lines via src/services/reportCard/reportCard.service.js:36-181 → ../custom_addons_scola/gcgscola/scola_report_card/controllers/report_card_workflow_api.py:47-561. Conditional SC-LEARN producer chain only: gradebook/publish in ../custom_addons_scola/gcgscola/scola_lms/controllers/lms_grading_api.py:21-102,982-1035; weekly get/save/approval in src/services/lms/teacherReport.service.js:33-84 → ../custom_addons_scola/gcgscola/scola_lms/controllers/lms_teacher_report_api.py:840-1092, ../custom_addons_scola/gcgscola/scola_lms/controllers/lms_weekly_approval_api.py:123-196.
Steps and state transitions	Enter/save gradebook → publish/submit subject or weekly report → reviewer approve/reject → assemble/generate report card → resolve missing sections → review/finalize → portal/export. Code confirms weekly approve/reject and report workflow actions, but the canonical grade source, allowed post-approval edits and final state glossary require approval.
Downstream / completion criteria	Completion target: one term/student report card contains all approved source records, totals/labels are deterministic, is immutable or correctable under policy, and appears identically to authorized student/parent; unauthorized or other-class users see nothing. W08 may consume it only if W08 later becomes supported.
Correction, reversal, and recovery	Reject returns work to its named owner; late/missing grade, teacher replacement, reopened report, recalculation, duplicate generate and corrected final report need versioned audit and downstream invalidation. Export failure must not change finalization. No overwrite-after-finalize rule is assumed.
Security / privacy / integration	Teacher assignment and exact roster scope; separate enter/submit/approve/finalize/publish/export; no self-approval unless signed; parent-child/student-self scope; grades/comments and exports are sensitive; audit formula/source/version.
Evidence / readiness	Confirmed from code for actions/APIs; Requires product decision/runtime verification for grade source, edit locks, approver, completeness and cross-role propagation (docs/release-readiness/01-product-contract.md:249). Package bridge and static guards alone are not E2E evidence.

W09 — HR to payroll and payslip

Dimension	Catalog entry
Contract / business outcome	Optional Supported, SC-PEOPLE. Authorized HR/payroll staff convert approved employee, contract, period and input data into a reviewed payslip/payroll run; the employee sees only their own approved payslip, and any accounting effect has an owned posting/reversal path.
Actors	HR master-data operator, payroll preparer, independent reviewer/approver, employee self, finance consumer when integrated. HR/Payroll owner and DPO must approve role separation and confidential fields.
Prerequisites / starting state	W00; enabled SC-PEOPLE; tenant-scoped employee/person, active contract, salary structure, payroll period, journals/accounts if integrated, and an approved attendance/leave/input source. Starting state is an open payroll period with no final payslip or a draft run.
Canonical pages/routes	Employee/contracts, salary structures, payslips and payroll batches under HR; employee self-payslip route. Route evidence: src/router/hrAdminRoutes.js:13-128,247-321; src/router/teacherRouteFragments/core.js:104-111. Duplicate HR menu entries using the same payroll component do not create new workflows.
API/service chain	Payroll reports/admin and self views: ../custom_addons_scola/gcgscola/scola_payroll/controllers/payroll_api.py:52-354. Payslip list/save/update/compute/confirm/cancel/draft/refund/refresh-attendance/input/batch actions: ../custom_addons_scola/gcgscola/scola_payroll/controllers/payslip_admin_api.py:193-562.
Steps and state transitions	Validate employee/contract/structure/period → assemble approved attendance, leave and manual inputs → create draft payslip/batch → compute → review variance → confirm/finalize → employee self-view and optional accounting/payment handoff. Current controller exposes compute, confirm, cancel, return-to-draft and refund actions; their allowed state/SoD matrix is not yet approved.
Downstream / completion criteria	Completion target: every in-scope employee has at most one approved payslip per period/contract; totals derive from versioned approved inputs; self-view shows only own finalized record; optional finance entry reconciles once. Whether W06 is the authoritative attendance source and when recompute is allowed require approval.
Correction, reversal, and recovery	Invalid/missing contract/input rejects before posting; repeat compute/confirm is idempotent; cancel/draft/refund preserve original and audit reason; a corrected input deterministically recomputes only under the approved period/state policy. Payment/accounting reversal cannot be inferred from the existence of refund action.
Security / privacy / integration	Separate view/prepare/compute/review/confirm/cancel/refund/configure; maker-checker; employee self and company scope; no guessed-ID salary access; field projection for salary, tax, bank and attendance; sensitive reads/exports audited.
Evidence / readiness	Confirmed from code for route/API action presence; Inferred from code for the complete payroll chain; Blocked by defect STAB-010 and BLK-A07, including view/mutation/elevation/company scope (docs/release-readiness/08-stabilization-backlog.md:51; docs/release-readiness/04-authorization-readiness.md:165).

W10 — Billing and payment

Dimension	Catalog entry
Contract / business outcome	Optional Supported, SC-FEES with optional SC-FIN integration. Approved fee rules enroll the intended student, create an accurate bill, accept one authorized cash/transfer/gateway payment, validate evidence, update balance once, and issue one trustworthy receipt.
Actors	Billing/fee administrator, cashier/treasurer, payment verifier, student/linked parent payer, finance/accounting downstream actor. Billing/Finance owner must approve posting, refund and maker-checker.
Prerequisites / starting state	W00 and W02; enabled SC-FEES; tenant-scoped student enrollment, fee product/rule/template/schedule, journal/bank/payment method, optional scholarship/installment. Starting state is no enrollment or an unpaid/part-paid charge. Pricing/effective-date and scholarship ownership require DEC-008.
Canonical pages/routes	Fee templates/schedules/enrollment/scholarship/installment/SPP pages and operator transfer/cash/payment setup; parent billing/payment pages. Route evidence: src/router/financeRoutes.js:92-128,753-813; src/router/parentRouteFragments/finance.js:13-40. Cash/transfer/gateway are channels in one payment lifecycle, not separate product workflows.
API/service chain	Fee enrollment: ../custom_addons_scola/gcgscola/scola_fees/controllers/fee_enrollment_api.py:116-267; fee schedule/template: ../custom_addons_scola/gcgscola/scola_fees/controllers/finance_fee_api.py:274-488; manual transfer/cash/proof/submit/verify/reject/receipt: ../custom_addons_scola/gcgscola/scola_fees/controllers/manual_payment_api.py:101-563; gateway: ../custom_addons_scola/gcgscola/scola_fees/controllers/payment_gateway_api.py:78-311; parent billing: ../custom_addons_scola/gcgscola/scola_fees/controllers/parent_billing_api.py:198-323.
Steps and state transitions	Configure fee → enroll intended student → generate charge/invoice → payer selects channel → cash record or upload proof/gateway initiation → submit → verifier approve/reject or gateway callback → post/update balance → receipt. Current manual controller exposes create/proof/submit/verify/reject/cash actions; one approved state glossary across channels is missing.
Downstream / completion criteria	Completion target: the intended invoice/balance changes exactly once, payment and receipt reference the same company/student/amount, parent sees only linked-child data, and optional journal entry is balanced/reconciled. Notification is an integration governed by DEC-010, not an assumed success signal.
Correction, reversal, and recovery	Duplicate callback/upload/submit must be idempotent; amount/reference mismatch and stale bill must reject safely; rejected proof remains non-posted. Refund, reversal, charge correction, partial payment, overpayment and gateway-timeout reconciliation need an owned compensating workflow and audit.
Security / privacy / integration	Separate configure/enroll/view/collect/verify/post/refund; validate company on student, rule, product, invoice, journal, bank and payment FKs; parent-child/self scope; protect proof files, bank references, amounts and receipts; verify gateway signatures and replay resistance.
Evidence / readiness	Confirmed from code for current endpoints/actions; Inferred from code for end-to-end accounting effect; Blocked by defect STAB-014 tenant/FK scope and open reversal/ownership decisions (docs/release-readiness/08-stabilization-backlog.md:55; docs/release-readiness/04-authorization-readiness.md:47).

W11 — Accounting transaction lifecycle

Dimension	Catalog entry
Contract / business outcome	Optional Supported, SC-FIN. Authorized finance actors create a balanced company transaction, an independent authority posts/approves it, reconciliation is deterministic, and any correction follows an auditable accounting reversal rather than silent mutation.
Actors	Accounting preparer, finance reviewer/controller, payment approver, bank reconciler, auditor/read-only leadership. Proposed owner: Finance Controller; maker-checker and delegation require DEC-004.
Prerequisites / starting state	W00; enabled SC-FIN; company chart of accounts, journal, period, currency/tax, partner and bank setup. Starting state is an open accounting period and draft source transaction or unmatched statement line.
Canonical pages/routes	Journal/move and invoice pages; bank reconciliation; payment approval pages under Finance. Route evidence: src/router/financeRoutes.js:143-344,656-678,848-881. Reporting views are downstream consumers, not extra mutation journeys.
API/service chain	Move list/create/write/delete/actions: ../custom_addons_scola/gcgscola/scola_account/controllers/accounting_admin_api.py:111-207; reconciliation save/auto/match/validate: ../custom_addons_scola/gcgscola/scola_account/controllers/accounting_modules_api.py:212-300; payment approval request/approve/reject/reset: ../custom_addons_scola/gcgscola/scola_account/controllers/accounting_payment_approvals_api.py:15-106.
Steps and state transitions	Create balanced draft → validate data/period → independent post; payment path request → approve/reject/reset under allowed state; reconciliation import/select → match/unmatch → validate; reporting/audit consumes posted state. Current action names are confirmed, but self-approval, reset/reopen and reversal rules are not an approved accounting policy.
Downstream / completion criteria	Completion target: one balanced posted move, one approved payment state where applicable, and statement lines reconciled exactly once; reports reproduce source amounts and audit actor. SC-FEES/W09/W12/library fines may feed SC-FIN only through explicit tested bridges.
Correction, reversal, and recovery	Draft correction may be editable under policy; posted records require reversal/correcting entry, not delete; duplicate post/approval/reconcile is idempotent; unmatched/import error has a safe queue. Closed-period and cross-module rollback ownership require Finance sign-off.
Security / privacy / integration	Split view/create/edit/delete/post/approve/reconcile/configure/export; strict maker-checker; every record/FK company scoped; elevation only in a scoped service; immutable audit; protect bank, tax and payment data.
Evidence / readiness	Confirmed from code for routes and action endpoints; Blocked by defect STAB-003 / BLK-A09 because view-like authority can reach mutation/elevated paths and company scope is incomplete (docs/release-readiness/08-stabilization-backlog.md:39). No SC-FIN enablement before negative, tenant, SoD and integrity tests pass.

W13 — Stock opname

Dimension	Catalog entry
Contract / business outcome	Optional Supported, SC-OPS. Inventory staff freeze or otherwise establish a trustworthy expected-stock snapshot, count every required item, an authorized reviewer approves the variance, and one adjustment updates stock with an auditable record.
Actors	Inventory counter/officer, independent inventory approver, warehouse/finance downstream actors. Inventory owner must decide freeze, threshold and adjustment-posting authority.
Prerequisites / starting state	W00; SC-OPS; tenant-scoped product, warehouse/location, units and current stock; no conflicting open opname under the approved policy. Starting state is a new draft inventory count with expected quantities captured under a defined timestamp.
Canonical pages/routes	/inventory/stock-opname and its detail/action states; route evidence src/router/inventoryRoutes.js:371-379. List/detail/action panels for the same record are one workflow.
API/service chain	FE list/detail/create/action/lines: src/services/admin/inventory.service.js:509-641 → ../custom_addons_scola/gcgscola/scola_inventory/controllers/inventory_admin_api.py:757-886. Authoritative state/actions and stock-quant update: ../custom_addons_scola/gcgscola/scola_inventory/models/stock_inventory.py:34-47,132-285.
Steps and state transitions	draft → in_progress start → capture counts → validate → waiting_approval or policy-driven approval → apply adjustment → approved/done; reject currently leads to cancel; reset-to-draft is available in allowed states. The current validation has its all-lines-counted check disabled/commented (../custom_addons_scola/gcgscola/scola_inventory/models/stock_inventory.py:176-179), which is a gap, not an accepted rule.
Downstream / completion criteria	Completion target: a complete approved count changes only intended product/location quants once, records expected/count/difference and actor/time, and optional asset/accounting consumers reconcile. done must be reproducible from the counted lines and one snapshot.
Correction, reversal, and recovery	Before apply, correct/recount or reject under policy. Current model disallows cancel after done (../custom_addons_scola/gcgscola/scola_inventory/models/stock_inventory.py:268-285); no supported reversal is proven. Concurrent stock movement, incomplete lines, duplicate apply, crash mid-adjustment and mistaken location require atomicity/locking and a compensating adjustment process.
Security / privacy / integration	Split count/validate/approve/apply/configure; company/warehouse/location/product scope; maker-checker for material variance; lock/concurrency policy; immutable before/after quant audit. Avoid exposing cost/value to roles that only count quantity.
Evidence / readiness	Confirmed from code for current states/actions/quant write and disabled completeness check; Requires product decision/runtime verification for freeze, threshold, concurrency, completeness and recovery (docs/release-readiness/01-product-contract.md:255).

W14 — Library circulation

Dimension	Catalog entry
Contract / business outcome	Optional Supported, SC-LIB. A valid borrower reserves or borrows one available copy, the library records checkout/renewal/return, resolves lost/damaged/fine outcomes through approved authority, and leaves copy/loan/financial state internally consistent.
Actors	Librarian/circulation operator, student or employee borrower, fine/waiver approver, finance consumer if fines post. Library owner and Finance owner share lost/damaged/fine policy.
Prerequisites / starting state	W00; SC-LIB; W02 identity for student borrower or employee identity; active member, catalog/copy/location and loan/fine policy. Starting state is an available copy, queued reservation, or active loan. Queue priority/expiry and fine/waiver ownership remain open.
Canonical pages/routes	Library management catalog/unit/movement/queue/stock/fines/returns/quick-circulation pages and borrower self-service routes. Evidence: src/router/libraryManagementRoutes.js:15-106,196-256; src/router/sharedExperienceRoutes.js:155-228. Self/admin presentations are role views of one circulation record chain.
API/service chain	Queue create/cancel/assign/collect, return creation, waiver approve/reject and damage handling: ../custom_addons_scola/gcgscola/scola_library/controllers/library_queue_return_api.py:35-363; return state/actions: ../custom_addons_scola/gcgscola/scola_library/models/library_return_workflow.py:126-301; fine invoice/post effects: ../custom_addons_scola/gcgscola/scola_library/models/circulation_extend.py:228-293.
Steps and state transitions	Find available title/copy → optional queue/reserve → deterministic assign/collect → checkout → optional renew → return inspection → normal/lost/damaged resolution → assess fine → approve/reject waiver where requested → copy available or terminal exception. Code confirms normal/lost/damaged and waiver actions; policy and state ownership are not final.
Downstream / completion criteria	Completion target: one copy cannot be assigned/loaned twice; borrower and librarian agree on due/return state; normal return makes copy available; lost/damaged state and fine are applied exactly once; optional posted invoice is visible in finance without duplicate.
Correction, reversal, and recovery	Concurrent queue assignment must select one deterministic winner; failed collect/checkout/return must leave recoverable state; lost/damaged misclassification, fine waiver/reversal and posted-invoice correction require approved compensating paths. Settings/config and loan recovery cannot rely on broad view capability.
Security / privacy / integration	Member self-scope vs librarian company/library scope; separate queue/manage/checkout/return/fine/waive/configure; restrict borrower history and fines; same-company copy/member/invoice; audit waiver and damage evidence.
Evidence / readiness	Confirmed from code for queue/return/waiver/fine effects; Blocked by defect STAB-031 queue concurrency and STAB-032 settings capability; Requires product decision for fine/waiver/reversal (docs/release-readiness/08-stabilization-backlog.md:77-78).

W15 — Counseling and student affairs

Dimension	Catalog entry
Contract / business outcome	Optional Supported, SC-STUDENT. A permitted actor records a student-affairs or counseling event, the assigned owner reviews and resolves the appropriate sub-process, approved effects propagate once, and sensitive history is visible only for a documented purpose. This is an umbrella of related record types, not one fabricated universal state machine.
Actors	Counselor, assigned teacher/homeroom actor, student-affairs officer, reviewer/approver, student/linked parent only for approved projections. Counseling/Student Affairs owners and DPO must define case ownership and disclosure.
Prerequisites / starting state	W00, W01/W02; SC-STUDENT; tenant-scoped student, category/rule, assignment/case owner and privacy/retention policy. Starting state varies: new confidential note/referral, achievement, violation, incident, or permit. Each subtype requires its own approved fields and state matrix.
Canonical pages/routes	Counseling dashboard/students/violations/achievements/notes/referrals/incidents/permits pages under src/router/counselingRoutes.js:21-532. Similar student timeline/detail panels are related views, not duplicate workflows.
API/service chain	Counseling reports/detail/save, responses, referrals/status and schedule: ../custom_addons_scola/gcgscola/scola_counseling/controllers/counseling_domain_api.py:146-521. Achievements approve/reject, permits/actions and incidents triage/investigate/resolve/escalate: ../custom_addons_scola/gcgscola/scola_student_activity/controllers/kesiswaan_domain_api.py:146-261,966-1087,1134-1236.
Steps and state transitions	Select the specific subtype → create report/case with least necessary data → assign owner → review/respond/refer or approve/reject → for incident triage/investigate/resolve/escalate → publish only approved student/parent projection → close/retain. Code confirms subtype actions; no single cross-subtype sequence or finalization rule should be invented.
Downstream / completion criteria	Completion is subtype-specific: achievement/violation points, approved permit attendance effect, resolved incident, or completed referral/counseling plan—only after owner approval. Parent notifications and attendance/points effects are confirmed candidates (docs/recon/workflow-candidates.md:32) but require exact per-event propagation tests and privacy decisions.
Correction, reversal, and recovery	Incorrect report/identity, rejected achievement, withdrawn permit, reopened incident, mistaken attendance/points effect and sensitive-note correction require versioned audit, not silent delete. Appeal, escalation, emergency/break-glass, retention and notification failure paths remain open.
Security / privacy / integration	Split view/create/respond/refer/close/export and subtype approve actions; case/assignment/class/company and parent-child scope; purpose-limited field projection; highly sensitive discipline, counseling, health/family and attachments; audited break-glass only.
Evidence / readiness	Confirmed from code for subtype actions/APIs; Blocked by defect STAB-002 counseling scope and STAB-011 student-affairs mutation capability (docs/release-readiness/08-stabilization-backlog.md:38,52). Assignment, approval, retention and privacy still require owner/DPO confirmation.

W20 — RFID attendance ingestion

Dimension	Catalog entry
Contract / business outcome	Optional Supported, SC-ATTEND+. A registered tenant device submits an authenticated, deduplicated RFID event for an active card; the processor creates or reuses exactly one intended attendance effect; operators can inspect errors and use one safe retry/dead-letter path. This is not part of the W05 manual pilot.
Actors	Physical device identity, smart-attendance operator/device-card administrator, attendance owner, support operator for failed events; student/employee is the subject, not an API authority.
Prerequisites / starting state	W00 for operator UI; SC-ATTEND+; active tenant-scoped device and card assignment, secret/signature policy, event ID/time, target attendance mode, W01/W02 data for student/session processing, and W05-compatible status semantics. Starting state is no event with the external event ID.
Canonical pages/routes	Operator cards, devices, events and monitoring routes currently declared at src/router/inventoryRoutes.js:508-538; product IA must place them under SC-ATTEND+ and hide them from inventory-only tenants. These four pages are management/monitor views of one ingestion workflow.
API/service chain	Device ingestion/ping: ../custom_addons_scola/gcgscola/scola_smart_attendance/controllers/rfid_api.py:67-342; card management: ../custom_addons_scola/gcgscola/scola_smart_attendance/controllers/rfid_cards_api.py:341-671; device management: ../custom_addons_scola/gcgscola/scola_smart_attendance/controllers/rfid_devices_api.py:346-517; event list/retry/monitor/config/export: ../custom_addons_scola/gcgscola/scola_smart_attendance/controllers/rfid_events_api.py:369-707; event state/idempotency: ../custom_addons_scola/gcgscola/scola_smart_attendance/models/rfid_event.py:13-168; processor: ../custom_addons_scola/gcgscola/scola_smart_attendance/models/rfid_attendance_processor.py:20-190.
Steps and state transitions	Register device/card → device signs and submits unique event → authenticate device/company → persist event pending → validate card/time/target and deduplicate → processor creates/reuses student-gate or classroom attendance → mark success, duplicate, or error → operator monitors and retries only an eligible failed event. Current event model has these states; processor error can mark processed while model retry rejects processed, producing an unresolved retry contradiction.
Downstream / completion criteria	Completion target: one accepted external event maps to one event record and at most one attendance effect in the correct tenant/mode; duplicate delivery is observable but harmless; portal/admin views show the effect through the appropriate attendance domain; unsupported card/mode creates no mutation.
Correction, reversal, and recovery	Define retryable vs terminal errors, atomic reset/retry, bounded attempts, dead-letter owner and manual correction link. Device offline/out-of-order clock, revoked card, duplicate/concurrent ingest and downstream failure must preserve idempotency. Reversing an erroneous attendance effect uses its domain correction policy, not event deletion.
Security / privacy / integration	Device authentication/signature/replay protection; device/card/event/config/retry capabilities distinct; device/card/company ownership and assignment-date checks; secrets non-returned; event/card/time/location retention minimized; full correlation audit.
Evidence / readiness	Confirmed from code for routes, event states and processor branches; Blocked by defect STAB-030 due view/mutation and retry-state ambiguity (docs/release-readiness/08-stabilization-backlog.md:76). W20 requires W05/W06 domain semantics but remains a separately enabled and tested SKU path.

7. Workflows outside the supported baseline

The following entries remain in the inventory so their routes cannot disappear from release review. They are not eligible for a positive “supported workflow” test or documentation freeze in their present classifications.

W08 — Promotion and retention

Dimension	Catalog entry
Contract / business outcome	Incomplete / Remove from Product Surface, SC-REPORT candidate. Intended outcome is an approved, auditable promotion/retention decision and roster transition. V1 must hide/remove the current surface; the intended outcome is not an approved supported workflow.
Actors	Potential curriculum evaluator, homeroom recommender and final approver. Actor ownership and maker-checker are Requires product decision; no role should receive current mutation authority by inference.
Prerequisites / starting state	If reconsidered: W00/W01/W02/W07, current academic year/batch, complete approved evidence and next-batch target. Starting-state and evidence thresholds—including any code constants—are not business-approved.
Canonical pages/routes	Current admin route /admin/promotion; role aliases that reuse the same component are duplicates, not separate products. Evidence: src/router/academicProgressRoutes.js:230-238; alias/component relationship docs/recon/page-relationships.md:72-76. All entries should be hidden while status remains incomplete.
API/service chain	FE list/count/stats/generate/evidence/workflow: src/services/admin/promotionAdmin.service.js:7-25 → ../custom_addons_scola/gcgscola/scola_report_card/controllers/promotion_admin_api.py:63-172. Model states/effects are in ../custom_addons_scola/gcgscola/scola_report_card/models/student_promotion.py:25-58,527-849.
Steps and state transitions	Current code suggests generate/evaluate → recommended → decided → executed, with retained reason and next batch for promotion. Execution can change batch membership and notify parent. This is Confirmed/Inferred from code only, not a product-approved state, threshold or irreversible-action contract.
Downstream / completion criteria	No V1 completion criterion while hidden. If restored, completion must prove one authorized decision, correct next roster, retained reason, parent visibility/notification policy, and no duplicate execution across all downstream academic consumers.
Correction, reversal, and recovery	No approved rollback from executed roster effects is proven. Required future design must define pre-execution correction, decision appeal, wrong-batch compensating transaction and downstream recomputation before exposure.
Security / privacy / integration	Future policy must separate evaluate/recommend/decide/execute, require assignment/company scope and maker-checker, protect grades/evidence, audit irreversible action and test W01/W02/W07 propagation.
Evidence / readiness	Blocked by defect STAB-009 / BLK-A05: the admin controller references a broken/undefined guard and policy is unapproved (docs/release-readiness/08-stabilization-backlog.md:50; docs/release-readiness/04-authorization-readiness.md:163). Treatment: remove/hide, test absence/direct denial, and do not normalize the defect.

W17 — Complaint intake and triage

Dimension	Catalog entry
Contract / business outcome	Requires Product Decision; no approved package owner. Potential outcome is safe public complaint intake followed by assigned, confidential internal triage and response. Neither that surface nor its audience/retention/response promise belongs to V1 until Product, Security and DPO approve it.
Actors	Anonymous or identified submitter; proposed complaint operator/case owner; principal/escalation reader only if explicitly assigned. Current route labels do not establish those roles.
Prerequisites / starting state	Explicit public-purpose/consent notice, abuse protection, server attachment policy, tenant/case routing, operator ownership, retention/redaction and response SLA. Starting state would be no complaint plus approved field configuration. These prerequisites are unresolved.
Canonical pages/routes	Public /complaint; internal /admin/complaints with detail/dashboard/config routes in src/router/publicComplaintRoutes.js:4-44. Internal routes must be hidden; public route must also be disabled unless an explicit public-service decision and abuse/privacy controls pass.
API/service chain	Current controller exposes public configuration/submit, internal dashboard/list/detail, read/unread and field configuration surfaces in ../custom_addons_scola/gcgscola/scola_public_complaint/controllers/public_complaint_api.py:27-478. Static trace did not establish a complete assignment/status/response mutation lifecycle; absence must be treated as Missing or unclear.
Steps and state transitions	Intended only: validate consent/abuse/file → submit with opaque reference → assign tenant/case owner → triage/status/response → close/retain/redact. Current code does not prove that full chain or an approved state machine, so no supported transition is asserted.
Downstream / completion criteria	None for V1 while undecided. A future criterion must include safe acknowledgement, exactly one company-scoped case, assigned-owner actions, auditable response/closure, submitter-safe status view and retention/deletion behavior.
Correction, reversal, and recovery	False/spam/duplicate report, wrong tenant, sensitive attachment, reporter correction, operator reassignment, response correction and deletion/legal hold all require policy. No current generic delete/retry is accepted as recovery.
Security / privacy / integration	Explicit public allowlist/rate/anti-bot; strict file MIME/size/signature/scan; no case enumeration; case/company/assignment scope; purpose-minimized list/detail; safe download; redaction/retention; audit sensitive read/export.
Evidence / readiness	Blocked by defect STAB-001 S0 and Requires product decision DEC-001/004/009 (docs/release-readiness/08-stabilization-backlog.md:37,102,105,110). Internal surface remains hidden; route presence is not support.

W18 — Messaging and notification

Dimension	Catalog entry
Contract / business outcome	Requires Product Decision; no approved package/process owner. Potential outcome is tenant- and relationship-scoped conversation plus reliable notification/read state. Existing portal capabilities do not establish a supported cross-role communications product.
Actors	Internal user, student, linked parent, potential channel manager and notification administrator. Who may discover contacts, create channels, message across schools or manage notification policy is unresolved.
Prerequisites / starting state	W00; approved package boundary, contact/membership relationship, company/channel type, attachment policy, retention/moderation, quiet-hour/channel/delivery and retry policy. Starting state may be no channel or an existing authorized membership.
Canonical pages/routes	User /messaging and /notifications; management /admin/messaging, /admin/channel-management, /admin/notification-config from shared and communication routes (src/router/sharedExperienceRoutes.js:98-153; src/router/communicationAdminRoutes.js:10-62). These remain hidden until DEC-001 selects the product.
API/service chain	Channel list/create/search/contact: ../custom_addons_scola/gcgscola/scola_portal/controllers/general_messaging_channel_api.py:12-34; messages/send/read/attachments: ../custom_addons_scola/gcgscola/scola_portal/controllers/general_messaging_message_api.py:12-44; portal notifications: ../custom_addons_scola/gcgscola/scola_portal/controllers/portal_notification_api.py:18-87; config: ../custom_addons_scola/gcgscola/scola_portal/controllers/notification_config_api.py:25-57.
Steps and state transitions	Intended only: discover permitted contact/channel → create or join authorized channel → send body/attachment with idempotency key → persist message → notify members → mark/read receipt → honor preferences. Current code exposes these actions but no approved unified state/delivery contract; transport notification and authoritative message state must remain distinct.
Downstream / completion criteria	None for V1 while undecided. A future criterion must prove one durable message, only intended members can discover/read/download, retry creates no duplicate, read state is correct, delivery failure is observable, and notification is not mistaken for the authoritative record.
Correction, reversal, and recovery	Failed upload/send/delivery, duplicate client request, removed member, mistaken recipient, message deletion/redaction, moderation and quiet-hour backlog require explicit policy. Retrying transport must not duplicate the message.
Security / privacy / integration	Backend membership and company scope on every list/send/read/download; relationship-scoped contact discovery; attachment validation/safe download; content/metadata retention and audit; notification config view/configure split; SSE/push is delivery only.
Evidence / readiness	Blocked by defect STAB-006 S0 for membership/attachment scope and Requires product decision DEC-001/009/010 (docs/release-readiness/08-stabilization-backlog.md:42,102,110-111). Current code presence is not an approved communications SKU.

8. Missing E2E coverage and unresolved contracts

Coverage gap	Affected workflows	Required closure before certification	Status / evidence
Active-role, package and canonical-home enforcement	W00 and all	Approve DEC-001/002/003; fresh-role, switch-role, package-off and direct-route/API denial matrix	Blocked by defect: STAB-007/008/024/025/028; docs/release-readiness/08-stabilization-backlog.md:48-49,65-69
Password/account/session exception journey	W00	Decide and bound account activation, forced password, reset/unlock, expiry, concurrent-session revocation and break-glass; expose only retained routes and assign recovery/audit owner	Requires product/security decision: DEC-014 and CTRL-006; supported-looking surfaces include src/router/adminShellRoutes.js:61-68, src/components/ChangePassword.vue:187-203, and ../custom_addons_scola/gcgscola/scola_core/controllers/auth.py:367-400
Master ownership, publication, lock and correction	W01	Approved owner/effective date/reference-delete/collision/session correction policy and downstream invalidation	Requires product decision: DEC-005/007/008; roadmap docs/release-readiness/10-implementation-roadmap.md:143-149
Identity match/merge/unlink/import recovery	W02, W03, W19	Deterministic same-tenant match, source ownership, idempotent import/handoff/sync, account/parent unlink recovery	Blocked/decision: STAB-004/013/023; DEC-008/009
Offline/retry/reopen/result propagation	W04	Approved attempt and exam transition matrix; idempotent answer/submit; regrade/result-correction integration	Requires product decision/runtime verification: docs/release-readiness/01-product-contract.md:246
Attendance completion/correction/status/proof/privacy	W05	Close STAB-017–022/027 and DEC-006; exact roster, state, reason/window, proof and reader propagation	Blocked by defect/decision: docs/release-readiness/08-stabilization-backlog.md:58-63,68,107
Employee fallback, lock and correction	W06	GPS/face/device alternatives, overnight/timezone, missed checkout, correction/period lock and DPO contract	Requires product decision: docs/recon/workflow-candidates.md:23
Grade-source, finalize and corrected-report propagation	W07	Canonical grade source, completeness, maker-checker, versioned finalization/reopen and portal update	Requires product decision/runtime verification: docs/recon/workflow-candidates.md:24
Promotion execution and reversal	W08	Fix guard; approve evaluate/recommend/decide/execute policy; rollback/appeal; complete E2E	Not supported / blocked: STAB-009
Payroll input source, SoD and reversal	W09	Close STAB-010; approve inputs/recompute/confirm/refund/accounting and confidentiality	Blocked by defect/decision: docs/release-readiness/08-stabilization-backlog.md:51
Billing refund/reversal/gateway reconciliation	W10	Close tenant/FK gap; one channel state model; refund/overpayment/timeout recovery and journal owner	Blocked by defect/decision: STAB-014
Finance post/reconcile/approval reversal	W11	Close STAB-003; approve SoD, period close, reversal and cross-module journal ownership	Blocked by defect/decision: STAB-003
Procurement idempotency and compensating chain	W12	One commitment/PO/receipt/realization, attachment policy, partial failure and reversal	Blocked by defect/decision: STAB-012
Stock freeze/completeness/concurrency/reversal	W13	Snapshot/freeze, all-lines validation, approval threshold, atomic apply and compensating adjustment	Requires product decision/runtime verification: current completeness gap ../custom_addons_scola/gcgscola/scola_inventory/models/stock_inventory.py:176-179
Queue, fine, waiver and posted-invoice recovery	W14	Close STAB-031/032; deterministic queue and Finance-approved fine/waiver/reversal	Blocked/decision: docs/release-readiness/08-stabilization-backlog.md:77-78
Case assignment, privacy, appeal and subtype effects	W15	Close STAB-002/011; subtype state/owner matrices, retention, break-glass, attendance/points reversal	Blocked by defect/decision: docs/release-readiness/08-stabilization-backlog.md:38,52
News recall, legacy migration and delivery recovery	W16	Close STAB-033; approval/audience/recall and notification dedupe/failure contract	Blocked/decision: STAB-033, DEC-010/011
Approved complaint product and complete triage	W17	Decide owner/package; implement missing lifecycle and security/privacy controls	Not supported / S0: STAB-001
Approved messaging product and membership/delivery contract	W18	Decide owner/package; close membership/attachment; quiet-hour/retry/retention/moderation	Not supported / S0: STAB-006
Dapodik preview/source/conflict/rollback	W19	Non-mutating preview, separated execute, field ownership, tenant match, rollback and resumable logs	Blocked by defect/decision: STAB-004, DEC-008
RFID retry/dead-letter and downstream correction	W20	Close processed/error retry contradiction, capability split, signature/replay, one-effect and correction tests	Blocked by defect: STAB-030

8.1 Package-surface denominator gaps outside W01–W20

The workflow IDs above do not by themselves certify every menu/route promised by the proposed package rows in 01. For each gap below, Product must either narrow the package contract to named workflows/subflows or approve a new workflow ID with the same 11-category matrix. A generic package smoke or a passing adjacent workflow cannot fill the denominator. These are coverage/decision gaps, not application defects.

Gap ID	Package / currently unmatched surface	Required closure before package certification	Current status / evidence
E2E-GAP-01	All proposed supported packages: no approved leaf/page → workflow → test-denominator manifest yet	Inventory every supported canonical leaf and bind it to a W-ID/subflow plus required RT-* cases, or remove it from the package contract	Requires Product Decision / test design: QG-01, QG-02, QG-05, QG-14; package rows docs/release-readiness/01-product-contract.md:92-106
E2E-GAP-02	SC-CORE calendar, notification/configuration, user administration, and core portal-read surface beyond W00/W01/W02/W16 and W05 pilot	Define bounded Core journeys/subflows and all category parameters; exclude any optional/undecided leaf	Missing denominator: SC-CORE claims these routes at docs/release-readiness/01-product-contract.md:92
E2E-GAP-03	SC-LEARN standalone course/content/assignment/submission lifecycle; W07 only covers gradebook → report card integration	Add a Learning workflow/matrix or narrow SC-LEARN to a specifically named W07 dependency contract	Missing denominator: SC-LEARN surface docs/release-readiness/01-product-contract.md:96; W07 scope above
E2E-GAP-04	SC-LIB collection, textbook/GLS, configuration, and reporting beyond W14 circulation	Add bounded library subflows/parameters or remove those leaves from the certified SKU	Missing/partial denominator: docs/release-readiness/01-product-contract.md:98
E2E-GAP-05	SC-OPS master, procurement, asset, and reporting surface beyond W13 stock opname	Add product-owned journeys with state/recovery/integration matrices or narrow SC-OPS	Missing/partial denominator: docs/release-readiness/01-product-contract.md:100
E2E-GAP-06	SC-PEOPLE employee master, contract, leave, and self-service surface beyond W09 payroll	Add HR lifecycle journeys and privacy/scope matrices or narrow SC-PEOPLE	Missing/partial denominator: docs/release-readiness/01-product-contract.md:102
E2E-GAP-07	SC-ATTEND+ face/geofence/device/card/configuration surface beyond W06 employee attendance and W20 RFID ingestion	Decide supported modes and privacy basis; add a journey/matrix for every retained mode or remove/hide it	Requires Product/DPO Decision: docs/release-readiness/01-product-contract.md:103
E2E-GAP-08	SC-FOUND Foundation Analytics has no W01–W20 product workflow or 11-category matrix	Define a bounded business outcome and workflow ID, or reclassify/remove the package from Optional Supported	No denominator: docs/release-readiness/01-product-contract.md:104
E2E-GAP-09	SC-STUDENT extracurricular/discipline/permit breadth is only partially represented by W15 counseling/student-affairs	Enumerate each retained sensitive subflow under W15 or add separate workflows with DPO/ownership evidence	Missing/partial denominator: docs/release-readiness/01-product-contract.md:101
E2E-GAP-10	SC-BOS budget/RKAS planning, ledger, and reporting beyond W12 procurement	Add pilot subflow matrices and producer/consumer assertions, or narrow the pilot contract to procurement	Missing/partial denominator: docs/release-readiness/01-product-contract.md:106
E2E-GAP-11	SC-REPORT standalone source/finalization path: current W07 code evidence includes SC-LEARN although SC-LEARN is a separately sold optional package	Define and test SC-REPORT with SC-LEARN off, or make the dependency an explicit Product/Commercial decision; the combined bridge suite is integration evidence only	Missing standalone denominator: docs/release-readiness/01-product-contract.md:95,249
E2E-GAP-12	W00 credential lifecycle and exception recovery: activation, forced password, reset/unlock, expiry, concurrent-session revocation and break-glass	Approve DEC-014, narrow/remove unsupported surfaces, and parameterize W00 validation/recovery/security/UI cases with fresh accounts and auditable recovery	Missing bounded subflow: code surfaces src/router/adminShellRoutes.js:61-68, src/components/ChangePassword.vue:187-203, ../custom_addons_scola/gcgscola/scola_core/controllers/auth.py:367-400; CTRL-006

9. Release-test handoff contract

For every Core V1, enabled Optional Supported, or admitted Controlled Pilot workflow, the release matrix must instantiate the eleven denominator categories below. “N/A” needs a signed domain/security rationale; a missing case cannot be counted green. Privacy/audit is cross-cutting evidence, not a twelfth family. Detailed executable cases belong in 07; defect/decision ownership is governed by 08, release disposition by 09, and dependency-aware implementation order by 10.

Test family	Minimum E2E assertion derived from this catalog
Positive journey	Named authorized actor reaches the approved completion criterion using canonical pages/routes and resulting API chain.
Negative authorization	Unsupported role, view-only capability, previous active role, and direct API caller are denied with no state change.
Record scope	Other class/assignment/employee/child/case/member/device record is denied without existence or count leakage.
Tenant/company isolation	Same-shaped IDs and cross-company foreign keys in a second tenant are denied atomically.
Validation/integrity	Required, invalid, duplicate, stale, partial, boundary and attachment inputs are rejected by backend and represented safely in UI.
State transition	Every approved transition passes; invalid, self-approval and out-of-order action fail with unchanged data.
Retry/idempotency	Repeated, concurrent and interrupted mutation produces at most one intended effect and an observable terminal/retry state.
Recovery	The catalog’s approved correction/reversal/compensating path preserves history, actor, reason and downstream consistency.
Cross-role propagation	Producer result appears to the exact authorized consumer and corrected/reversed result propagates under the approved contract.
Cross-module integration	Every declared bridge is tested with producer/consumer IDs; disabled optional package has no hidden dependency or surface.
UI/IA parity	Canonical menu, breadcrumb, route, action visibility and actual backend authority agree at supported viewports.

Privacy/audit assertions are parameterized inside NEG/SCP/TEN/STA/REC/XRP/UIA (and POS when an audit result is part of successful completion): sensitive reads/files/exports and mutations must enforce purpose/scope/retention and record principal, active role, company, object, action, reason, and result.

These assertions operationalize QG-05–QG-14 (docs/release-readiness/09-release-quality-gate.md:136-145). They are inputs to the release test matrix, not claims that the tests currently exist or pass.

10. Catalog-level completion and freeze criteria

A workflow may be marked E2E-ready only when all of the following are true:

1. Its contract status, SKU/addons, owner, roles and pilot/optional boundary are approved; disabled or excluded surfaces are absent.
2. There is one canonical task route/page per role; every alias is a tested redirect with lifecycle, not a competing implementation.
3. Every step maps to a real route/component/service/controller/model effect on the recorded FE/BE/database/addon build.
4. Capability, record scope, tenant/company/school scope, domain ownership, state and audit are backend-enforced with deny-by-default behavior.
5. Starting state, completion state, allowed transitions and downstream effects are approved by the workflow owner; no code constant is silently promoted to business policy.
6. Correction/reversal, interrupted-operation recovery, retry/idempotency and integration-failure ownership are tested.
7. All positive, negative, scope, tenant, validation, state, retry, recovery, propagation, integration, UI, privacy and regression cases pass with no skipped required case.
8. There is no open S0/S1 or unresolved decision affecting completion, authorization, data integrity, tenant isolation, sensitive data or critical recovery; accepted limitations meet the quality-gate policy.

The global release freeze still requires all QG-01–QG-18, including exact manifest reproducibility and documentation freeze (docs/release-readiness/09-release-quality-gate.md:132-149).

11. Self-review

Review question	Result
Unsupported claims	Target completion/recovery statements are labeled as targets or decisions; static route/action presence is not called runtime proof. W08/W17/W18 have no supported completion claim.
Duplicated surfaces	Role aliases, reused components, runner variants, payment channels and management/detail views are consolidated under one workflow identity. Legacy announcement is excluded from W16.
Unresolved contradictions	W05 direct-to-done correction, W12 repeated approval, W13 disabled completeness check, W19 missing preview/rollback and W20 processed-error retry are explicit blockers/gaps.
Security boundaries	W00 active role/package; tenant/company; class/assignment; self/child; employee; case/member/device; maker-checker; files/proofs; sensitive read/export and audit are included.
Missing E2E links	W01→W02→W05, W16 after W00, W06→W09, W11+W13→W12, W02→W10/W14/W15, W05↔W07/W15/W20, W03→W02 and W19↔master ownership are explicit and remain test obligations.
Product decisions disguised as engineering	State/owner/approval/recovery/source/privacy/profile/credential-lifecycle choices are routed to DEC-001–DEC-014; engineering targets do not select the policy.

12. Sources reviewed

• Active governance: docs/ai-guidelines/development-guide.md, docs/ai-guidelines/workspace-governance.md, docs/ai-guidelines/architecture-api.md, and docs/qa/testing-guidelines.md.
• Reconnaissance: docs/recon/application-map.md, route-inventory.md, role-permission-matrix.md, page-relationships.md, workflow-candidates.md, and open-questions.md.
• Documentation planning: product surface, blocker register, priority, decision workshop, W05 pilot plan, and W05 traceability under docs/documentation-planning/.
• Release-readiness contract/audits/backlog/gates/roadmap: docs/release-readiness/01-product-contract.md through 04-authorization-readiness.md, and 08-stabilization-backlog.md through 10-implementation-roadmap.md.
• Current frontend routers, services and representative components plus current backend controllers/models cited inline. No runtime environment or production database behavior is claimed from this static pass.