# Diary — 2026-06-03 (Adi)

User: adi (Adi Pramono), lead developer. My progress and thinking for the day.

## The key idea I want captured: build approach

How we split the migration work between scripted import and human building:

- Record-based content — courses, blog posts, staff bios, photo library, livestream entries — goes in by
  scripted DB import. It's structured, so deterministic ETL is faster, cheaper, and more consistent than
  hand-building. Hand-keying 700+ blogs / 168 bios / 141 courses would blow the budget.
- Pages are built by humans (juniors). The real reason is QA / human eyes: hand-building puts a person on
  every page as it's made, reviewed against the live site during construction, catching layout/parity/
  content issues an automated migration would carry through silently. Layered review: junior builds →
  Zeina reviews → I (Adi) do final QA.
- The per-page featured-image / Hero Media variance (slider / static / YouTube / MP4) is NOT the
  justification — a script could probably handle it; it's just that since pages are hand-built anyway, the
  person sets the right hero in the same pass.
- AI/Claude is behind-the-scenes tooling (extractor, transforms, redirect map, QA scanning) — not the
  page-builder.

(Also recorded in `PLAN-INTERNAL.md` → "Build approach", and in Claude memory.)

## What I did today

- Built the full 10-week plan doc set:
  - `10-WEEK-PLAN.md` — executive / client-facing plan.
  - `PLAN-INTERNAL.md` — team plan (assignments, critical path, Pages deep-dive).
  - `TASK-BREAKDOWN.md` — 104-item backlog (E0–E14).
  - `TASK-TRACKER.md` + `task-tracker.csv` — status board, burn-down, burn log, export.
  - `manual-thought-on-web-dev.md` / `.txt` — my block plan (~6–8 consolidated custom blocks from the PDF survey).
- Polished the exec plan: team by role (no AI mention — our private tool), no emojis/bold, added a
  "What we need from Brentwood" column, named Week 8 as buffer, flagged that Aug 1 is a Saturday (confirm
  weekend vs weekday launch), added the change-control note (route changes through Rian), and surfaced the
  editor-friction (roles + approval) and performance/backups work that were missing.
- Reviewed the plan twice (once through Rian's lens) and tightened it.
- Looked at `mysql-data/brentwood`: all 51 Laravel tables are present (raw InnoDB). Conversion to WP is
  feasible via the extractor — content only, NOT users / password_resets / tokens.

## Worry / operational note: my permissions are limited

I'm a developer on this server, not the owner — limited permissions (no sudo, no direct docker, can't
reach the Laravel DB directly, owner-only paths are off-limits). At some point the bulk/elevated tasks
will exceed what I can run myself: DB access for the Week-1 counts and the extractor, exposing the Laravel
MySQL, container-level operations, broad migration scripts, anything under owner-only paths.

Plan for those: rather than me forcing it (and rather than bending the server's strict security model),
Claude + I draft the request and the exact, ready-to-run commands, and ask Rian (owner) to execute them.
Keep each request self-contained so Rian just runs it and reports back. Especially applies to: reaching
the Laravel DB, any docker/sudo-level step, and anything in owner-only areas.

## Next steps (Adi)

- Test the DB import for Courses and Blog posts myself first — not sure it'll work at my permission level,
  but worth a try. If it doesn't work, ask Rian for help.
- Confirm the total number of pages from the database.
- In my other sheet I'm scoping only the frontend (public) pages for now — the aim is to reduce the load
  of pages that need manual hands and eyes, since those are the ones humans are best placed to do at this
  level / point in time.