Outstanding Decisions & Missing Areas

This page is the full JSON-backed view of what is still missing before the tutoring workflow is fully locked. It contains the detailed policy gap register, the full open/provisional decision rows from the operational spec, and the implementation capability gaps that still block clean execution.

How to read this page

An area is outstanding when one of two things is true: either the decision-grade workflow spec still marks it as open or provisional, or the current codebase still cannot support the intended policy cleanly across DTOs, UI surfaces, notifications, and guardrails.

Fix Existing Feature Existing behavior, visibility, workflow, or UX is wrong and needs correction.

New Feature A net-new capability, action surface, notification, or reporting function.

Ops / Setup Onboarding, data cleanup, seed/setup, account prep, handoff, or beta-run operations work.

Policy / Scope Decision framing, sequencing, or explicit defer/not-now scope control rather than direct implementation.

Frozen / Out of Scope Pricing, payout, invoicing, discount, and finance-modeling work excluded during the current freeze.

How We Know

The source-of-truth workflow tables in PRIORITY_PROJECT_EDITS.md explicitly mark rows as decided, provisional, or open.
The policy gap register in PRIORITY_PROJECT_EDITS.md spells out unresolved questions, options, trade-offs, recommendations, and what would become locked if chosen.
The decision-grade operational spec in PRIORITY_PROJECT_EDITS.md lists exact field mutations, blocked actions, timers, surfaces, endpoints, and financial consequences. Any row still marked open or provisional remains outstanding.
The current frontend and worker code was compared against the target behavior. Missing DTO fields, missing routes, split UI surfaces, stale refresh behavior, and unsupported visibility rules are tracked as implementation gaps.
The April 17, 2026 meeting transcript was folded in as an explicit operational addendum so beta-testing tasks, session-policy decisions, and contradictions are now visible alongside the main workflow spec.

Meeting Apr 17 2026 Addendum

This section folds the April 17, 2026 meeting into the outstanding-work view. Estimates are conservative lower-bound implementation estimates for one focused pass and do not include waiting on stakeholders, QA rounds, or deployment.

