# Autopilot Decisions Log This log records every documented decision made during unattended (autopilot) work, per Section 10 of `documentation_standard.md`. Each entry states the ambiguity, the decision made, the rationale, and where it applies. Entries are for user review; changes are applied only after user review and direction. Status: **LIVE** — appended to whenever a genuine ambiguity is resolved during autopilot work. --- ## Decision Log ### AD-001 — Pre-existing duplicate test IDs in `user_login_tests.md` (Module 1, group 1) - **Date:** 2026-09-14 - **Ambiguity / bug found:** During the one-time `TC-SA-` prefix rename, a pre-existing ID-scheme bug was detected in `super_admin/authentication_access/user_login_tests.md`. The file (feature group 1) used group digits 01–04 (one per feature: `TC-01-01-001..031`, `TC-01-02-001..028`, `TC-01-03-001..020`, `TC-01-04-001..019`) instead of a single continuous group-1 sequence. This created 67 duplicate IDs that collided with the legitimate IDs of `account_verification_tests.md` (group 2), `two_factor_authentication_tests.md` (group 3), and `password_management_tests.md` (group 4), violating the locked rule that test IDs are unique across the repository. - **Decision:** Renumbered `user_login_tests.md` to the correct continuous scheme `TC-01-01-001..098` (feature 1.1 = 001–031, 1.2 = 032–059, 1.3 = 060–079, 1.4 = 080–098), updating both the `### TC-` headers and the Coverage Matrix rows. All other 145 test files were verified correct and untouched (except the global `TC-SA-` prefix rename). - **Rationale:** The locked ID scheme is `TC----` — the group digit must equal the feature group number (1 for user_login), and the sequence is continuous within the group. This matches the scheme used in all other 145 files. - **Where it applies:** `super_admin/authentication_access/user_login_tests.md` only. - **Verification:** After the fix, all 4,280 Super Admin test IDs are unique (4,280 headers = 4,280 unique), 0 duplicates remain. ### AD-002 — Module lists derived for the 4 new user types (from the PDF) - **Date:** 2026-09-14 - **Ambiguity:** The PDF does not present a single explicit "module list" per user type; features are spread across Section 1 (User Management System), Section 4 (Core Learning Features), Section 5 (Target Exam), Section 6 (Parental Insights), Section 7 (Additional Recommended Features), Section 9 (Mobile App), Section 10 (AI Study Companion), Section 11 (Affiliate Advanced), Section 12 (Training Institute Enterprise), and the User Journey narratives. A judgment call was needed to group these into modules per user type, mirroring the Super Admin module structure. - **Decision:** Derived the following module lists (in dependency order), scoped to Phases 1–4 and EXCLUDING the locked exclusions (AI Mentor Mode, virtual study rooms, voice notes, AR/VR, exam hall simulator, white-label/enterprise): **Student (15 modules):** 1 Authentication & Account Setup, 2 Profile Management, 3 Course Access & Learning, 4 Assessment & Practice, 5 Learning Tools, 6 Target Exam Feature, 7 Subscription Management, 8 Progress & Analytics, 9 Gamification & Engagement, 10 Social Learning, 11 Live & Interactive Sessions, 12 Offline Learning Support, 13 Mobile App Features, 14 AI Study Companion, 15 Notifications & Alerts. **Parent (10 modules):** 1 Authentication & Account Setup, 2 Child Account Linking, 3 Child Monitoring Dashboard, 4 Parental Insights & Performance Analysis, 5 Parental Controls, 6 Parent-Teacher Communication, 7 Parent Reports & Alerts, 8 Subscription & Billing Management, 9 Parent-Student Collaboration, 10 Notifications & Preferences. **Affiliate (9 modules):** 1 Authentication & Account Setup, 2 Affiliate Dashboard, 3 Referral & Marketing Tools, 4 Sales & Commission Management, 5 Multi-Tier Commission Tracking, 6 Performance-Based Incentives, 7 Marketing Automation, 8 Affiliate Training & Resources, 9 Notifications & Preferences. **Training Institute (9 modules):** 1 Authentication & Account Setup, 2 Institute Dashboard, 3 Bulk License Management, 4 Student Management, 5 Billing & Licensing, 6 Advanced Institute Analytics, 7 Integration & APIs, 8 Custom Learning Paths, 9 Enhanced Support. - **Rationale:** Each module groups related PDF features for one user type, mirroring the Super Admin module granularity (a module = a coherent cluster of feature groups). Excluded features (per the locked standard) were omitted. Module counts are estimates; feature groups within each module are defined as the work proceeds. - **Where it applies:** `student/`, `parent/`, `affiliate/`, `training_institute/` master lists and all subsequent module work. - **Review note:** User to confirm/adjust module groupings during review. ### AD-003 — Test-generation depth for the 4 new user types (one test per sub-feature + one matrix row per sub-feature and per rule) - **Date:** 2026-09-14 - **Ambiguity:** The Super Admin corpus is not uniform. Modules 1–15 use a verbose feature-file style (9–13 sub-features per feature) with a test file that has one test per sub-feature plus a Coverage Matrix row for every sub-feature AND every rule (e.g., `user_login_tests.md` = 98 tests, 14-row matrix per feature). Modules 16–24 use a condensed style (8 sub-features per feature, 8 tests, 14-row matrix). The locked standard's Coverage Matrix rule ("a row for EVERY sub-feature AND every rule") is the binding invariant; the 8-test pattern of M16–24 is a by-product of their 8-sub-feature feature files, not a separate rule. - **Decision:** For the 4 new user types, keep the feature files at the same verbose depth as Super Admin M1–M15 (9–12 sub-features per feature, last sub-feature = "Audit logging of the X"). Generate the test file with **one test per sub-feature** (sequence continuous within the group file), and a Coverage Matrix with **one row per sub-feature plus one row per rule** (each rule row reuses the test ID of the sub-feature it folds into). Test ID scheme is `TC----` where the group digit is the group's ordinal position in the module's slim index and the sequence is continuous across all features in the group file. - **Rationale:** This satisfies the locked Coverage Matrix invariant exactly and matches the established, verified Super Admin M1–M15 depth, so the new user types are directly comparable to the existing corpus. It is the most conservative (highest-coverage) reading of the locked standard. - **Where it applies:** All test files for `student/`, `parent/`, `affiliate/`, `training_institute/`. - **Review note:** If the user prefers the condensed M16–24 style (8 sub-features / 8 tests per feature) for the new user types instead, the feature files and test files can be re-condensed in a single pass. ### AD-004 — Unrelated `Laravel/api_hub` project swept into Affiliate M7 commit - **Date:** 2026-09-18 - **Ambiguity / bug found:** While committing Affiliate M7, the standing `git add -A` rule swept in a `Laravel/api_hub/` Laravel project (60+ files, created 2026-09-18 11:43, i.e. during this session but NOT by this agent) and an empty `Flutter/` folder. These are unrelated to the documentation task and were committed as part of `1d6e739` (Affiliate M7). - **Decision:** Left the files in the repository as committed (no history rewrite, no deletion) and continued the documentation work. The Affiliate M7 documentation files themselves are correct and verified (101 unique `TC-AF-7-` tests, all invariants pass). - **Rationale:** Deleting or rewriting history for files the user (or another tool) may have intentionally added would be destructive. The safest non-destructive action is to document and continue; the user can decide whether to keep, move, or remove `Laravel/` and `Flutter/`. - **Where it applies:** Commit `1d6e739` only. All subsequent commits use `git add -A` per the standing rule; if the user wants the documentation repo kept separate from code, they should say so and I will switch to path-scoped adds (e.g. `git add affiliate/`). - **Review note:** User to confirm whether `Laravel/api_hub` and `Flutter/` belong in this repository. ### AD-004 (update) — External process committing to this repo concurrently - **Date:** 2026-09-18 - **Update:** A second external process (creating `Laravel/backend_ui/`) pushed commit `8063929` between my TI M6 and M7 commits. That commit also swept in the TI M7 feature files + slim index (its message references the TI M7 docs), so my M7 commit `8f2258c` contained only the 4 test files. Verified: all 8 TI M7 files are tracked, working tree clean, no data loss. The `Laravel/` scaffold (now `api_hub/` + `backend_ui/`) remains in the repo pending user decision (see AD-004 above). ### AD-005 — Environment setup: api_hub MySQL database name - **Date:** 2026-09-18 - **Ambiguity:** The user directed switching `api_hub` to MySQL (user `root`, password `admin123`) and creating the database, but did not specify a database name. - **Decision:** Used `api_hub` as the database name (matches the app folder name). `Laravel/api_hub/.env` set to `DB_CONNECTION=mysql`, `DB_DATABASE=api_hub`, `DB_USERNAME=root`, `DB_PASSWORD=admin123`. `.env.example` mirrors this with an empty `DB_PASSWORD` (no secrets in the committed example). - **Rationale:** `api_hub` is the least-surprising name for the database that backs the `api_hub` app. - **Where it applies:** `Laravel/api_hub/.env`, `Laravel/api_hub/.env.example`. - **Review note / BLOCKER:** The MySQL server currently **rejects** `root`/`admin123` (ERROR 1045 access denied), so the database has NOT been created and migrations have NOT run. The user must set the `root` password (or provide working credentials) interactively, then run `php artisan migrate` in `Laravel/api_hub`. If a different DB name is preferred, update `DB_DATABASE` in `.env`. ### AD-006 — Environment setup: backend_ui Vue 3 SPA + path-scoped commit - **Date:** 2026-09-18 - **Ambiguity:** (a) `backend_ui` is stock Laravel 12 with no Vue; the user asked for "Vue 3 + standard Laravel-Vue wiring, plain Vue 3 SPA". (b) At commit time, two unrelated files (`Documents/super_admin/admin_ui_screen_1_command_center.md`, `admin_ui_screen_2_academic_content_studio.md`) appeared from an external process (same pattern as AD-004); the standing `git add -A` rule would have swept them into the environment-setup commit. - **Decision:** (a) Installed `vue@3`, `vue-router@4`, `pinia`, `axios`, and `@vitejs/plugin-vue`; added `resources/js/App.vue`, `router/`, `views/`, `api/` (axios client), a `spa.blade.php` shell, and pointed `routes/web.php` `/` at it. Added `api_hub_url` to `config/app.php` (env `API_HUB_URL`, default `http://localhost:8000`) injected into the SPA via `window.__API_HUB_URL__`. Moved `backend_ui` to port 8001 (api_hub owns 8000) and switched its session/cache/queue drivers to file/sync (no DB). (b) Committed **path-scoped** (only the environment-setup files) instead of `git add -A`, leaving the two unrelated `super_admin` files uncommitted. - **Rationale:** Plain Vue 3 SPA (no Inertia) matches the API-first architecture — `backend_ui` has no DB and talks to `api_hub` over HTTP only. Path-scoped add avoids committing another process's in-progress work. - **Where it applies:** `Laravel/backend_ui/` (Vue wiring, config, routes, `.env`/`.env.example`), commit `257b396`. - **Review note:** The two `Documents/super_admin/admin_ui_screen_*.md` files remain uncommitted pending user direction. If the standing `git add -A` rule should resume, the user should confirm.