You can follow the thought.
Names and small functions explain the job. Sensor rules, evidence retrieval, and answer assembly have distinct responsibilities.
See the service boundaries ↗Experiment 04 / Quality assurance
Prove it.
Then break it.
A convincing answer can still be wrong. Give our tiny system an inspection, sneak in a bug, and watch the checks catch it.
Real assertions · simulated services / No account. No collateral damage.
The slightly suspicious build
Does it hold up?
DEMO RELEASE GATENOT TESTED
The same sensor rules, vision filtering, and backend pipeline used across this playground.
0PASSED
0FAILED
10NOT FINISHED
Ten checks. No results yet. Let’s see what this thing is made of.
Fixed test fixtures. Your saved readings stay untouched.
Looks plausible. Missing the proof.
The broken build strips citations from the answer service. Restore them, then run the same checks again.
The inspection list.
INSPECT A CHECKNOT RUN
Show your work.
Select a check to see what it expects, then run the suite to collect evidence.
No green lights on credit. Results come from comparisons against the running simulation.
Inspect request & service trace
Captured during this check. An expected backend error can be evidence of a passing test.
This small suite runs in a browser worker. Its gate is a teaching demo, not this site’s CI or a production release decision. Passing these checks does not prove every behavior is correct.
What good looks like / code
Good code earns
your trust.
Green tests are evidence, not a trophy. These are the habits this tiny system is trying to demonstrate.
No moving targets.
A request captures one state snapshot. Later slider changes cannot silently rewrite the answer’s evidence.
Inspect “No moving the goalposts” ↑Bad news travels clearly.
Validate inputs. Keep offline readings marked last known. Stop when retrieval fails instead of manufacturing a plausible answer.
Inspect the failure checks ↑A test can disagree.
The expected source comes from the contract, independently of the answer. That is why removing citations makes the check fail.
Try the broken build ↑Old work stays old.
Stopping a run terminates its worker. Late messages cannot overwrite a newer result. An unfinished suite gets no passing gate.
Run, then stop ↑Change one thing on purpose.
Keep rules visible and responsibilities small. A fix should address a concrete failure while the other checks keep their meaning.
Start with a clear definition ↗This demo’s ten checks cover a narrow slice. A production system also needs reviews, security and access checks, performance work, and feedback from the people using it.
Iteration / close the loop
A red light is
a useful clue.
OBSERVE
The receipt disappeared.
The answer sounded reasonable, but QA found no source citation.
DECIDE
Fix code or revisit intent?
Our product contract requires evidence. Keep that requirement; fix answer assembly.
CHANGE + VERIFY
Restore. Rerun. Learn.
Switch back to the healthy build. Run the same checks. Then ask what important behavior still needs a test.
Green lights need a reason
01 / ARRANGE
Make the setup repeatable.
Give each check a known temperature, scene, or question. A test should not depend on whoever touched the sliders last.
02 / ACT
Exercise the real path.
Run the shared simulation code. Backend checks capture service output; the deliberately broken build removes citations inside answer assembly.
03 / ASSERT
Compare. Don’t applaud.
Expected and actual values must agree. A refusal can pass. A polished answer without required evidence can fail.