Keeping application approval tied to the facts reviewed.

THE WORK

The project.

Career Application Agent gives application preparation a revision history. A pack records the profile, CV and destination it was prepared for, and approval belongs to that exact combination. If a fact is corrected or a newer CV replaces the old one, the local service requires another review before the pack can move on.

The TypeScript MCP core also records attempts without treating an uncertain outcome as permission to try again. Starting an attempt, consuming approval and updating the pack happen in one saved mutation, with idempotency checks for retries. These are local preparation and recordkeeping capabilities: the core has no employer-submission client.

IMPLEMENTATION

Design choices.

1. Approval follows the reviewed facts, not just the pack's status. The service checks the latest profile and CV even when the pack text hasn't changed, and limits approval to a thirty-minute window. A later factual correction therefore requires review again.
2. One mutation starts the attempt and consumes its approval. Matching STARTED, SUBMITTED or UNKNOWN records block another attempt, so an unresolved result stays unresolved until it is reconciled rather than quietly becoming a retry.
3. An idempotency key covers the full semantic request, including attribution and revision preconditions. Exact replay returns the original result digest without repeating the change; different input under that key conflicts. Receipts retain digest metadata instead of private result contents, which callers retrieve through a separate read.
4. One encrypted file keeps the storage model compact, but encryption cannot distinguish the newest valid file from an older valid copy restored after restart. An external store identity and revision anchor are still needed before external submission could depend on this state.
5. Employer-side execution stays outside the MCP core. Local validation can check record shape and allowed transitions; it cannot independently verify a browser's field mapping or the origin of a receipt. Those checks need their own implementation before employer-side writes are enabled.

HOW IT FITS TOGETHER

Architecture.

• Nine workflow skills guide preparation through a 29-tool STDIO MCP core. Zod validates requests before domain logic records listing identities and immutable profile, CV and pack revisions. Fit and evidence coverage have separate scores, so a promising match isn't presented as complete support for every requirement.
• Approval creation recomputes the stored pack digest and checks that its referenced revisions are current. The service clock controls expiry. Beginning an attempt repeats those checks, then looks for an existing STARTED, SUBMITTED or UNKNOWN attempt for the same candidate and job or destination.
• CareerStore serializes mutations and works on a cloned draft state. After revision and idempotency checks, one mutation creates the attempt, consumes approval and updates the pack, with audit and receipt metadata saved alongside it. Those three lifecycle changes share one saved state rather than separate writes.
• The service keeps its state in one local file encrypted with AES-256-GCM and an scrypt-derived key. POSIX ownership checks, a held directory identity and a lifetime single-writer lock protect the path and writer. This avoids a separate database service while retaining explicit checks around each durable write.
• External observations arrive as typed caller input. The core itself has no browser, email, network or submission client. Job Search Workflow System and Career Document Tooling are related work, not established runtime integrations of this service.

ACCESS & INPUT

Security controls.

• Authenticated encryption protects the state contents and detects modification. POSIX ownership checks, held directory identity and a single-writer lock also check where the file is stored and which process can write it.
• Approval covers the exact pack digest and current profile and CV revisions, with expiry checked against the service clock. Those checks run again when an attempt begins, closing the gap between review and use.
• An older valid encrypted file can still be restored after restart without detection because there is no external revision anchor. Caller-supplied receipt data also does not establish that an employer issued it. These limits keep the present implementation scoped to local records and preparation.

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

1. Code and development records reviewedReviewed11 September 2026

   The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

   Scope of this check

   Code review, not a fresh run of the app