workday: ship the two reads that could be verified, and say why the rest are not here

[jklaassenjc]

Workday import — 2 of the area's 9 operations. CLI and MCP behind internal/workday.

This is a smaller PR than the area deserves, and the reason is the point: the tenant probed has six directory integrations and none of them is Workday, so almost nothing here could be checked against real data.

What was verified, and is therefore what ships

GET /workdays returns a bare JSON array. Not {count}, not {results}, not {workdays} — an org with no integration returns []. Every sibling area in this API returns an envelope, so this is the fact most likely to be assumed wrong later, and it's the one pinned hardest.

The error shapes are correct. A well-formed id no integration has → 404. A malformed one → 400 invalid object id. Worth stating plainly, because the neighbouring Google EMM area (#145) does not behave this way: there, a fake enterprise id returns an empty device list.

What is not here, and why

The area also serves a workers listing and an import-results endpoint. Their response shapes have never been observed, so implementing them means writing a parser for a response nobody has seen.

Given this area's list endpoint already breaks the pattern its siblings follow, guessing would be a poor bet specifically here. Both are recorded in workday.Unprobed with what to do first, and a test fails if that map is emptied without the endpoints being implemented.

There is also no lookup by name — the record has never been seen with data in it, so which field holds a display name, or whether one exists, is not established. The id shape is checked locally instead, so a typo reads as a typo rather than as a server error.

The id question, recorded as an assumption

The spec names the path parameter {id} on some endpoints and {workday_id} on others. Whether that's a real distinction could not be established — with no integration there is nothing to address.

Google EMM advertised the same split and it turned out to be fiction, so the working assumption is one id. That assumption is written down in IsObjectID as an assumption, rather than buried inside a resolver where the next person would inherit it as fact.

Writes held back, and one deserves naming

POST /workdays/{id}/import carries the users scope: it creates and updates real directory users from HR data, and no dry run for it was found. That is not something to ship against an integration nobody can test.

Verification

go test ./... green, make verify-site clean, tool census 332, workday registered in classifications and schema.

Live: the list returns [] from both surfaces; a malformed id is refused locally with the same message from both; a well-formed unknown id reaches the API and 404s.

Refs KLA-485

🤖 Generated with Claude Code