Open and work a case

Opening a case is one command. It puts a working copy of the case on your machine, on a branch of your own, and then briefs you on what you are being asked to do.

This page assumes you have picked a case and have its id. If you have not, start at Find a case to work on.

Before you begin

• You are logged in — /fito-login.
• git and gh are installed, and gh is authenticated as the GitHub account linked to your Fito profile. Opening forks a repository under that account, and submitting later checks that the two match.

Open the case

1. In your pi session, run:

   /fito-case-open <case-id>

   <case-id> is the case’s id — the last part of its /cases/<id> URL. Cases have no short name in the terminal, so this id is what every command takes.

2. Watch it work. In order, it:

   • forks the case repository to your GitHub account
   • clones the fork into ~/.fito/cases/<case-id>/
   • checks out the published version of the case, not its default branch
   • re-validates the .case/ folder structurally, in your checkout
   • creates your working branch
   • records your enrollment with Fito

3. Confirm the checkout. It prints where the case landed and which branch you are on:

   Case opened at: ~/.fito/cases/<case-id>
   on branch '<name>'

   Check that the fork it names is owned by your Fito-linked account.

What the briefing gives you

Once the checkout exists, the session reads the case and orients you. It comes in four parts, in this order.

1. The header — the case’s title, its type (diagnostic, implementation or tutorial), and how long it is estimated to take.

2. The situation — every situation document the case declares, in the order it declares them, each framed by what it is: a ticket, an email, log output, a chat thread, a pull request description, or plain prose. Nothing is reordered or skipped, because the order is part of the story.

3. The task — the objective, any constraints you have to work within, the steps if it is a tutorial case, and the deliverables you are expected to produce.

4. The artifacts — an annotated map of the repository’s relevant files, labelled evidence, target, reference or scaffold, with the target files you will most likely change called out.

It then grounds the case in Fito’s vocabulary, in two groups: This case develops, from the case’s learning objectives, and You should already know, from its prerequisites. Each one is fetched from the live Knowledge Repository rather than paraphrased.

The solution is out of reach, not merely off-limits

The briefing never shows you .case/solution/, and neither does the tutor. That is not a rule either of them is asked to keep.

The briefing surface serves documents by an enumerated key — manifest, situation, task, artifacts, starter_state, knowledge_refs — and never by a file path. Four things have no key at all: the exemplar solution folder, solution.yaml, rubric.yaml and quiz.yaml. There is no request that reaches them, so there is nothing to resist.

The case’s own manifest is trimmed the same way. You see the title, the type and the duration; the authors, the publication status and the submission configuration are authoring metadata and are not served.

The files are on your disk either way

Your checkout is a git repository, and the published version does not carry the solution branch. What you cannot reach through the briefing, you also cannot reach by reading around it.

Work

Open ~/.fito/cases/<case-id>/ in your editor and solve the case. Commit on the working branch — that is the branch submitting will push.

Stuck? Ask the tutor. It can read this case and the knowledge behind it, and nothing else.

When you want to see where you stand without handing anything in, run /fito-evaluate <case-id>. It scores your work locally and records nothing. See How a case is scored.

Coming back to a case you already attempted

If your fork already carries this case’s working branch — you submitted once, deleted the local checkout, and came back — the open stops and asks you.

Choice	What it does
Resume	Checks out the fork’s branch and tracks it. Your commits and your open pull request survive.
Start over	Deletes the fork’s branch, which closes the old pull request, and starts fresh from the published version.

The session relays both options and waits. It never picks for you, because one of the two throws away work.

Start over closes your pull request and drops unmerged work

Deleting the fork’s branch is not reversible from Fito. Choose it only when you mean to abandon that attempt.

A first open — no fork, or a fork without that branch — never asks.

When an open refuses

What it says	What it means
A “case source malformed” report, and no branch	The case’s own .case/ folder does not validate. Nothing is wrong on your side. Try again later, or report the case.
A refusal naming a deprecated case	The case has been withdrawn. Do not work around it; pick another.
⚠ This case has been deprecated…, then a normal open	The case is on its way out but still workable.
It will not overwrite a non-empty checkout	You already have this case open at ~/.fito/cases/<case-id>/. Work there.
GitHub CLI is not ready — install gh and run 'gh auth login'.	gh is missing or signed out.

What’s next

• Ask the tutor — case-scoped help while you work.
• How a case is scored — what the rubric will judge.
• Submit and read your result — hand it in.