Design a case

Designing is a dialogue. You bring a goal and the technologies the case is about; the command grounds it against the knowledge Fito actually holds and writes a case proposal. Nothing else is written — no .case/ folder, and never a file under a source project you point it at.

This page covers /fito-case-design, its flags, and the two refusals it can end on. For the shape of the thing you are designing, read What a case is.

Before you begin

• A pi session in a working directory of your own, with Fito installed there. See Set up a working directory.
• Every technology the case is about, and the major line it targets, already provisioned. See Provision a technology.
• The knowledge components the case will reference, already pushed. If they are not there yet, this command refuses — see When the command stops.

You do not need to be logged in. Every read this command makes is public.

Design the case

1. Run the command with the goal and one --technology per technology, each carrying its major line:

   /fito-case-design "diagnose a broken JSON endpoint" --technology javalin@7

   To build the case on a project you already have, add --source:

   /fito-case-design "diagnose a broken JSON endpoint" --technology javalin@7 --source ~/code/my-javalin-app

2. Answer the dialogue. It settles the scope, the case type, a duration estimate, and the toolchain — the build tools the case project is built against, named by major line only (9, never 9.5.1).

3. Read the proposal it drafts and push back on it. Scope, references, rubric criteria, weights and the quiz are all open until you confirm.

4. Confirm. The proposal is written to ./case-proposal.md, or wherever --output says.

Confirm the result before you move on: open the file and check it carries Parameters, Learning objectives, Prerequisites and Rubric criteria. Those four are what the next step reads, and it stops without them. Quiz items, Source grounding and Open questions are present only when the case has them.

Flags

Flag	Required	What it does
(leading text)	Yes	The goal — what the case should teach or assess
--technology <slug>@<version>	Yes, repeatable	A technology the case is about, with its major line
--source <path>	No	An existing project to build the case on
--output <path>	No	Where to write the proposal. Defaults to ./case-proposal.md

Every --technology must carry its @<version>. A bare slug is refused rather than treated as “any version”, because every knowledge component is scoped to a major line, and a component live only on another line reads as missing.

Note

The toolchain and the --technology versions are two different declarations. The technology versions are what the case teaches; the toolchain is what the case project builds against. They overlap and are not the same.

What the proposal holds

A markdown file with fenced YAML blocks, shaped like the .case/ files they seed:

Section	Seeds
Scope	The situation and the task
Parameters	manifest.yaml — type, duration, language, tags, technologies, toolchain
Learning objectives	learning_objectives.yaml
Prerequisites	prerequisites.yaml
Rubric criteria	rubric.yaml
Quiz items	quiz.yaml, when the case has one
Source grounding	Reuse runs only — the project, the case area, the gate commands
Open questions	What was left for you to settle at the next step

Rubric weights must be positive whole numbers summing to exactly 100, and every criterion sketches all four levels, scores 0 to 3.

Every reference is verified, never guessed

The command lists what the vocabulary holds for each declared technology and major line, then fetches every id the proposal will carry. An id that does not come back is missing, and no unfetched id reaches the proposal.

Caution

Choose the references as if they were permanent, because after publication they are. A published case whose learning objectives, prerequisites or rubric references change cannot be corrected in place — that correction is a new case. See The reference set.

Assessment targets a learning objective

The command lists every component your rubric criteria and your quiz questions name, looks for each one in the learning objectives, and reports every miss under Open questions — saying whether it is a prerequisite, or neither. It reports rather than repoints, because which repair you want is your call.

The full rule, and why it is a report and not a refusal, is on What a case is.

The rungs are a quality ladder at the declared level

A criterion’s bloom_level is what a met criterion records: a score of 2 or 3 records that level, and a score of 0 or 1 records NOT_ACHIEVED. So the four rungs of its levels measure how well the learner worked at that one level. They never climb from one level to the next:

Rung	Score	What it describes
not_achieved	0	No attempt at the declared level, or a wrong one
partial	1	An attempt at the declared level that falls short
achieved	2	Met. This rung defines the award, so write it with the most care
exemplary	3	Met well — the same work done better, at the same depth

The command also compares each criterion’s declared level with what its rungs ask the learner to do: recall, explain or apply. A criterion that declares APPLICATION while its rungs ask the learner to explain assesses COMPREHENSION, and a learner who explained well would be recorded at APPLICATION without applying anything.

Each miss goes under Open questions, naming the criterion, the rung, the declared level and the level the rung assesses. The command keeps the criterion as drafted, because the repair — declare the level the rungs assess, or rewrite the rungs — changes what the case certifies. Settle it before you publish: after that, a changed level makes a new case.

Descriptions name the topic, never the move

Every description you write here travels: the generate step copies them into the case files, and the public catalogue page is drafted from the learning objectives. So a description may state what is broken and what the learner will be able to do, and must not state the move that repairs it.

The full rule, with worked examples, is on What a case is.

When the command stops

Both stops write no proposal.

What you see	What it means	What to do
“The Fito vocabulary doesn’t hold these declared technologies yet”	A slug is absent, or it exists without the major line you named	Provision it, or correct a misspelled declaration
“These components don’t exist in the Knowledge Repository yet”	The case needs knowledge nobody has written up	Run the knowledge pipeline over the source, then re-run this command

Do not shrink the case to fit what exists. Dropping a component the case genuinely needs makes a worse case; the vocabulary is what should grow.

One check before you reach for the pipeline: if every candidate under one technology came back missing, suspect the major line rather than the vocabulary. The technology and the line both exist — step 1 proved that — so what is left is that the components you need live on a different line.

Any other failure, such as an unreachable backend, says nothing about your declaration. It is reported as it arrived.

What’s next

• Generate the .case/ folder — turn the proposal into the contract.
• Identify knowledge components — if the design stopped on missing components, start here.