Work Type	Item	Owner	Expected Output	Dependency / Note	Conservative Time Estimate
`Ops / Setup`	Create 10 test assignments for educators	Nicole Tan	10 visible practice postings that cover both rejection and acceptance cases.	Requires matching-safe seed data and tutor-visible postings.	2h
`Ops / Setup`	Prepare educator guide PDF	Nicole Tan	Tutor-facing guide for login, profile verification, students, applications, sessions, and feedback expectations.	Best done after current UX labels are stable.	3h
`Ops / Setup`	Re-sync sessions up to the pre-absence cutoff	Sid M	Session data brought back to the agreed historical point before beta tutor review begins.	Depends on identifying the exact cutoff point from ops records.	4h
`Ops / Setup`	Upload educator profile PDF form data into the web app	Sid M	Imported educator profile data available in the correct web fields.	Depends on source PDF quality and field mapping.	5h
`Ops / Setup`	Delete fake student entries so live tutors do not see them	Sid M	Fake student rows removed or hidden from educator-visible surfaces.	Should be done before beta tutor login starts.	1.5h
`Ops / Setup`	Cross-check assignments against TimeTap using Nicole's list as source of truth	Sid M	Tutor-visible assignments reconciled against the source roster and scheduling system before beta use.	Requires Nicole's latest educator/client list and current TimeTap export or view.	2h
`Fix Existing Feature`	Fix `View Full Profile` loading failure	Sid M	Parent-facing tutor profile loads correctly from posting detail.	Depends on diagnosing current frontend/API failure path.	4h
`New Feature`	Implement educator notification when parents propose trial dates	Sid M	Tutor receives actionable notification with posting + date context.	Should land together with return-to-applications stage behavior.	4h
`Fix Existing Feature`	Differentiate trial vs regular sessions and show parent-proposed changes in tutor sessions	Sid M	Tutor session rows clearly label trial/regular and pending parent proposals.	Depends on session DTO enrichment.	8h
`Fix Existing Feature`	Change tutor session filter label to `Next 7 days`	Sid M	Session filter copy updated from `Today + upcoming` / equivalent.	Pure UI copy unless filter logic also changes.	0.5h
`New Feature`	Add cancel button directly on tutor sessions page	Sid M	Session rows expose cancellation action in-page.	Depends on final cancellation policy and endpoint behavior.	6h
`Fix Existing Feature`	Convert all time displays to `AM/PM`	Sid M	Platform time formatting normalized across session surfaces and related views.	Requires shared formatter sweep.	2h
`Fix Existing Feature`	Restrict session review actions to completed sessions only	Sid M	Irrelevant parent review actions disappear until a session has happened.	Depends on clear derived/persisted happened-state rules.	3h
`Fix Existing Feature`	Implement 4-hour reschedule block and block tutor check-in when parent reschedule is pending	Sid M	Reschedule/check-in guardrails enforced for both roles.	Requires reschedule request visibility in session DTO.	6h
`Fix Existing Feature`	Make checkout button grey and disabled until allowed	Sid M	Disabled checkout control replaces passive text before checkout opens.	Frontend-only once timing rules are settled.	2h
`Fix Existing Feature`	Restrict `Check In` to the session day	Sid M	Check-in action only appears when session is on the current day and in allowed window.	Depends on final check-in window rule implementation.	2h
`Fix Existing Feature`	Change past unconfirmed sessions to `Not Completed`	Sid M	Past untouched sessions no longer appear as merely `Scheduled`.	Depends on agreed derived lifecycle labels.	3h
`Fix Existing Feature`	Harmonize tutor and parent session views	Sid M	Parent and tutor see highly parallel session layouts with role-specific actions.	Depends on shared appointment DTO enrichment.	12h
`Fix Existing Feature`	Open checkout 30 minutes before lesson end and keep it available for 24 hours after	Sid M	Checkout timing window matches meeting decision.	Requires frontend and backend guardrail update.	3h
`Fix Existing Feature`	Update parent session status to `Completed` after educator confirms	Sid M	Parent session calendar reflects educator-confirmed completion immediately.	Must align with parent-facing acknowledgement language.	3h
`Fix Existing Feature`	Change self-service reschedule cutoff to 4 hours prior	Sid M	All self-service reschedule actions lock 4 hours before start.	Mostly overlaps with reschedule guardrail work.	2h
`Fix Existing Feature`	Remove `Log Session` button completely	Sid M	Tutor-facing `Log Session` action removed.	Conflicts with later meeting statement that tutors still need to add sessions.	2h once policy is final
`Ops / Setup`	Share pricing schedule link and relevant tabs	Nicole Tan	Sid has the correct pricing sheet/tabs for tutor-view rules.	Operational handoff, not product work.	0.25h
`Ops / Setup`	Activate specified tutors as demo users for testing	Sid M	Named tutor accounts are login-ready and correctly permissioned.	Depends on source tutor list.	2h
`Ops / Setup`	Create tutor login credentials using `FirstNameLastNameZip!` pattern	Sid M	Credential list ready for demo/beta tutor login handoff.	Depends on receiving final tutor roster and zip data.	1.5h
`Ops / Setup`	Send educator detail file by Monday for tutor trial access setup	Nicole Tan	Source roster with the minimum fields needed to create the beta tutor accounts.	Should avoid wider sheet sharing because of password and pricing sensitivity.	0.5h
`Ops / Setup`	Gather educator feedback during the beta period and escalate blockers quickly	Nicole Tan	Feedback loop runs during the test window, with major blockers surfaced immediately rather than batched late.	Depends on having a clear feedback channel and escalation owner.	1h
`Frozen / Out of Scope`	Review payout logic after educator beta flow stabilizes	Sid M	Post-beta finance/payout review sequence is defined without pulling payout logic into beta launch scope.	Should happen after beta workflow and session-state issues settle.	1h

Meeting-Derived Additions

