verify-content: only interview sheets are checked; no enforcement for other generated documents

[teslamint]

Summary

verify-content checks one artifact type: an interview sheet. Every other generated document — résumé variants, career descriptions, screening reports, packet notes — has no automated check that its claims exist in the source corpus. The rule those documents must satisfy is written in AGENTS.md; nothing enforces it.

Current scope

src/careerkit/resume/cli.py:41-46:

verify_content = subparsers.add_parser("verify-content", help="Validate generated content against source evidence")
verify_content.add_argument("interview")
verify_content.add_argument("--resume")
verify_content.add_argument("--config")

The positional argument is interview. extract_claims() (src/careerkit/resume/application/verify_content.py:134) reads that one path. There is no equivalent entry point for a résumé variant or a generated report.

The rule with no enforcement

AGENTS.md states it directly:

Override content must not add technologies, roles, or achievements absent from base private/companies/ or private/profile/ files.

and enumerates the inflation classes to reject — role, verb, scope, architecture.

For interview sheets there is a command. For everything else the check is a human reading the document against the sources.

Why this is load-bearing

In one working session, three claims that had been identified as unsupported and removed from the sources earlier the same session reappeared in a generated report produced downstream. One of the reintroduced sentences contradicted itself in place: it asserted no direct experience with a metric and then cited that metric parenthetically as evidence.

Separately, a verb was widened during a style pass — a narrower implementation verb replaced with a broader construction verb — which is exactly the verb-inflation class AGENTS.md names. The sources had not changed; only the generated prose had.

Both were caught by reading the artifact. Neither would have been caught by any command in this repository.

The failure mode is specific: a term removed from the sources still exists in older generated artifacts, in prior submissions, and in an agent's or author's working memory. Removal from the source does not propagate to anything produced later that did not re-derive from the source.

Suggested direction

1. Accept a generic document path in verify-content, so any generated artifact can be checked against the résumé corpus rather than only an interview sheet.
2. Support a forbidden-term list in verify_content_config.json — terms previously removed as unsupported, which must not reappear in any generated document. A removal decision then becomes durable instead of surviving only in whoever made it.
3. Optionally, wire the check into career-resume build as a warning, so a build that reintroduces an unsupported claim says so.

Item 2 is the one that addresses the observed failure: the current design can express "this claim lacks evidence" only as an absence, never as a standing prohibition.

Related

Companion to #26 and #27 from the same session — all three are cases where the repository holds the information needed to catch a defect but no command surfaces it.