# Carebook source review and Workforce pilot handover — 2 October 2026

**Workforce is the pilot target.** The latest user direction states that Antonio has just migrated Carebook to Workforce. The separate Workforce workstream owns destination validation and final release. This document supplies the bounded Carebook source/security review, migration reconciliation inputs and acceptance handover; it does not recommend new Carebook pilot installations or establish that the reported migration succeeded.

This is a source-based review and checklist, not a deployment approval. The review date does not establish the meeting date or time. Carebook baseline: `ajamu/aximaapp_v2`, `main` commit `9671e0ed0e316031b4cb4774d155dd72b5663208` (merge of PR #370). Today's isolated source branch is `codex/carebook-pilot-isolation-20261002`; its validation is recorded below. Carebook fixes do not prove that the migrated Workforce workflows pass.

## Product identity and scope

| Product | Verified repository and implementation | Pilot boundary |
| --- | --- | --- |
| Carebook | Private [ajamu/aximaapp_v2](https://github.com/ajamu/aximaapp_v2), default branch `main`. [composer.json](../composer.json) requires Yii2 `~2.0.45`; [config/web.php](../config/web.php) names Carebook; [web/manifest.json](../web/manifest.json) names Axima Carebook. | Legacy migration source, not the current pilot target. This checkout has not been converted to Laravel. Its mobile interface is Yii views and a PWA manifest, implemented by [MobileController](../controllers/MobileController.php). |
| Axima Workforce | Private [ajamu/axima-workforce](https://github.com/ajamu/axima-workforce), Laravel `^13.17`, PHP `^8.3`, Inertia/Vue and Sanctum in its current main `composer.json`. | Separate application with organization tenancy and a dedicated Care Clients workspace. Care recipients and commercial billing clients have different meanings. |
| Axima Workforce Mobile | Private [ajamu/axima-workforce-mobile](https://github.com/ajamu/axima-workforce-mobile), Vue 3 / Capacitor 8. | Uses the Workforce API. This is not evidence of a Carebook native client. Current release documentation covers Android; an iOS project is not evidenced. |

No separate repository named Carebook, or Carebook branch named Laravel/Capacitor, was found in the authorized repository searches. This is a discovery result, not a claim that no other private implementation exists.

## Source findings and destination evidence gaps

1. **Carebook has no proven shared-database organization isolation.** No organization/tenant model or organization/tenant key was found in its first-party models, controllers or migrations. Role checks and staff/client ownership do not provide organization tenancy. This is a source-side limitation, not a finding about Workforce. Do not put the three pilots into a shared Carebook database; validate their destination organization boundaries in Workforce.
2. **Production release state is unverified.** Workforce [PR #175](https://github.com/ajamu/axima-workforce/pull/175) documented stale served frontend assets and local server source changes. Merged code does not establish which commit, assets or workers are running today.
3. **Legacy credential configuration requires remediation.** Carebook's committed database configuration contains a credential. Do not copy or reuse it in Workforce. Move any retained source deployment secrets to private configuration, replace any affected live credential through its authorized owner, and check repository history and logs for exposure. No credential values are reproduced here and no live credential was changed during this review.
4. **Source schema and synthetic seed data need reconciliation.** There are 63 Carebook migrations at the baseline. [The historical shift-deletion migration](../migrations/m250226_000000_delete_shifts_from_oct25.php) is now a no-op, but [the sample-data migration](../migrations/m250909_000110_insert_sample_data.php) still inserts fabricated facilities, rooms, beds and clients. Identify any seeded records in the migration reconciliation rather than treating them as real clients. A source rebuild/re-export, if separately selected, needs a disposable rehearsal; do not blindly migrate a customer database.
5. **Native acceptance is incomplete.** Workforce Mobile's latest reviewed [PR #40](https://github.com/ajamu/axima-workforce-mobile/pull/40) leaves physical-device offline/force-stop and native push checks open. Its [CI run](https://github.com/ajamu/axima-workforce-mobile/actions/runs/36528150919) has failed quality and Android jobs without executed steps/logs; the PR records an Actions budget startup blocker. Today's release must obtain its own evidence.
6. **Carebook guides are not destination acceptance evidence.** Existing operation guides describe intended journeys but are not proof that every action works or transferred into Workforce. The source baseline has no first-party `.github/workflows` automation; workflows inside committed dependencies are unrelated.
7. **Legacy intake can leave partial records at the reviewed baseline.** `ClientController::actionCreate` saves related client/profile/contract/care records without one enclosing transaction and does not check every related save result. Attachment failure is surfaced as a flash message. Check migrated records for missing related data; this unresolved source workflow must not be reported as a Workforce defect without destination evidence. It needs repair and failure/rollback tests only if continued source intake is separately selected.

## Workforce meeting walkthrough to validate with the destination owner

Use a synthetic Workforce organization with outbound mail disabled/captured. If Antonio's migrated organization contains real care data, inspect it only through separately authorized private reconciliation; do not display those records in the meeting demo.

1. Confirm the correct organization and role, then show the operations/schedule overview with synthetic work.
2. Open **Care Clients**; show a synthetic profile, assigned worker and imported-history example. Demonstrate that care recipients are distinct from commercial contracts. Availability and counts of the real imported records remain private acceptance checks.
3. Show a synthetic shift linked to the appropriate care client, worker and site; validate publish/acceptance/coverage behavior in the destination's current UI.
4. As the assigned worker, demonstrate permitted care-note entry and an append-only correction, then prove an unrelated worker cannot access that client or its documents.
5. Demonstrate the selected attendance → review → timesheet/report workflow on web and, where supported, the matching Workforce mobile build. Record web handoffs and any incomplete native steps explicitly.
6. Show captured notification state and delivery health. Native push/inbox receipt remains a separately authorized acceptance test, not a claim established by queued state.
7. Finish with reconciled migration counts and the remaining pilot gates below. Do not rerun the completed migration or promotion simply to make a demo screen look populated.

These destination steps require validation by the Workforce workstream; this source checkout cannot execute or certify them.

## Legacy synthetic walkthrough for source diagnosis only

The following routes document implemented Carebook source behavior for fixture/reconciliation work. They are not the intended pilot demonstration or a recommendation to operate a new Carebook installation. Execute only if the destination owner needs a synthetic comparison or exporter fixture.

Use only a disposable local or approved staging database, fabricated identities and `.test` email addresses. Set Yii mail to file transport before any action that can notify: shift creation calls `ShiftMailer` automatically. Disable outbound transport and reminder cron in the demo. Do not connect production databases, send invitations, publish real shifts, collect real signatures or create live access grants. Use separate browser profiles for roles, and clearly label the demo as synthetic.

Pre-stage `Demo Client A`, `Demo Client B`, `Demo Provider A`, `Demo Provider B`, a scheduler/administrator, a linked demo client account, one site and one shift. Keep unrelated Client B/Provider B records to prove denied access. Record the generated IDs privately; the placeholders below are not production identifiers. Avoid unsupported claims about messaging, payments or clinical functionality based only on prose in `operations.md`.

Routes below are Yii route IDs; use the URL generated by the running app (for example `index.php?r=client/view&id=<demo-client-id>`), not an assumed pretty-URL configuration.

| Step | Role and implemented path | Evidence to capture |
| --- | --- | --- |
| 1. Sign in and orient | `site/login`, then `site/dashboard`; [SiteController](../controllers/SiteController.php). | Correct role landing page, useful empty states, role-appropriate navigation. |
| 2. Register the care recipient | Scheduler/administrator: `client/create`, `client/view`; [ClientController](../controllers/ClientController.php). The combined form includes Client, Location, Profile, Contract, ADLs and CarePlans. Keep portal invitations disabled. | Required-field errors, saved synthetic demographics and related records, refresh persistence. Supply location name/address/city/state/postal code and at least one valid ADL/care plan; the baseline's blank fallback models do not make these optional. |
| 3. Review care context | Review the saved client care context; authorized administrator may use `care-plan/view`/`care-plan/create`; [CarePlanController](../controllers/CarePlanController.php). Add synthetic notes through `note/create`; [NoteController](../controllers/NoteController.php). | Saved care context, note visibility and expected role boundaries. |
| 4. Schedule care | Scheduler/administrator: `shift/create`, then `shift/calendar2` or `shift/kanban`, and `shift/view`; [ShiftController](../controllers/ShiftController.php). Assign only the synthetic provider/client. | Correct times, client, worker and assignment state; validation for overlap/invalid references. Automatically generated notifications stay in file capture. |
| 5. Provider review and response | Provider A: `care-provider-schedule/upcoming`, `care-provider-schedule/detail`, POST `care-provider-schedule/respond`; [CareProviderScheduleController](../controllers/CareProviderScheduleController.php). | Accept/decline state persists; decline requires a comment. Provider B cannot read/respond to Provider A's shift. |
| 6. Care work | Provider A: `care-provider-shift/view`, POST `care-provider-shift/update-tasks` and `care-provider-shift/add-note`; [CareProviderShiftController](../controllers/CareProviderShiftController.php). | Task state and synthetic handover note persist; unrelated task/client IDs are rejected. |
| 7. Clock and phone view | `mobile/shifts`, `mobile/shift-view`; [MobileController](../controllers/MobileController.php). Use existing clock controls backed by [ClockEntryController](../controllers/ClockEntryController.php). | Own shift only, duplicate/action errors, start/end timestamps, 390px readability. This proves the Carebook web/PWA path only. ClockEntry is separate from Attendance; do not claim this step alone feeds timesheet totals. |
| 8. Timesheet handoff | Administrator: `attendance` CRUD and `timesheet/create` using synthetic Shift/Attendance records. Provider A: `care-provider-timesheet/index`, `view`, POST `submit`; [CareProviderTimesheetController](../controllers/CareProviderTimesheetController.php). Administrator: `timesheet/view`, POST approve/reject, CSV/PDF. | A draft/rejected synthetic sheet submits once; approved/other-worker records cannot be changed. Verify totals against Attendance or the scheduled-shift fallback. Attendance CRUD is restricted to administrative roles; do not promise provider check-in through AttendanceController. |
| 9. Access denial | Repeat view/edit/API/export requests as Provider B and the unrelated client account. | Server-side 403/404 or scoped result, no leaked names/care text/files, and no database mutation. Hidden navigation alone is insufficient. |

Legacy route/source review is complete; live browser execution, screenshots and per-step results remain unverified here. Any executed source comparison must be labeled separately from the Workforce demonstration.

## Conditional checks if the legacy source remains in service

These are source maintenance/reconciliation checks, not prerequisites to deploying a fresh Carebook pilot. The current goal is a successful Workforce pilot.

- [ ] Confirm the retained source's existing isolation, secrets, storage, backups and logs; do not add the other pilot organizations to its database.
- [ ] Test SuperAdmin, Scheduler, Client Manager, CareProvider and linked client access against current `User` role definitions. Deny unsupported roles explicitly. Cover lists, details, writes, JSON APIs, exports and files.
- [ ] Prove worker/client ownership and foreign-reference rejection for clients, shifts, tasks, care plans, notes, clock entries and timesheets; include unrelated and nonexistent IDs.
- [ ] Recheck access after reassignment, client-link removal and logout/session expiry. Inspect client/family/internal-note visibility separately.
- [ ] Complete intake → care plan → scheduling → response → task/note/clock → timesheet review using synthetic data. Test validation errors, repeated submits and empty results.
- [ ] Verify timezone, overnight shifts, recurrence boundaries, overlaps, cancellation/decline and sickness handling for the functions selected for the pilot.
- [ ] Validate clock totals separately from timesheet/report outputs against known synthetic timestamps. Timesheets use Attendance or a scheduled-shift fallback, not an assumed ClockEntry bridge; check approved records remain protected.
- [ ] Check desktop and phone layouts, keyboard/focus behavior, visible form errors, required fields, loading/error/empty states and refresh persistence.
- [ ] Verify authentication/session configuration, HTTPS, CSRF/HTTP verbs and production error handling. Inspect browser console/network responses without capturing secrets or health data.
- [ ] Confirm notification recipients and triggers with local capture; prevent duplicate and unrelated-recipient messages. Live delivery is a separate authorized staging test.
- [ ] Rehearse a fresh install and upgrade on disposable data, inspect seed/sample behavior and pending migrations, and perform a backup restoration test.

## Workforce and mobile pilot acceptance

Workforce is a separate release. Use its own tests and [deployment guide](https://github.com/ajamu/axima-workforce/blob/main/docs/deployment.md); do not transfer Carebook test results to it.

- [ ] Record the backend/mobile source commits, API environment, build checksums and approved organization memberships. Demonstrate cross-organization isolation and immediate access revocation in web and API requests.
- [ ] Test owner/admin, scheduler, supervisor, worker, finance and client-viewer boundaries; verify supervisor site/team scope and organization switching with in-flight requests.
- [ ] Validate required scheduling, coverage, client requests, attendance/corrections, timesheet approval and notification journeys against the matching API version. Mark web handoffs and unavailable native features honestly.
- [ ] For [Care Clients](https://github.com/ajamu/axima-workforce/blob/main/docs/care-clients.md), deploy the `2026_10_01_090000_create_care_client_workspace` migration and assets, then verify assigned-worker access, supervisor scope intersection, append-only amendments, encryption/private downloads, revoked assignments and foreign references. Finance, scheduler and client viewer do not receive care-workspace access.
- [ ] Install durable queues and the dedicated `legacy-migrations` worker before imports/backfills. The documented timeout is 1,800 seconds with retry/visibility at least 1,860 seconds; normal minute scheduler cron does not consume these jobs. Confirm other notification/operational workers and scheduler health independently.
- [ ] Run mobile `npm ci`, `npm run check`, `npm run build`, `npm run build:android:production`, native drift check, `npm run android:assemble:debug` and `npm run android:bundle:release` from the reviewed commit. Resolve failed or unexecuted CI gates.
- [ ] Confirm the exact approved HTTPS API origin in the bundle. Test the same checksummed APK on Android 13+ and a current Samsung device, including upgrades, cold start, force-stop/relaunch, Android Back, GPS accepted/denied, offline paired punches/retry/idempotency, expired session and account/organization changes.
- [ ] Test push accepted/denied and in-app notification navigation. Missing Firebase configuration can intentionally disable native push; a successful build does not prove delivery.
- [ ] Complete 320–412px and 100–200% text-scale checks. Follow the full [mobile UAT and signing/Play release checklist](https://github.com/ajamu/axima-workforce-mobile/blob/main/docs/mobile-production-readiness-uat.md) before any distribution. A native iOS release is not part of the evidenced implementation.
- [ ] Keep agreement-signature work separate: Workforce [PR #180](https://github.com/ajamu/axima-workforce/pull/180) is already merged and owned by a separate workstream. This Carebook review neither validates nor modifies its rollout.

## Migration acceptance, if explicitly selected

The implemented source contract is [schema-v1 Workforce JSON](migration/WORKFORCE_JSON_EXPORT.md), exported by a Carebook SuperAdmin. The proposed `.axima` archive contract is a separate design; renaming ZIP/SQL files does not make them compatible.

- [ ] Use the actual exporter with synthetic records first; verify integrity, optional-table warnings, complete counts and credential exclusions.
- [ ] Confirm destination chunk upload/preview uses current assets, not the old whole-file uploader. Deploy the matched fixes from Workforce [#174](https://github.com/ajamu/axima-workforce/pull/174), [#175](https://github.com/ajamu/axima-workforce/pull/175), [#176](https://github.com/ajamu/axima-workforce/pull/176) and Carebook [#370](https://github.com/ajamu/aximaapp_v2/pull/370) where required by the deployed baseline.
- [ ] Reconcile `source count = operational + archived + rejected` for every entity; inspect timezone, rates, placeholders, duplicated staff emails and attendance conflicts. Include `shift_tasks`, `adls`, `care_plans`, `attendance`, `clock_entries`, `notes` and `shift_notes`; verify the same checklist and notes remain attached to each migrated shift/client. Today's source checklist patch prevents future destructive updates but does not repair historical records. Review imported rates/credentials rather than treating imported values as verified.
- [ ] Compare a known synthetic schedule/attendance/clock example with destination totals. Source timesheets use Attendance or a scheduled-shift fallback, not ClockEntry; confirm the destination's hours provenance and conflict handling instead of assuming these sources are interchangeable.
- [ ] Keep care recipients separate from commercial billing contracts. Validate explicit source identities and protected history; never match people solely by name.
- [ ] Transfer required file binaries separately: source JSON contains database records/paths, not the underlying files. Verify private access after transfer.
- [ ] Existing Workforce tenants require an authorized administrator's explicit Care Clients promotion/backfill action. Confirm idempotency, requesting-admin reauthorization and sanitized failure/retry behavior.
- [ ] Obtain a separate cutover decision covering source-write pause, protected transfer, retained backup, reconciliation owner and rollback. This checklist does not authorize a live export/import or database migration.

## Deployment decision and rollback record

- [ ] Confirm Workforce organization boundaries, selected mobile scope, acceptance owner and the exact approved destination commits.
- [ ] Reconcile server-local changes without overwriting them; compare deployed PHP and asset manifests with the reviewed build. Verify clean release input and correct branch.
- [ ] Confirm supported runtime/extensions, private secrets, storage permissions, HTTPS/session settings, durable jobs, scheduler and notification capture/transport configuration.
- [ ] Take an authorized backup and prove restoration; review migration effects and prepare code/database rollback together.
- [ ] Deploy only after separate authorization, run the synthetic role smoke path and health checks, and record screenshots, checksums, errors and remaining limitations.
- [ ] Assign an incident/rollback owner and a support contact for each organization. Approve any store/internal distribution and live notification acceptance separately.

No production deploy, production migration, customer-data change, real invitation/email, real signature, new live grant or purchase was authorized or executed as part of this review. Existing Graxana/CRM work and other branches are outside this change.

## Evidence and current validation record

Historical evidence below is attributed to merged PRs; it was not rerun by the repository-context review:

| Source | Recorded evidence and limits |
| --- | --- |
| Carebook [#370](https://github.com/ajamu/aximaapp_v2/pull/370), merged 1 October | 12 exporter tests / 61 assertions; 78 MB synthetic export under a 32 MB PHP limit; synthetic exporter-to-Workforce import. This is exporter coverage, not whole-app acceptance. |
| Workforce [#176](https://github.com/ajamu/axima-workforce/pull/176) | 43 migration tests / 321 assertions and 17 upload/status tests; full CI reported passing. Production deployment and real migration excluded. |
| Workforce [#177](https://github.com/ajamu/axima-workforce/pull/177) | 602 backend tests / 5,215 assertions; 62 mobile API tests / 514 assertions; 75 frontend tests; synthetic care/import browser checks. Its migration and workers remain deployment prerequisites. |
| Mobile [#40](https://github.com/ajamu/axima-workforce-mobile/pull/40) | 180 local mobile tests and quality/build checks reported passing; hosted jobs did not execute. Physical-device offline/force-stop and native push remained open. |

Today's repository-context checks: verified repository metadata/branches/PRs, stack manifests, Carebook baseline commit, first-party mobile/tenancy/migration source and the mobile CI job startup state. No first-party `AGENTS.md` was found in this checkout. Local `.codex/memories_1.sqlite` was opened read-only: its `stage1_outputs` table had zero rows, so no Axima/Carebook saved memory summary was available.

Today's implementation/testing record:

- Scope: isolated Carebook source branch; API access, care-provider client access, transactional checklist completion, user serialization and migration-export regression coverage. No Workforce code or tests were executed by this workstream.
- Runtime: PHP **8.4.19**, PHPUnit **9.6.29**. Command: `php vendor/bin/phpunit -c phpunit-safety.xml --log-junit tests/_output/pilot-safety.xml` using the isolated runtime. The combined run passed **95 tests / 299 assertions**.

| Today's suite | Result |
| --- | --- |
| Shift API access | 41 tests / 116 assertions passed |
| Care-provider client access | 21 tests / 41 assertions passed |
| Checklist completion | 18 tests / 72 assertions passed |
| User serialization | 3 tests / 9 assertions passed; the original baseline reproduced 3 failures before the branch fix |
| Workforce migration exporter | 12 tests / 61 assertions passed |

- Checklist coverage includes validating the entire payload before replacement, rejecting duplicate/foreign-client ADLs, and transaction rollback when a later save fails. These fixes do not repair existing source or migrated records.
- Browser/demo execution: **not performed**. There are no new browser screenshots or end-to-end claims from this workstream.
- The Codeception functional route expectation was updated but **not run**; execution needs a safely configured dedicated test database. The passing PHPUnit safety suite is not the full Carebook functional suite.
- Remaining acceptance: Workforce migrated-record reconciliation, its organization/RBAC and selected workflows, deployed commit/assets/workers, notification delivery, and mobile device/native release checks remain with the destination owner. Legacy partial intake saves remain an unresolved source limitation if source intake continues.
- Source branch review: [`codex/carebook-pilot-isolation-20261002`](https://github.com/ajamu/aximaapp_v2/tree/codex/carebook-pilot-isolation-20261002), based on the baseline recorded above. Destination reviewer/acceptance owner: the separate Workforce workstream; record a named organizational approver before release.

Until these entries and the applicable acceptance checks are complete, describe this deliverable as a source review and handover. Workforce pilot approval requires the destination owner's recorded validation of the migrated organization and selected workflows.