Work Type	Addition	Why It Matters	Recommended Treatment	Conservative Time Estimate
`Ops / Setup`	Beta tutor exploration should be ready by April 20, 2026	This becomes the practical readiness milestone for beta access.	Treat as the beta-readiness checkpoint for tutor-facing surfaces.	0.5h
`Ops / Setup`	Beta test window runs until May 3-4, 2026	Gives a concrete feedback and bug-fix window.	Add as milestone guidance in the operational plan.	0.5h
`Ops / Setup`	Beta tutors should verify profile details and student-list accuracy after first login	This is part of the test script, not just a generic login step.	Add to the educator guide and beta test checklist explicitly.	1h
`Ops / Setup`	Beta tutors should also verify available postings, applications, and upcoming/future sessions	The testing script needs to cover the full educator workflow, not only profile and student data.	Add these explicit checkpoints to the educator guide and trial checklist.	1h
`Ops / Setup`	Major blockers found by tutors during beta should be streamed immediately	This defines the incident/escalation path during the test window.	Add an operational feedback/escalation rule to the beta plan.	0.5h
`Fix Existing Feature`	Student name should show under the session calendar	Tutors need quick student context inside the calendar/session surface.	Add to session UI polish backlog.	1h
`Fix Existing Feature`	Trial-confirmed tutor should appear under `My Students` after acceptance	Clarifies when trial relationships become student-visible.	Add to match/trial visibility rules.	2h
`Fix Existing Feature`	Check-in/check-out is not a live timer, it is a completion confirmation flow	Prevents the wrong mental model in UX language.	Update copy and docs so actions read as confirmation, not time tracking.	1h
`Fix Existing Feature`	Parents should not be able to reschedule after educator confirmation	Protects completed-session and payout integrity.	Keep this as a hard blocked action in the session model.	1h
`Fix Existing Feature`	Parents should not be able to reschedule after tutor has checked in	Confirms attendance should freeze the slot.	Keep this as a hard blocked action in the session model.	1h
`Fix Existing Feature`	Checkout errors need to surface visibly, not hide behind the navigation or action layout	The meeting captured real confusion where an error existed but users could not see it clearly.	Tie this directly to the top-most error-overlay and action-feedback cleanup.	1.5h
`Fix Existing Feature`	Session lists should reflect the selected filter scope consistently	The team called out that `sessions in view` did not reliably match the chosen scope.	Add explicit filter-scope correctness to the session UX cleanup work.	2h
`New Feature`	Proposed sessions may need a tentative visual treatment in calendar mode	The meeting suggested a `parent proposed` style akin to a dashed/tentative calendar event.	Add to the session-view convergence and visual-status work.	2h
`Frozen / Out of Scope`	If checkout happens after the payroll cutoff date, the session moves to the next payout cycle	This affects educator expectations and payout statement logic.	Add as payout statement and cutoff policy, not full payroll-engine scope.	2h
`Frozen / Out of Scope`	Tutor-facing session surfaces may need earned-amount visibility per completed session	The meeting implies educators should see earnings even if full billing is removed.	Treat as payout-reporting UX scope for completed sessions.	4h
`Frozen / Out of Scope`	Payout statement should only show completed sessions in `1-15` and `16-end-of-month` periods	Clarifies the payout statement display rule even though full payroll integration is deferred.	Treat as reporting UI scope, not full payroll engine scope.	4h
`Frozen / Out of Scope`	Coordinator is the only actor who controls educator incentive adjustments	Limits who can override payout variance.	Add to future payout/policy module assumptions.	1h
`Frozen / Out of Scope`	Client discounts and trial-price changes should not change educator payout	Protects tutor payout consistency even when parent pricing changes.	Add as payout-policy rule separate from client pricing logic.	1h
`Frozen / Out of Scope`	Flexible historical pricing/versioning is a future requirement, not launch scope	Prevents short-term hardcoding that would break future pricing history.	Record as future architecture requirement for pricing/payout modules.	2h
`Frozen / Out of Scope`	Discount-code support for new users was proposed as a simpler future pricing lever	This is a future pricing/commercial feature, not part of the launch-critical workflow.	Track as optional later pricing feature.	1h
`Frozen / Out of Scope`	Pricing remains subject-based, not age-based	Prevents pricing logic from drifting into DOB-driven payout logic.	Lock this into pricing policy documentation.	1h
`Frozen / Out of Scope`	DOB/grade may still be useful for profile context even though pricing is not age-based	Separates profile-data usefulness from pricing rules.	Keep as future profile-data consideration, not payout logic.	1h
`Frozen / Out of Scope`	Payroll integration is deferred from the upcoming launch	Prevents current launch scope from expanding into a payout-engine rewrite.	Mark payroll engine work as explicitly out of launch scope.	1h
`Frozen / Out of Scope`	Test exploration comes first; finance-grade outputs come later	This captures the core launch-scope rule from the meeting and avoids premature finance UX promises.	Make this explicit in the rollout plan and payout-deferral wording.	0.5h
`Ops / Setup`	Tutor credentials should be changeable after first login even if seeded with a simple initial password	Keeps the beta credential policy simple without implying permanent weak-password storage.	Make sure the beta login guide and account setup permit password change.	1h
`Ops / Setup`	The full tutor/pricing sheet should not be shared broadly	Passwords and pricing data are sensitive operational information.	Record as an operational data-handling rule for beta setup.	0.5h

