Submit and read your result

Submitting a case opens a pull request from your fork, records the submission with Fito, scores your work, and writes the result to your profile. It is one command, and it is safe to run more than once.

This page assumes you have worked a case and want to hand it in. If you have not opened one yet, start at Open and work a case.

Before you begin

Four things have to be true, and the first two are the ones that stop people.

• You are logged in to Fito from the terminal. Run /fito-login if you are not.
• Your Fito account has a GitHub identity linked, and your local gh is authenticated as that same account. See Link GitHub before you submit below.
• Your work is committed on the case’s working branch. The command pushes what is committed, and nothing else.
• The case is still open at ~/.fito/cases/<case-id>/. If you deleted the checkout, re-open it first.

Link GitHub before you submit

A submission’s artifact is a pull request, so Fito needs to know which GitHub account is yours. Link it once, in the web app: sign in and choose Continue with GitHub, using the same account your local gh is authenticated as.

/fito-submit checks this before it pushes anything. Two refusals can come back, and they mean different things:

Your Fito account has no linked GitHub identity, which is required to submit.
Link your GitHub account to Fito, then submit again.

Nothing is linked. Go and link it in the web app.

GitHub account mismatch: your Fito-linked account is @alice, but gh is
authenticated as @alice-work.
Run 'gh auth login' as @alice, or link @alice-work to your Fito account, then
submit again.

Two accounts, and Fito will not guess which one you meant. Move either side to match the other.

Why it refuses instead of pushing

The pull request is what proves the work is yours. A pull request opened by one account and recorded against another proves nothing, so the check runs first and nothing reaches GitHub until it passes.

If gh itself is not ready you get a third message — GitHub CLI is not ready — install gh and run 'gh auth login'. — which is Log in from the terminal territory, not a Fito account problem.

Submit

1. Commit your work on the working branch in ~/.fito/cases/<case-id>/.

2. In your pi session, run the submit command:

   /fito-submit <case-id>

   Replace <case-id> with the case’s id — the last part of its /cases/<id> URL, the same id you opened with.

3. Watch it work. It pushes your branch to your fork, opens a pull request against the case’s submission target branch, and records the submission. It prints the pull request URL and a line naming the submission:

   Submission recorded with Fito (id: 019f93a1-12a1-72e8-a369-0bff38814ba4)

4. Answer the quiz, if the case has one. Not every case does.

5. Read the per-criterion feedback it prints at the end.

Confirm it worked: the pull request URL opens on GitHub, and the summary names a proficiency for each criterion.

It is safe to re-run

/fito-submit reuses an open pull request rather than opening a second one, and re-recording the same pull request changes nothing. Re-running it re-scores your work and replaces the recorded result.

That matters when something fails halfway. If the pull request opened but the record did not, you get:

Your pull request is open:
  https://github.com/...
…but recording the submission with Fito failed: <reason>
Re-run /fito-submit to retry — it reuses this PR.

Run it again. It picks up the existing pull request and retries the record.

A rejected push means a diverged fork, not a broken command

If your fork’s branch already carries a previous attempt, the push is refused:

The push was rejected: your fork's '<branch>' branch has diverged from this
checkout (it carries a previous attempt).
Do not force-push. Re-open the case with /fito-case-open and choose to resume
the previous attempt or start over, then submit again.

Do not force-push. Re-open the case and pick resume or start over — that choice is described in Open and work a case.

What you get back

One block per rubric criterion, and one per quiz question. Each carries:

• the criterion, and the knowledge component it assesses, by name rather than by bare id
• the Bloom level that criterion targets
• the result: for a criterion or an open-ended question, the score out of 3 and the label that score matches; for a multiple-choice question, correct or incorrect
• the proficiency recorded for that component — the Bloom level at a score of 2 or 3, NOT_ACHIEVED at 0 or 1
• a link into the Knowledge area, so you can go and read the component
• one sentence saying why

A criterion whose evaluation method is human cannot be scored locally. It comes back marked as needing human review, and it is called out so you know that part of the picture is still open.

For how the 0–3 score is reached in the first place, see How a case is scored.

What lands on your profile

Your profile keeps the highest proficiency per knowledge component — across the rubric and the quiz, and across every attempt you make. A second submission that scores lower on a component does not pull the first one down.

That is why each submission’s report — the summary in your terminal, and its card on the case page — covers that submission alone, and /competencies in the web app is the authoritative record. Read /competencies when you want to know where you actually stand.

Read your standing on the case cover

Sign in to the web app and open the case at /cases/<id>. A Competencies assessed section sits on the cover, and what it holds is yours alone — nobody else sees your standing. The heading is on the cover for every visitor, signed in or not; only your own rows ever appear under it.

It is grouped by competence, not by submission. Each row carries:

Column	What it holds
Competency	The competence this case assessed, linking to your breakdown of it
Technologies	The technologies that demand that competence
Proficiency Level	Your computed aggregate, the same one /competencies shows: the level pill, Proficiency achievement as a percentage, and the coverage line

The icon beside the pill and the one beside the percentage each show that row’s arithmetic. The icon on the Proficiency Level header gives the points each level adds.

Only evaluated submissions feed it, and two different lines stand in for the table while it is empty. Before your first evaluated submission, the section reads “Your assessments for this case will appear here once you submit a solution.”

When you have been evaluated and the table is still empty, it reads “Your submission was evaluated, but no competency covers what this case assessed yet. Your results are recorded and will appear here once one does.” Nothing is lost: your proficiency is recorded per knowledge component either way, and the rows appear once a competence names those components.

A competence can show Not assessed yet even after you submit — that happens when the only criterion touching it is still waiting on human review.

Read each submission on the case page

The case page also keeps the report of every submission of yours that was evaluated. Sign in and open the case at /cases/<id>: a Your submissions section sits after the case’s own text and before Usage, and the page’s outline links to it. Like Competencies assessed, it is yours alone, and it does not appear until one of your submissions is evaluated.

It holds one card per submission, newest first. The newest card starts open and the older ones start closed. Select a card’s head to open or close it. Select the section’s heading to fold the whole section; folded, it keeps one line about your latest submission.

Each card’s head gives the date, the Evaluated chip and a summary line such as “Rubric: 2 of 3 criteria met · Quiz: 1 of 2 correct”. A criterion is met at a score of 2 or 3. A result still waiting on human review is counted apart and left out of the total: “Rubric: 1 of 2 criteria met, 1 awaiting review”. Under the head sit a link to the pull request and the case version you submitted against.

Inside the card, a Rubric table and a Quiz table list every result:

Column	What it holds
Criterion or Question	The criterion’s id made readable, with how it was checked under it — applies-a-binding-fix reads Applies a binding fix. For the quiz, the question and its type
Knowledge component	The component it assesses, linking to its page, with its type badge
Result	The score in words, and the score out of 3
Level recorded	The proficiency recorded: the Bloom level, or Not achieved with the level the row targets

The reviewer’s reason sits under each row. The words come from the score:

Score	Result
0	Not met
1	Partly met
2	Met
3	Met well
None yet	Awaiting review

A multiple-choice question reads Correct or Incorrect, with no score and no reason. A written answer reads like a criterion. The question’s text comes from the case’s current quiz, so a question that a newer version of the case removed shows its id instead. The section never shows a question’s answer or its choices.

What’s next

• How a case is scored — the rubric, the four evaluation methods, and the quiz.
• Bloom levels and proficiency — what your recorded proficiency means and how it rolls up.
• Find a case to work on — pick the next one.