tryskian

Applyekhine

Is the work interesting? Which résumé belongs with it? What answers are true?

Applyekhine is a local tool for preparing job applications. It keeps those decisions in order, carries a selected résumé through the application, and checks the fields it fills before the human submits.

The name combines “apply” with Alekhine's gun: a queen lined up behind two rooks. Around here, getting ready to apply is “rack the stack.”

Interest comes first

The starting question is whether the work itself is relevant. Qualifications, form answers and permission to submit are separate decisions later in the process. An unfavourable answer to a qualification question does not have to rewrite the earlier assessment of the work.

The visible listing and its source are captured first. A résumé is selected and kept with that application. If two genuinely fit, the workflow pauses for a choice. Missing answers can remain unknown.

Diagram

One application, with clear decisions

One application, with clear decisions
Relevance, résumé choice, application-system capability, field verification and human submission have distinct places in the workflow.
Open full-size diagram
Read the diagram

Capture the visible listing and its source state, then apply the discovery policy. An allowed listing reaches a relevance decision. A relevant role is routed to a résumé; a genuine tie pauses for a choice. The application system is detected. Unsupported capabilities pause for an adapter. A supported form receives a plan and adapter. Missing answers or human gates pause the role. Supported fields are filled and read back, then held ready for human review. Submission is a separate human action. Decisions and pauses retain role state and redacted evidence.

Original Mermaid source

Filling is an operation that can be checked

Application systems have different capabilities. The documented adapter set supports Ashby filling and readback, Greenhouse inspection, and detection for several other systems. Recognising a form does not by itself enable filling it.

A browser action names a semantic control and an expected value. After the action, readback checks what reached the control. The result is either a verified operation or a pause requiring attention.

Diagram

Check the field after the action

Check the field after the action
A successful action includes checking what reached the intended control.
Open full-size diagram
Read the diagram

Identify the semantic control and expected value, perform the browser action, read the control back, then record either a verified result or a pause.

Original Mermaid source

A pause belongs to one application

An unanswered question or unsupported form should leave a clear place to resume. Applyekhine records progress for each role, allowing one application to wait while the rest of a batch continues.

Candidate materials and application records have their own private location. Synthetic listings, answers and forms allow the workflow to be demonstrated without using a person's application data. Submission remains a separate human action.

What the project asks

Can an application workflow keep relevance separate from answers and authority? Can it preserve a decision as the work crosses from a listing to a résumé, an application plan and a browser form?

The implementation gives those questions concrete places to inspect: the routing decision, the known or unknown answer, the adapter's capability, the field readback and the resumable application state.

Sources & further reading