Meeting Conflicts Still Needing Decision

Work Type	Conflict	Why It Is A Conflict	Current Recommendation	Conservative Time Estimate To Resolve
`Policy / Scope`	`Remove Log Session completely` vs `educators still need to add additional sessions`	The transcript contains both positions, and they imply different session-creation ownership models.	Remove the current `Log Session` UX, but preserve a cleaner `Add Session` capability for tutors if extra-session creation is still required.	2h
`Policy / Scope`	`Parent approval monthly` vs immediate parent-facing acknowledgement semantics	One part of the meeting points toward monthly approval discipline, while another expects immediate completed-state awareness.	Keep immediate educator-confirmed completion visibility, but separate that from the parent acknowledgement/billing cadence.	2h
`Policy / Scope`	`Completed` vs `Confirmed by educator` as the immediate parent-facing label	The meeting supports both ideas, and they create different expectations around whether the session is fully settled or only educator-confirmed.	Use a two-layer label if needed: lifecycle state `Completed`, with supporting copy `Confirmed by educator; awaiting parent acknowledgement`.	1.5h
`Frozen / Out of Scope`	`Billing could potentially be removed` vs `payout statement should still show completed sessions`	This changes whether billing UI is removed entirely or narrowed to reporting.	Keep lightweight payout statement/reporting and defer full payroll/billing engine work.	2h
`Policy / Scope`	`Confirmed sessions cannot be modified by parents` vs `parents should still see all sessions and reschedule where allowed`	The allowed reschedule surface is only coherent if completed and educator-confirmed sessions are clearly blocked.	Preserve full session visibility, but hard-block post-confirmation reschedule/edit actions.	1h
`Frozen / Out of Scope`	`Remove parent pricing complexity from launch` vs future need for flexible historical pricing	Launch scope wants simplicity, but later pricing history/versioning requirements are real.	Explicitly defer pricing-versioning implementation while documenting it as an architectural follow-up.	1.5h
`Policy / Scope`	Imported historical sessions as normal editable rows vs special locked historical records	The meeting implies some past/imported sessions may need different treatment rather than pretending they are ordinary live platform sessions.	Treat imported historical sessions as special read-only or explicitly tagged records unless manually normalized.	2h
`Frozen / Out of Scope`	Parent invoicing model and review deadline strictness are still underdefined	The meeting leans toward billing-cycle approval, but the exact invoicing and deadline model is not fully decided.	Keep this open in policy until the beta validates the session-acknowledgement flow.	2h
`Frozen / Out of Scope`	Future pricing model shape: per-child hardcoding vs per-session values vs discount codes vs configurable module	The meeting surfaces these options but does not lock one architecture yet.	Defer implementation now, but record these as the explicit future pricing-model design options.	2h

Detailed Policy Gap Register

