Plan the case source

A case needs source code: the starter state a learner receives, and the exemplar solution on case/solution-vX.Y.Z. Fito does not write that code. It writes the two documents that guide you while you do.

This step sits between generating the contract and publishing. It writes only .authoring/, never .case/ and never your project source, and it pushes nowhere.

Before you begin

A working directory containing .case/. See Generate the .case/ folder.
The case-proposal.md that Design a case wrote. The command reads each technology’s major-line version and the toolchain from it.
An LLM provider configured in pi, and the pi-subagents package installed. The planning is handed to a worker persona over that package, on your own model.

Plan the source

From the directory that holds case-proposal.md, run the command and name the case directory:
```
/fito-case-plan-source ~/code/my-case
```
To force the scenario, or to read a proposal kept somewhere else, add the flags:
```
/fito-case-plan-source ~/code/my-case --scenario greenfield --proposal ~/code/case-proposal.md
```
Confirm the scenario it detected and the proposal file it found. Reuse means the tree already carries project source; greenfield means the starter source is built from scratch.

When it finds no proposal, it asks for the file’s path. Without a proposal, give it each technology’s major-line version and the toolchain instead.
Read the digest it relays: both terminal states, the number of plan steps, which rubric gates are covered, and its toolchain cross-check.
Ask for any section, and hand revisions back, until the documents are right.
Let it commit. Only .authoring/ is staged. If anything outside that folder has changed, it stops and shows you rather than committing.

Flags

Flag	Required	What it does
(leading text)	No	The case directory. Defaults to `.`
`--scenario reuse\|greenfield`	No	Overrides the detection in step 2
`--proposal <path>`	No	The case proposal to read. Defaults to `case-proposal.md` in the case directory, then `./case-proposal.md`

The two documents

File	What it is
`.authoring/source-spec.md`	What the source must be — both the starter state and the solution branch
`.authoring/source-plan.md`	Ordered, verifiable steps to get there

Running the command again on a tree that already has them is a revision run. It says so and asks what should change; it never silently overwrites documents you have reviewed.

Two kinds of problem, two different routes

The planner reads your .case/ contract against the source. When the two disagree, the fix depends on which one is wrong.

What it reports	Where the fix belongs
A contract conflict — a gate command the project’s build files do not declare, a test path that cannot exist	`.case/`. Re-enter Generate the `.case/` folder, correct it, then re-run this command
A toolchain mismatch — your declared toolchain contradicts what a technology version says it needs	Nowhere automatic. It is advisory: reconcile the declaration yourself

Never plan around the contract. If the contract is wrong, change the contract.

Build the source outside Fito

Executing .authoring/source-plan.md is your own work, in your own harness, with whatever tooling you like. Fito names no tool and has no command for this half.

Which document does what

The two documents are not two steps. They are a runbook and the bar it has to clear:

File	Role	What you do with it
`.authoring/source-plan.md`	The runbook	Execute its numbered steps, in order
`.authoring/source-spec.md`	The acceptance criteria	Check the finished tree against it

Hand over both. The planner writes them to stand alone — every test name, gate command, error string and branch name is stated inline — so a session that knows nothing about Fito can execute them. A coding agent reads them as well as you do.

A step is done when its check passes

Every step carries a verification: a command, and the result you should observe. That is what makes handing the plan to an agent safe. You are not trusting a report, you are running a command.

Two kinds of step still need you:

A value the planner could not ground. Where neither the fetched knowledge nor the existing tree showed how something is done, the step names it as a value to verify against the real toolchain, rather than inventing an API that would travel on into the case project.
A gap the planner flagged. If a failing_tests entry, a known error or a deliverable had no file-level counterpart, it says so in its digest rather than papering over it. Closing that one is yours.

You are finished when two commands agree

Run both and read the output:

Branch	What you must see
`case/solution-vX.Y.Z`	Every rubric gate command passes its passing condition
The starter branch, the one carrying `.case/`	Exactly the tests `known_state.yaml` names fail, each for the stated reason. Nothing else fails

The solution branch stays local. Pushing it is /fito-publish-case’s job; your plan only has to leave it existing.

Come back and re-validate

When the source is finished, run the generate command over the tree again:

/fito-case-generate --dir ~/code/my-case

It finds .case/ already there and takes its re-validate path. artifacts.yaml is finalised against the now-real tree, and the tree earns the fresh attestation the publish carries.

What’s next

Publish a case — push the refs, register, and go live.