Skip to content

Dashboard status demonstration

This page describes the earlier fourteen-week layout and is being rewritten; where it differs, the syllabus applies.

This public example supplies an authored candidate, its worked repair and a demonstration runner. The runner executes both functions on the same six contract cases. It makes no model calls. Its scripted candidates let you inspect one complete repair repeatedly without treating the result as a model capability measurement.

Contract and prediction

The input is a Python string. Ignore surrounding whitespace and letter case in the ASCII status names. Map ok to passed, fail to failed, and every other string to unknown, including the empty string. Behavior on a non-string input is outside this exercise's contract.

Before opening the repair, predict Candidate A's output on " OK " and write the required output. Explain which operation can make them differ. Then compare the worked repair in the notes. These are worked teaching examples, not answers to a graded submission.

Repository walkthrough

This second example extends the same dashboard from a helper function to its caller. It is a course-authored hand trace, with a frozen source snapshot below. The proposed actions, patch and outputs are authored teaching material. No model selected these actions, and no repository test run is being reported. Read the snippets as text; the runnable six-case helper demonstration in the next section is a separate artifact with its own execution evidence.

Request and frozen files

A developer needs reliable labels and a matching failed-build count. Each build has an integer ID and a string status. Preserve every record's ID and its input order. The count must equal the number of displayed rows labeled failed. Use the existing status contract for all labels. Storage, input validation and additional service statuses are outside this change.

These five named files form the entire teaching snapshot. They are printed here, not taken from a project repository or its instructor solutions.

contract.md:

Ignore surrounding whitespace and ASCII letter case in string statuses.
ok -> passed; fail -> failed; every other string -> unknown.
Keep every build ID in its input order.
failed equals the number of displayed rows labeled failed.

sample.json:

[
  {"id": 17, "status": "\tfAiL\n"},
  {"id": 18, "status": "ok"},
  {"id": 19, "status": "cancelled"}
]

labels.py (the same initial helper as Candidate A):

def status_label(raw):
    labels = {"ok": "passed", "fail": "failed"}
    return labels.get(raw.lower(), "unknown")

dashboard.py:

from labels import status_label


def dashboard(builds):
    rows = []
    for b in builds:
        label = status_label(b["status"])
        rows.append({"id": b["id"], "label": label})
    failed = sum(b["status"] == "fail" for b in builds)
    return {"rows": rows, "failed": failed}

test_dashboard.py (the existing check):

from dashboard import dashboard


def test_ordinary_failure():
    assert dashboard([{"id": 1, "status": "fail"}]) == {
        "rows": [{"id": 1, "label": "failed"}],
        "failed": 1,
    }

Pause 1: choose context and define the change

Before reading the proposed sequence, identify which files establish the desired behavior, current implementation and existing observations. The printed test supplies a check, not an observed test result. Derive the required full output for the sample from the contract before examining the patch.

A bounded delegation prompt could be:

Read the contract, sample, helper, caller and checks. Explain where labels and counts can disagree. Propose the smallest repair and regression checks. Preserve all build IDs and their order. Report the files changed and the actual checks completed; identify any missing result.

An agent could perform the repeated context gathering, file edits and permitted checks, using returned observations to decide what to inspect next. That is the workflow this example makes concrete. It is not a measured speedup or an observed model success. The engineer still owns the contract and acceptance decision.

Pause 2: follow a helper-only proposal

In the authored sequence, a proposed read of dashboard.py would be checked by the controller before a tool could return its bytes. Those bytes reveal two separate interpretations of the status: the helper supplies a row label, while the summary compares the raw string directly. A model could overlook the second interpretation.

Suppose the first proposed edit changes only labels.py:

-    return labels.get(raw.lower(), "unknown")
+    return labels.get(raw.strip().lower(), "unknown")

The hand-derived sample result is:

{
  "rows": [
    {"id": 17, "label": "failed"},
    {"id": 18, "label": "passed"},
    {"id": 19, "label": "unknown"}
  ],
  "failed": 0
}

The required count is 1. The helper's six cases do not call dashboard, and the existing dashboard test uses the exact raw string fail. Those checks would miss this disagreement. This conclusion follows from the printed code; it is not a recorded pass or failure. What check should be added before another proposal?

Pause 3: use one interpretation and protect the caller

Keep the helper repair and propose this additional change in dashboard.py:

-    failed = sum(b["status"] == "fail" for b in builds)
+    failed = sum(row["label"] == "failed" for row in rows)

For the sample, independently expect all three rows above in the same order, with failed: 1. A full-output assertion checks the labels, count, retained IDs and order. Also retain the original ordinary-failure check and the helper's ordinary, padded, unknown and empty-string regressions. An empty build list should produce {"rows": [], "failed": 0} under the same row/count rules.

At this point the authored sequence contains a proposed repair and hand-derived expectations. Accepting an actual implementation would additionally require completed checks on the exact changed files, inspection of the diff and a review of remaining scope. A successful file write, test request or final message cannot fill that gap. Do not enter any of these hand-derived values into your model-calibration record.

Pause 4: decide what to delegate next

Name one useful bounded next action for an agent and one judgment you must make yourself. For example, the workflow can collect the relevant files and execute an allowed full-output regression; you must decide whether its expectations preserve the stated product behavior. If the new status completed has no supplied meaning, neither more code generation nor a green test invented by the agent settles that rule.

Supported execution

The fixture is a local, scripted example. It makes no model request and needs no credentials. From the repository root, copy the public files to a temporary directory and run them with the repository's small IPC helper on PYTHONPATH:

week01_root=$PWD
week01_work=$(mktemp -d)
cp lectures/week-01/fixture/{candidate.py,repaired.py,demo.py} "$week01_work/"
(cd "$week01_work" && PYTHONPATH="$week01_root/scripts" python3 demo.py)

Inspect $week01_work/observations.json as text. The command exits zero and prints this transcript:

generation: scripted-course-candidates
candidate / ordinary: 2/2 passed
candidate / contract: 4/6 passed
repaired  / contract: 6/6 passed
regression: original cases retained

Candidate A's two failed checks are expected observations. The demonstration succeeds only when those failures and the repair's six successes match the specified matrix. An unexpected result raises an error. The exported JSON contains each input, expected and actual output, and SHA-256 hashes of the three executed source files.

The hashes bind this public record to source bytes for inspection. An editable local record is practice feedback, not an authoritative grade or proof of a model run. This demonstration makes no model request and supplies no new profile.

The public regression verifier also checks that a broken repair, an unexpectedly changed candidate or an exception cannot produce the success transcript. Run it in the same temporary directory:

cp lectures/week-01/fixture/verify_demo.py "$week01_work/"
(cd "$week01_work" && PYTHONPATH="$week01_root/scripts" python3 verify_demo.py)

Expected: five passing checks (Ran 5 tests, OK) and zero exit status. These checks support the teaching demo; they add no student submission requirement.

Inspection and continuation

Read the original two checks and the two previously failing cases. Explain why each added case distinguishes Candidate A from the repair. Describe a behavior the six cases do not test. You can trace the same table without executing code; label that work as a hand trace and use the supplied transcript as a reference expectation.

Keep an absent or unexpected execution result as such; do not present the reference transcript as the output of a failed invocation. Continue the classroom discussion from the written contract and code while the local setup is repaired.