Gap	Open Question	Why It Matters	Options	Trade-Offs	Current Recommendation	What Becomes Locked
Cancellation model by actor	Who can cancel a session, under what timing rules, and what persisted state model should represent each cancellation path?	Affects payout fairness, package deduction reversal logic, parent/tutor trust, and whether `Cancelled_By_Tutor` is sufficient as the only stored cancel status.	Minimal: one cancel state plus audit metadata. Medium: actor-aware states such as `Cancelled_By_Tutor`, `Cancelled_By_Parent`, `Cancelled_By_Coordinator`. Full: actor + timing + reason categories.	Minimal is easiest technically but weak for analytics and policy clarity. Medium is the best operational balance. Full is strongest long term but much heavier.	Use the Medium model first.	Appointment cancel enum design, cancellation UX copy, payout/package consequences by actor.
Missed session / no check-in model	If a session start/end passes and the tutor never checks in, should this remain a derived overdue state or become a persisted status?	Affects ops queue clarity, accountability, reporting, and whether a missed session is distinguishable from an untouched future session.	Derived only, or persisted missed status such as `Missed` or `No_Check_In`.	Derived-only avoids migration. Persisted status makes reporting and policy enforcement cleaner if missed sessions become common.	Start derived-only unless operations already treat missed sessions as a high-volume reporting category.	Session status model, stale-session queue logic, reporting buckets.
Amber vs red outstanding counts	What thresholds should move an outstanding badge from green to amber to red?	Affects operator prioritization and whether badges remain meaningful rather than noisy.	Binary only; time-based urgency; severity-based plus time-based.	Binary is simple but weak for triage. Time-based is strong and easy to explain. Severity-plus-time is powerful but harder to keep consistent.	Use time-based urgency: grey `0`, green within SLA, amber approaching breach, red overdue.	Nav badge logic, queue ordering logic, notification urgency language.
Admin dispute outcomes	What final outcomes can a coordinator/admin choose when resolving a disputed session?	Affects payouts, package usage, and fairness to parent and tutor.	Simple: approve or cancel. Practical: approve as-is, approve adjusted hours, or void financially. Full: granular adjudication including partial payout and misconduct flags.	Simple may be too blunt. Practical likely covers most disputes. Full adjudication is strongest but much heavier operationally.	Use the Practical model first.	Admin dispute UI, payout settlement logic, package reversal logic.
Tutor withdrawal after push / parent acceptance	Until what point can a tutor withdraw cleanly from an application or match flow?	Affects fairness to parents, coordinator workload, and trust in pushed candidates.	Withdraw allowed until push; until parent acceptance; or after parent acceptance only through a stronger decline/cancellation flow.	Earlier cutoffs increase parent confidence. Later flexibility reduces tutor friction but creates more churn.	Allow normal withdrawal until parent acceptance. After parent acceptance, treat any tutor exit as a higher-friction decline/cancellation flow.	Application CTA rules, tutor workflow labels, post-acceptance cancellation/escalation rules.
`Log Session` as first-class action	Is manual session logging still a core product need, or should it become a rare exception/admin action only?	Affects whether the app stays schedule-first, data quality, and how much ad hoc correction behavior is permitted.	Keep as first-class tutor action; keep only as exception path; or remove from tutor UX and keep admin-only.	First-class is flexible but weakens schedule discipline. Exception-only is the best balance if ad hoc logging is still sometimes needed. Admin-only is cleanest but slower for real corrections.	Keep it as exception-only unless there is a strong business reason to preserve routine manual logging.	Tutor sessions UX prominence, appointment creation permissions, correction workflows.
Session review window and language	How long does the parent have to acknowledge a happened session, and is the language purely `Acknowledged` or should there be a distinct interim label?	Affects payout timing, backlog size, and clarity of parent-facing status text.	Keep current 2-day hard decision window; keep a 2-day priority window but allow later acknowledgement with ops visibility; or extend the formal window.	Hard 2-day is operationally tight but can create avoidable exceptions. Priority plus late acknowledgement is more forgiving. Longer windows slow payout closure.	Keep a 2-day priority window, but separate expected response SLA from the absolute maximum self-service acknowledgement window.	Payout cadence assumptions, parent session copy, ops escalation timing.
Parent / tutor / coordinator session-surface split	How far should the app go in fully converging parent and tutor session views versus preserving role-specific pages?	Affects implementation scope, centralization of logic, and how quickly the UX becomes coherent.	Shared model with separate pages; shared model with highly parallel pages; or one component system with role toggles.	Separate pages are fastest. Highly parallel pages improve consistency. One component system is strongest long term but is a much larger UI refactor.	Use a shared model plus highly parallel pages first.	Frontend architecture direction, endpoint design expectations, UI refactor size.
Child-level intake vs posting-level requirements	Should subject/timing preferences live only on postings, or is there still a valid child-level intake concept that should remain?	Affects parent information architecture, match precision, and duplication/staleness of preference data.	Posting-only requirements; child-level baseline plus posting-specific overrides; or keep both fully independent.	Posting-only is cleanest and best matches the current direction. Baseline-plus-override is flexible but more complex. Fully independent duplicates data and creates drift.	Move toward posting-only requirements unless there is a strong operational need for persistent child-level learning preferences separate from session logistics.	Child intake design, posting creation requirements, migration/removal of legacy intake fields.

Outstanding Decision-Grade Rows

These are the full rows from the operational spec that are still open or provisional. This is the exact level that should drive product-policy review and implementation planning.

Posting And Application Rows

