No automated verification: a piped-input smoke script would lock in each branch's output

[dmccoystephenson]

Summary

There is no automated verification of any kind in this repository — no test framework, no CI workflow, and no script that runs the program and checks what it prints. Every claim about behavior has to be re-established by hand, one piped run at a time.

This became concrete while fixing #4. The evidence that the fix worked was produced by stashing it, re-running the divide case, observing the tuple form, then restoring it and observing the sentence form. That evidence lives only in the pull request; nothing in the tree would catch the tuple form being reintroduced.

Suggested shape

A single POSIX-sh script — check.sh, no framework and no dependency beyond the shell and the interpreter — is the proportionate unit for a 16-line program:

• One case per branch: Add, Subract, Multiply, Divide, and the unrecognized-operation path, each asserting the line the program prints today.
• Four input lines per case (first number, second number, operation, exit pause). Three lines leaves the final raw_input to raise EOFError, which fails the case for a reason unrelated to the program.
• Every invocation wrapped in timeout, since the program blocks forever at the first prompt when stdin is not fed.
• A clean skip, not a failure, when no Python 2 interpreter is present: the version is probed, SKIP: no Python 2 interpreter is printed, and 0 is returned. A script that hard-fails on a Python-3-only machine is worse than none.
• No bytecode left behind.

The cases should characterize what the program does today, including the behavior tracked in #5, #6 and #8. Fixing a bug discovered while writing a case belongs in a separate change.

Why it is worth doing before the remaining behavioral issues

#5, #6, #8 and #10 all change what the program prints or accepts. Landing the script first gives each of those a place to record a real regression case, instead of leaving the evidence in a pull request body where nothing re-runs it.

This issue was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).

---

drafted by Claude on behalf of Daniel Stephenson

[dmccoystephenson]

This issue was selected as the work for an autonomous maintenance cycle and then abandoned
part-way through, so the reason is recorded here rather than left as silence.

A check.sh matching the shape described above was written — an interpreter probe that skips
cleanly when no Python 2 is found, a timeout-bounded runner supplying all four input lines, and
nine cases covering the four operation branches, mixed-case input, the unrecognized-operation
path, the unstripped-input behaviour tracked in #10, and the two crash paths tracked in #5 and #6.
It was then discarded unpushed, because it could not be executed even once in that environment:
sh check.sh, bash check.sh, sh -c, sourcing the file, and even the parse-only
bash -n check.sh were each refused by the harness, which permits the program itself to be run
(printf ... | timeout 10 python calculator.py works, and was used extensively) but not an
arbitrary shell script. Proposing a test script that had never been run — one whose own quoting or
arithmetic could be wrong in ways nothing had checked — was judged worse than proposing nothing.

Two observations from the attempt are worth keeping for whoever picks this up:

• Asserting on a substring of the answer rather than on the whole output keeps the cases
  independent of the prompt wording, which "Subract" misspelling rejects the correctly-spelled "subtract" and contradicts the repo description #7 and PR fix: accept "Subtract" and correct prompt spelling (#7) #14 propose changing. The operation keyword
  each case feeds still depends on that spelling, so the Subract case's input line has to be
  updated alongside any keyword change; a comment saying so belongs next to it.
• The exit status is worth asserting alongside the output, not just the printed text. The zero
  divisor case is a concrete example: before Division by zero produces a ZeroDivisionError traceback #5 was fixed it exited 1 with a traceback, and it now
  exits 0 with a message, so a case checking output alone would have missed half of what changed.

The zero-divisor fix that merged in #15 is exactly the situation this issue anticipates — its
FAIL→PASS evidence lives in that pull request body, where nothing re-runs it, and nothing in the
tree would catch the traceback being reintroduced.

This comment was drafted during a Gardener session
(https://github.com/Stephenson-Software/gardener).

---

drafted by Claude on behalf of Daniel Stephenson