Case study

Pocket Tasks: reconstructing task state and persistence

A teaching case with disclosed prior source access carries a REA-assisted investigation of a small command-line app into a separate Node implementation. It preserves observed task editing, persistence and selection behavior, then compares scoped outputs against fixed expectations and captured reference sessions.

Requirements and limitations

Pocket Tasks 1.0.0 is an authored local command-line app, not a commercial application or a native-binary benchmark. Its separate Node.js 20+ candidate implements nine commands and schema-1 JSON storage, including saved/draft separation, explicit save, cancel, restart and the original row-position selection quirk. It needs only the Node standard library and disposable local stores; there is no graphical interface or network backend.
The historical investigation combines REA JavaScript source analysis, ordinary source inspection and recorded process/file observations. The sanitized REA excerpt identifies the same target bytes but retains unknown semantic coverage and 230 semantic unknowns. It is not a canonical Evidence bundle or independent attestation, and parsing coverage is not behavioral equivalence. The later Node validator does not repeat that REA session.
The author had already seen the target source, reviewer scenarios, tests and prior answers before implementation. The candidate imports only Node filesystem/path modules; a published test definition copies its file alone before checking save behavior. Runtime independence from the reference does not establish independent discovery, a blind trial, clean-room provenance or an agent/model performance result.
The saved report records 16/16 checker process sessions across 12 scenarios and 10/10 replays of captured observations across seven scenarios. These overlap and must not be counted as 26 independent observations. The checker uses fixed, hand-authored expectations; responses and saved JSON are compared semantically, while malformed stores and foreign pending files use byte-preservation checks where required. The report retains humanReview=pending, reaTrial=unverified and independentEvaluation=false; these are author-reported results, not rerun by this collection.
The six recorded target/candidate/observation/validator/checker/packet-tool hashes and the oracle digest match the reviewed source. The report’s TASK.md packet hash instead matches an earlier instruction revision: a later edit changed review/authorization wording without changing the behavioral contract. Treat the packet record as historical evidence, not fresh validation of every file in the current package. The failure history also retains an initial restricted-Windows attempt with five passes and four failures, followed by nine passes with unchanged candidate code in a permitted local environment.
The contract bounds each invocation to 64 commands and 65,536 UTF-8 bytes, stores to 32 tasks and titles to 80 UTF-16 code units. Coverage is limited to named behaviors and tests; concurrent writers, crash durability, hostile filesystem races, UI behavior, hidden backends and production performance are outside the parity claim. MIT covers the authored example; upstream REA and other linked material remain separate. No target, candidate, checker, installer, model or upstream test was executed in this review.

About this entry

Type: Case study
Category: Community REA investigations
Relationship: Author-reported mixed workflow
Targets: App

Sources reviewed 2026-10-17

The description was reviewed against primary sources. This does not establish runtime testing, security auditing or verified compatibility.

Requirements and limitations

About this entry

Primary sources