Workflow	System Object(s)	Current State	Actor	Action / Trigger	Exact Field Mutation	Allowed Actions	Blocked Actions	Timer / SLA	Visibility By Role	Primary UI Surface	API / Endpoint	Notification Event	Audit Event	Financial Consequence	Escalation Rule	Decision Status	Decision Owner	Test Coverage
Shortlist tutor	`application`	`Pending`	Coordinator	shortlist	`application.status: Pending -> Shortlisted`	shortlist, reject, push	parent exposure before push	internal ops SLA	coordinator only	admin matching	application update endpoint	optional coordinator-only	application status audit	none	if stuck too long, queue badge escalates	Provisional	Ops	coordinator matching flow
Parent reviews pushed tutor	`application`, `match visibility`	`Pushed`	parent	open posting detail	no mutation	view profile allowed by visibility rule; accept; ignore	seeing protected fields before policy gate	parent response SLA TBD	parent sees permitted profile depth; tutor sees waiting stage; coordinator sees review pending	parent posting detail	posting detail endpoint	none or viewed event	analytics only	none	idle review becomes coordinator chase item	Provisional	Product	parent review flow
Tutor withdraws before acceptance	`application`	`Pending`, `Shortlisted`, or maybe `Pushed`	tutor	withdraw application	`application.status -> Withdrawn`	withdraw until cutoff	withdraw after cutoff once policy decided	cutoff policy TBD	tutor sees withdrawn; coordinator sees closed; parent should not see active candidate	tutor applications	application withdraw endpoint	optional coordinator notice	application withdraw audit	none	after cutoff, route through stronger decline path	Open	Product + Ops	tutor application management flow

Trial Negotiation And Conversion Rows

Workflow	System Object(s)	Current State	Actor	Action / Trigger	Exact Field Mutation	Allowed Actions	Blocked Actions	Timer / SLA	Visibility By Role	Primary UI Surface	API / Endpoint	Notification Event	Audit Event	Financial Consequence	Escalation Rule	Decision Status	Decision Owner	Test Coverage
Tutor reviews proposed dates	`trial_date_proposal`	`Date_Proposed` with pending proposal	tutor	open proposal detail	no mutation	inspect posting, child, slots; accept; counter	checking in to unscheduled trial; losing application visibility	response SLA should exist	tutor sees actionable proposal; parent sees awaiting tutor; coordinator sees aging queue	tutor applications, tutor sessions proposed items	trial status endpoint	optional viewed state	analytics only	none	if idle too long, coordinator follow-up	Provisional	Ops	tutor trial review flow
Parent pays trial invoice	`trial_invoice`, `match`	`trial_phase = Invoiced`	parent	pay invoice	invoice state paid; `trial_phase: Invoiced -> Active`	pay and continue	attending unpaid trial if policy disallows	invoice payment SLA TBD	parent/tutor/coordinator all see active scheduled trial	parent billing, tutor sessions, admin trial queue	invoice payment endpoint	payment received	payment audit	cash collection; trial financially committed	overdue unpaid invoice escalates	Provisional	Product + Finance Ops	trial payment flow
Trial completes and feedback recorded	`match`, `trial_feedback`	`trial_phase = Active`	Parent or coordinator	record outcome	save feedback; `trial_phase -> Feedback_Pending` if not already	mark continue/stop intent	scheduling regular sessions before decision	short follow-up SLA after trial	parent/tutor/coordinator see trial outcome pending	parent/trial follow-up, admin trial queue	trial feedback endpoint	feedback pending	trial feedback audit	may gate regular revenue continuation	stale feedback becomes coordinator task	Provisional	Ops	trial follow-up flow

Session Lifecycle Rows

Workflow	System Object(s)	Current State	Actor	Action / Trigger	Exact Field Mutation	Allowed Actions	Blocked Actions	Timer / SLA	Visibility By Role	Primary UI Surface	API / Endpoint	Notification Event	Audit Event	Financial Consequence	Escalation Rule	Decision Status	Decision Owner	Test Coverage
Parent acknowledges session happened	`appointment`	`Awaiting_Approval_Parent`	parent	acknowledge	`status: Awaiting_Approval_Parent -> Approved`; `confirmed_by_parent -> 1`; set approved hours	acknowledge, dispute	reschedule, cancel, pre-happened review	target response 2-day priority window	parent sees `Acknowledged`; tutor sees settled; coordinator sees closed	parent sessions	existing confirm/verify endpoint or renamed equivalent	session acknowledged	parent acknowledgement audit	payout becomes eligible; package deduction finalizes	overdue parent review may become coordinator chase item	Provisional	Product + Finance Ops	parent session review flow
Coordinator resolves dispute	`appointment`, issue/dispute object	`Disputed`	Coordinator	resolve	exact mutation depends on chosen resolution outcome: approve, adjusted hours, or void	resolve according to policy	silent close without explicit outcome	ops SLA required	all roles see final outcome and notes	admin disputes, session detail	admin dispute resolution endpoint	dispute resolved	admin resolution audit	payout/package effect depends on outcome	if unresolved beyond SLA, ops escalation	Provisional	Ops + Finance Ops	admin dispute flow
No check-in / missed session	`appointment`	`Scheduled`, session time passed	System time / coordinator	session missed without check-in	either none (derived-only) or future persisted `Missed` if policy changes	manual resolution, issue capture, maybe admin cancel	standard acknowledgement path before session actually happened	needs explicit ops SLA	tutor/parent/coordinator labels depend on chosen model	tutor sessions, parent sessions, admin backlog	derived from appointment feed or future admin endpoint	optional missed-session alert	derived-state reporting or future audit	payout/package usually blocked pending resolution	coordinator ownership after threshold	Open	Product + Ops	missed-session scenario coverage

