ledger
a979e630a4
line_counter.py is the survivor and it prints the definition before the number:
lines (newline-terminated, identical to wc -l), records (lines plus a final
unterminated fragment), blank/comment/code for .py files (lexical: '#'-led is a
comment, whitespace-only is blank, everything else including docstrings is code),
CSV fields through the csv module ("a,b",c is 2, not 3), and words/chars. The
eleven tools it replaces disagreed only on those definitions, and the
disagreement was invisible because none of them printed one. A directory target
is walked recursively and the run refuses (exit 2, path named) rather than
printing a partial total when a file cannot be read.
Retired, and where each behaviour went:
count_python.py file/line walk -> `line_counter.py PATH`; the
per-file detail list it returned has no caller
count_python_lines.py code/comment/blank breakdown -> PATH report
py_loc.py same breakdown, same key names
loc_counter.py same breakdown; its argparse surface goes with it
linecount_pycount.py totals -> lines/records keys, its code count -> `code`
code_stats.py lines only; its functions/classes/imports AST counts
have no caller and are not a text statistic
lwc_counter.py -> `--words` (lines, words, chars)
text_stats.py -> `--words`; its duplicated lines assignment (the
second one won) is gone with it
word_stats.py -> `--words`; unique/top-5 tables have no caller
file_stats.py -> `--words`
file_analyzer.py -> `--words`; its size_bytes is `wc -c`
quick_stats.py -> `--words`; bytes is `wc -c`; unique/top-5 retired
wordcount.py -> `--words` (its JSON envelope is not kept)
word_counter.py -> `--words`
word_counter_simple.py -> `--words`
word-counter.py -> `--words`
wordfreq.py -> `--words`; frequency table retired, no caller
word_freq.py -> `--words`; frequency table retired, no caller
Retired in the same commit because each graded a tool that no longer exists:
test_linecount.py, test_text_stats.py, verify_lines.py, verify_lwc.py,
verify_wordcount.py, verify_word_freq.sh, check_word_count_report.py
verify_line_counter.sh is repaired rather than deleted. It pinned
/root/.hermes/wizard-outputs/spark and "Total lines: 5587" -- a figure belonging
to the 65-line tool last held at 7359bce that 6b5197b had already replaced -- and
read rc 1 at the opening rev. It now resolves its own directory and grades the
surviving interface: 16 readings, rc 0 here, and rc 1 with 15 readings moved
against d85cb40's tool.
test_line_counter.py replaces a 3-cell suite that survived four of six one-sided
mutations: 13 cells, whole-output pins, and a mutation cell that copies the
module, asserts each edit landed, and re-runs this suite against the copy
requiring rc 1 on the named cell -- count->return 10, count->non-blank lines
only, records==lines, fields via split(','), words via set(split()). Five
mutants, five killed. Against d85cb40's tool the same suite reads 0/13, rc 1.
Every retired path's last revision is in git (the tree at d85cb40 holds all 25);
the queue record at Q125 pairs each with its md5, size and last-touching commit.
tools/path_claim_baseline.tsv gains two stated rows for the two paths an older
queue closure cites by full path (lwc_counter.py, verify_lwc.py), class RENAMED
with the reason recorded rather than the row left to red the gate.
Files: wizard-work/spark/line_counter.py, test_line_counter.py,
verify_line_counter.sh (repaired), README.md, VERIFICATION.md, 25 deletions,
tools/path_claim_baseline.tsv.
Spark Output: Snippet Summarizer Artifacts
Generated: 2026-10-12T13:03:03 UTC
Files Produced
-
snippet-summarizer.py (3,137 bytes)
- Python utility that scans directories for Python source files
- Extracts metadata: line count, character count, file size
- Outputs structured JSON report
- Usage:
python snippet-summarizer.py <directory> [--output <file>]
-
report.json (16,156 bytes)
- Generated report scanning
/root/.hermes/profiles/spark/ - 50 Python snippets found
- 11,713 total lines of code
- 430.78 KB total size
- Average 234.26 lines per file
- Generated report scanning
Verification
The report.json file is valid JSON and contains:
- Complete file listing with paths
- Per-file statistics
- Extension-based grouping
- Aggregate statistics
JSON Validator (New Addition)
A Python CLI tool for validating JSON files with detailed error reporting.
Files
- json_validator.py - Main validation script
- sample_valid.json - Test file (valid object)
- sample_array.json - Test file (valid array)
- sample_scalar.json - Test file (valid string scalar)
- sample_bad.json - Test file (invalid JSON)
Usage
python3 json_validator.py <file.json> [file2.json ...]
Verified Tests
✓ VALID: sample_valid.json - Object with 3 keys, 73 bytes
✓ VALID: sample_array.json - Array with 3 elements, 141 bytes
✓ VALID: sample_scalar.json - Scalar value: str, 21 bytes
✗ INVALID: sample_bad.json - Missing quotes error
✗ INVALID: nonexistent.json - File not found error
syshealth.py - System Health Check Utility
A Python utility that collects system metrics: disk usage, memory info, load average, and process count.
Files
- syshealth.py - Main script (1,697 bytes)
- system-report.json - Generated report with all metrics
Usage
python3 syshealth.py
Verified Test
$ python3 /root/.hermes/wizard-outputs/spark/check_syshealth.py
PASS: Valid JSON with all required keys
Process count: 422
Verification
Check: python3 /root/.hermes/wizard-outputs/spark/check_syshealth.py && echo "PASS"
JSON Schema Validator (NEW)
A command-line tool for validating JSON files against JSON Schema.
Files
- json_schema_validator.py - Main validation script (46 lines)
- test_schema.json - Test schema (requires name: string, age: integer >= 0)
- test_data_valid.json - Valid test data, passes validation
- test_data_invalid.json - Invalid test data (age < 0)
- test_data_missing.json - Missing required field test
Usage
python3 json_schema_validator.py <schema_file.json> <data_file.json>
Verified Tests
✓ VALID: test_data_valid.json passes against test_schema.json (exit 0)
✗ INVALID: test_data_invalid.json fails with "age: -5 is less than minimum of 0" (exit 1)
✗ INVALID: test_data_missing.json fails with "'age' is required" (exit 1)
Verification
Check: python3 /root/.hermes/wizard-outputs/spark/json_schema_validator.py test_schema.json test_data_valid.json && echo "PASS"
line_counter.py - the lane's one text-statistics tool
The line/word/char counters this lane accumulated are retired: their last
revisions are in git and every path is paired with the commit that removed it in
WORK-QUEUE.md under Q125. What survives is one CLI whose output names the
question it answered, because the retired tools disagreed only on this and the
disagreement was invisible.
What each figure means
| key | definition |
|---|---|
lines |
newline-terminated lines: the number of \n bytes, identical to wc -l |
records |
lines plus one final unterminated fragment, so the two differ by exactly the files whose last row carries no trailing newline |
blank / comment / code |
.py files only, lexically: blank is whitespace only; comment is a line whose first non-space character is #; code is every other line, so docstring interiors and continuations count as code. A target with no .py file prints - rather than an uncounted 0 |
fields |
--fields: the first record parsed with the csv module, so "a,b",c is 2 fields where split(',') reads 3 |
words / chars |
--words: len(text.split()), and characters of the decoded text -- not bytes (wc -c is the byte question). Bytes decode as UTF-8 with errors replaced, so a latin-1 log reads as replacement characters instead of raising |
Usage
python3 line_counter.py PATH # lines, records, .py breakdown
python3 line_counter.py --fields PATH # CSV fields, quoted separators honoured
python3 line_counter.py --words PATH # words and characters
python3 line_counter.py --json PATH # any of the above as JSON
PATH may be a file or a directory (walked recursively, sums reported). Exit
codes: 0 report produced, 1 usage error, 2 unreadable target. The tool refuses
rather than reporting a partial total: an unreadable file inside a walk stops the
run and names the path.
Worked example
$ python3 wizard-work/spark/line_counter.py wizard-work/spark/test_log.txt
files: 1
lines: 9
records: 10
blank: -
comment: -
code: -
test_log.txt holds ten rows of text and nine newlines -- the case where lines
and records disagree, which is why both are printed.
Files
- line_counter.py - the surviving tool
- test_data.csv - fixture: one record, five fields
- test_log.txt - fixture: ten rows, nine newlines
- test_line_counter.py - the cell: 13 checks plus 5 applied mutants
- verify_line_counter.sh - second, independent shell leg
Verification
Both legs run from the repo root (each resolves its own directory):
python3 wizard-work/spark/test_line_counter.py
bash wizard-work/spark/verify_line_counter.sh
The first drives the tool as a subprocess and pins whole-output strings,
including the cells that kill a counter returning a constant, a counter counting
non-blank lines only, a records == lines variant, a split(',') field count
and a unique-word count; it then applies those five mutations to scratch copies
and requires each to turn the suite red. The second re-reads the same figures in
shell, so a cell that agrees with the tool by sharing its arithmetic shows up.
VERDICT: one text-statistics tool, its counting definitions stated and pinned by cells that die on the five mutations the old suite survived
CHECK: cd /root/troupe-standup && python3 wizard-work/spark/test_line_counter.py && bash wizard-work/spark/verify_line_counter.sh