[rachmo]

Closes #65. The skill has now been used for one real run, its dry-run outputs were checked against the approved table, and this PR fixes what it got wrong.

The run (2026-10-15)

It was a backfill of the 13 students who had been entered with only enough to get them into Slack, filled from the 2026-27 registration form's responses:

• Quiet pass: 171 cells (contact details, student details) and 46 skill rows.
• Live pass: 23 guardian rows, plus two name fixes the operator approved.

After each pass, the whole workbook was compared cell by cell with the download before it. Every intended cell held the approved value, and nothing else changed. The dry runs matched the plan:

• the quiet pass left plan identical to the baseline;
• the live pass moved grp-parents from 65 to 88, made 1 roster name update, and changed nothing else.

One pending grp-parents join turned out to predate the run.

What the skill got wrong, now fixed

• The full read. The Drive connector's read_file_content returns only each tab's header and first 10 rows; People has 80. Gate 1's completeness check caught it. The read is now an .xlsx download, read by the new read_xlsx.py (Python standard library only) from the session scratchpad and deleted afterwards. Completeness is checked against the plan's people count.
• Copying. Each block now goes on the operator's clipboard with pbcopy and is checked with pbpaste. Tabs copied out of a chat code block can turn into spaces.
• Fills. They go in rectangles over consecutive rows where every target cell is blank, checked by Person ID on the first and last rows. That took 11 pastes where one row at a time would have needed about 39.
• Verification. Each pass ends on a fresh download, compared with the previous one across the whole workbook.
• The baseline. It now also records /hawkmod lifecycle groups, so a join that was already pending isn't taken for the import's own.
• Names. No rule splits every name of three or more words, so each one is listed for the operator to confirm.
• Corrections. An existing value the operator decides is a mistake is corrected as a write of its own, and its check confirms the old value.
• Deploying. The skill now says to deploy before taking the baseline. Record a CORI Expiry for every emergency contact (#63) #68 and Import people onto the lifecycle sheet through gates (#65) #69 hadn't been deployed when the run started.
• mapping.md, Format E. It gains the columns the team added (CORI parent? holds the date a check was done, so it's a date to get and never an expiry), and the conventions the earlier rows followed: grade to year, skill synonyms, note wording.

The skill files were checked against every name, email and phone number in the sheet and the responses: none appears.

CORI expiry: three school years, ending 1 September

This rule was settled during the run. A CORI check covers the school year it was done in (July to June) and the next two, and its expiry is entered as 1 September after the third, about the first day of school. A check done over the summer counts toward the coming school year.

• Code. A summer check's expiry can therefore be up to two months past three years. hawk-mod used to read anything past three years as a typo, so a mentor checked in July would have lost access. The new latestCoriExpiry (rules/screening.ts) allows that 1 September, and is never earlier than three years, so nothing that was current before reads as a typo now. It replaces the plain bound in screeningStatus, mayHaveAccess and screeningEntryErrors.
• Docs. lifecycle-sheet.md §2 now says what "never calculated" meant all along: the sheet stores the expiry, which is what everything triggers on. The CORI rule is the one expiry worked out, and it's worked out when it's entered.
• Skill. The import skill shows each CORI expiry as a derived value, with its working.

Verification

npm run typecheck && npm test && npm run format:check pass (857 tests, 2 of them new, for the summer CORI bound).

🤖 Generated with Claude Code