Reschedule And Cancellation Rows

Workflow	System Object(s)	Current State	Actor	Action / Trigger	Exact Field Mutation	Allowed Actions	Blocked Actions	Timer / SLA	Visibility By Role	Primary UI Surface	API / Endpoint	Notification Event	Audit Event	Financial Consequence	Escalation Rule	Decision Status	Decision Owner	Test Coverage
Tutor cancels future session	`appointment`	future session outside freeze	tutor	cancel	likely `status -> Cancelled_By_Tutor` or richer future enum	cancel if policy allows	cancel inside freeze; cancel after happened; check in afterwards	outside 4h freeze unless admin exception	all roles see cancelled with actor attribution	tutor sessions, parent sessions, admin appointments	cancellation endpoint TBD	cancellation notice	cancellation audit	payout removed; package reversal or no usage; penalty policy TBD	inside freeze or repeated pattern -> coordinator	Open	Product + Finance Ops	cancellation flow
Parent cancels future session	`appointment`	future session outside freeze	parent	cancel	future actor-aware cancel mutation TBD	cancel if policy allows	cancel inside freeze; cancel after happened	outside 4h freeze unless admin exception	all roles see cancelled with actor attribution	parent sessions, tutor sessions, admin appointments	cancellation endpoint TBD	cancellation notice	cancellation audit	package / invoice consequence TBD; tutor compensation policy TBD	inside freeze -> coordinator exception only	Open	Product + Finance Ops	cancellation flow

Badge, Visibility, And Surface Rows

Workflow	System Object(s)	Current State	Actor	Action / Trigger	Exact Field Mutation	Allowed Actions	Blocked Actions	Timer / SLA	Visibility By Role	Primary UI Surface	API / Endpoint	Notification Event	Audit Event	Financial Consequence	Escalation Rule	Decision Status	Decision Owner	Test Coverage
Parent full profile visibility	`application`, `match`, user profile projection	pushed/accepted tutor	parent	open candidate/profile detail	no underlying mutation; projection rules decide fields	view permitted fields	viewing blocked fields before allowed stage	always, stage-dependent	parent sees gated profile; tutor/coordinator see full internal data	parent posting detail, admin views	candidate detail endpoints	none	access/visibility logging desirable	none	privacy breach escalates immediately	Provisional	Product + Ops	visibility-rule coverage

Detailed Implementation Capability Gaps

