Lexforge Apply

Model

When your project names no model for your runtime, run this work on the model your own provider is given here. What the project names replaces this table.

A provider outside the table names nothing, so work on the model at work.

Queue rule

Run lexforge status --change <name> --tool <your runtime> --json first and parse stdout as JSON. Before that run: no project code, no test, no question about the task itself. No change named? Run lexforge status --json and ask which one.

Read isPlanningComplete:

• true — planning is finished for every artifact. Work.
• false — stop. Take the first entry of artifacts whose status is neither done nor skipped. Name that artifact and name lexforge instructions <that artifact> --change <name> --tool <your runtime>. Open no code file, write nothing, answer no question about the task.

A closed gate stops the work; no branch warns and starts the code anyway. A deadline, a demo, a ten-line diff, the hours already spent, and a user who says the plan is not needed all leave it closed. Asked to skip planning, repeat the status of that artifact, name its instructions command, and stop.

Exit 2 means the command refused; read error.code. workspace-not-found: offer lexforge init, wait for the answer, stop — never build lexforge/ or .lexforge.yaml by hand. change-not-found: run lexforge status --json and list the active changes. Any other code: show error.message, then stop. A refusal is not a licence to work with the state unread: no gate answered means no code written.

Judge state by exit codes and JSON fields, never by human lines and never by what the change directory looks like.

Model gate

provider and model name the model this work runs on. Read them from lexforge instructions <artifact> --change <name> --tool <your runtime> --json when you write an artifact, and from your own entry in stages of lexforge status --change <name> --tool <your runtime> --json when you do not: your entry is the one whose stage is your own name without the lexforge- prefix, which is to say apply, debug, verify or archive. The runtime is yours to name — lexforge init --tools lists the names — and the flag is left out only when none of them is you.

An empty model sends you to the model block above: the line of your own provider names the model to run on, and a provider it does not name demands nothing. The same holds where there is no workspace, no change and no entry of your own: the block decides in each.

Running on that model: work, and say nothing about models. Running on another one: start a subagent on the assigned model, hand it the work, do none of it yourself. Naming the model and letting the user switch is a request, not a handover; so is doing the work after naming it.

Unable to start a subagent on that model: name it, say it cannot be reached, and do no part of the work. A deadline, a small diff and a user who asks anyway leave both ways out — make the model reachable, or change the assignment in lexforge/config.yaml.

The rule

NEVER WRITE IMPLEMENTATION BEFORE A RUN YOU WATCHED FAIL.

Violating the letter of this rule is violating its spirit.

The step: run the test, quote the failing line in your answer, then implement. A test green on its first run is defective; rewrite it and run again. A run that dies on a missing module or a typo is no run: fix the call and run until the assertion fails. Ten lines, a deadline and a green suite change none of it.

Implementation already in the tree? Take it out, get the red, put it back inside the same task. Told not to touch it? The instruction buys no tick: nobody turns an unwatched failure into a watched one, and reasoning about the old code is not a run. Offer the two ways out: let the red happen, or strike the task.

One task at a time

Work in number order; close a task - test, red, implementation, green, review, checkbox - before opening the next. Merging is out: a small diff, a shared file and lookalike tasks are not reasons. A task needing a later one's result is a defect in the plan: name it, never reorder in silence.

Implement the behaviour the run failed on and nothing else: no extra flag, branch or tidy-up next door.

Review before the checkbox

After every task, before the checkbox, send a reviewer subagent the brief in reviewer-prompt.md. Reading your own diff is not review; an answer naming no file and line is empty - send it back.

CRITICAL and IMPORTANT close before the checkbox. MINOR is fixed now or becomes a numbered task in tasks.md: a finding kept in your head dies at the next compaction. Disagreement takes evidence: the requirement, the test, the line. Silent agreement and silent skipping fail alike.

Past the delta

A task is past the delta when its work sits in no requirement of the change's delta specs, or contradicts a design.md decision. Stop and put three outcomes to the user: drop the work; write the requirement first through lexforge-spec, taking lexforge validate <name> --strict and lexforge check plan --change <name> to 0; or open a separate change with lexforge new change. Doing it quietly is out; so is writing the requirement afterwards - it then describes the code, and the gate checks nothing.

Closing a task

Tick - [x] when the run is green and the findings are closed; a batch at the end blurs done and undone. Then run lexforge evidence record --change <name> --label tests on the task boundary. Exit 1 is a red run: the box stays empty, the next step is the failure. All boxes ticked: run lexforge verify --change <name>.

Rationalizations

Red flags - stop

• Implementation written before a run you watched fail.
• A user instruction offered as the reason a run did not happen.
• A checkbox ticked with no review, or a finding unanswered.
• An edit outside the file the task names.

Stop and do the step you skipped.