Area	Target Capability	What Is Missing In Code	How We Know	Current State	Owner	Blocking Scope
Unified parent sessions surface	A full parent sessions view showing all sessions with the same conceptual model as tutor sessions.	The route now exists at `/parent/sessions`, but the older child-specific pages still remain and the shared session-card/table logic is not yet componentized.	Frontend now ships a family-wide sessions hub with child deep-link filters, tutor-style view modes, and parent-specific actions.	Built, still needs convergence cleanup	Frontend	Follow-up cleanup rather than a parity blocker.
Trial proposed items inside tutor sessions	Tutor sessions should surface parent-proposed trial date items as first-class pending session rows with posting and child context.	Trial response UX still lives mainly in tutor student/application fragments, not a converged sessions model.	Current trial handling and tutor flows are still split across different surfaces.	Partially built elsewhere	Frontend + API	Blocks the intended return-to-tutor flow.
Appointment DTO enrichment	The appointment feed should expose `session_type`, `lifecycle_status`, `trial_phase`, latest reschedule metadata, and action flags.	Current backend appointment query helpers and payloads do not yet expose the full target contract.	The decision-grade spec requires fields that are not yet emitted by the current appointment queries.	Not built	API	Blocks consistent cross-role session rendering.
Outstanding tab counts	Role-aware outstanding counts on postings, applications, students, sessions, and related tabs.	Workspace shell supports badges, but counts are not computed and injected consistently.	The nav supports badge display but the data wiring is still missing.	UI support exists, data wiring missing	Frontend + API	Blocks actionable navigation at a glance.
AM/PM normalization	All session and related time displays should use `AM/PM` consistently.	Current frontend time formatting still uses military time in existing session surfaces.	Observed current time formatting behavior and helper usage still produce 24-hour labels.	Not built	Frontend	Blocks consistent human-readable scheduling language.
Top-most error overlay	Global error presentation should render above the navigation shell and remain unmistakably visible.	Current global error rendering does not yet follow the planned top-most overlay behavior.	Current shell/error structure still allows errors to feel visually subordinate to nav chrome.	Not built	Frontend	Blocks clear recovery when page loads fail.
Check-in/check-out disabled control states	Unavailable check-in/check-out states should render as disabled grey controls, not passive text.	Current tutor sessions still use plain explanatory text in some cases rather than disabled buttons.	The current tutor sessions page does not yet fully follow the planned control-state design.	Partially built	Frontend	Blocks clear rule communication on session actions.
AJAX invalidation consistency	Mutations should refresh affected rows, counts, and lists without manual reload.	Some list and badge views still require a manual refresh after mutations.	Observed behavior and fragmented refresh patterns show mutation results do not always fan out immediately.	Partially built	Frontend	Blocks trustworthy real-time operational UX.
Legacy child intake duplication	Preferences should have one clean source of truth aligned with posting-level requirements.	Child-level intake still captures subject/timing preferences even though the newer direction is posting-level requirements.	The new child-create page is clean, but the separate child intake route still carries the older model.	Legacy flow still active	Frontend + Product	Blocks a clean single-source-of-truth for preferences.
`/admin/tutors` load reliability	Admin tutors should load reliably with explicit failure diagnostics and hardened empty/error states.	The admin tutors page still requires a live bug pass and explicit failure handling hardening.	Reported production behavior plus the current frontend dependency on the tutor-performance endpoint means this still needs direct diagnosis.	Not yet diagnosed	Frontend + API	Blocks core coordinator educator management.

Conservative Estimate Register

These estimates are the lower-bound effort view for one focused implementation pass. They are meant for sequencing, not for contractual scheduling.

Policy Gap Estimates

Gap	Conservative Time Estimate
Cancellation model by actor	4h
Missed session / no check-in model	2h
Amber vs red outstanding counts	1h
Admin dispute outcomes	3h
Tutor withdrawal after push / parent acceptance	1.5h
`Log Session` as first-class action	2h
Session review window and language	2h
Parent / tutor / coordinator session-surface split	3h
Child-level intake vs posting-level requirements	2h

Outstanding Decision-Row Estimates

Workflow Row	Conservative Time Estimate
Shortlist tutor	2h
Parent reviews pushed tutor	4h
Tutor withdraws before acceptance	3h
Tutor reviews proposed dates	4h
Parent pays trial invoice	6h
Trial completes and feedback recorded	3h
Parent acknowledges session happened	4h
Coordinator resolves dispute	6h
No check-in / missed session	4h
Tutor cancels future session	4h
Parent cancels future session	4h
Parent full profile visibility	3h

Implementation Capability Gap Estimates

Capability Gap	Conservative Time Estimate
Unified parent sessions surface	12h
Trial proposed items inside tutor sessions	6h
Appointment DTO enrichment	8h
Outstanding tab counts	6h
AM/PM normalization	2h
Top-most error overlay	2h
Check-in/check-out disabled control states	4h
AJAX invalidation consistency	6h
Legacy child intake duplication	5h
`/admin/tutors` load reliability	6h

What Is Not Missing

Area	Reason It Is Not Missing
The workflow itself	The workflow now has a source-of-truth document, a canonical matrix, an exhaustive transition matrix, and a decision-grade operational spec.
Sections and ownership	The planning doc now has explicit sections, per-item coverage, owners, decision status, and escalation notes.
A place to review the real gaps	This `/outstanding` page now contains the detailed policy gap register and the full outstanding decision rows rather than only a condensed summary.

Recommended Next Use

Use the detailed policy gap register to settle the remaining unresolved product-policy questions.
Use the outstanding decision-grade rows to see exactly which implementation-driving records are still open or provisional.
Once a row is decided, update both PRIORITY_PROJECT_EDITS.md and this JSON page together.
Then convert the now-decided rows into file-level engineering tasks across frontend_nivaa/ and workers_nivaa/.