• 

  Working browser prototype with a synthetic workshop plan: one next action, preserved context, and a local decision history.

OneClearStep

Tagline: Resume an interrupted plan with one clear action, the last context, and uncertainty that cannot silently become done.

Inspiration and intended user

A student coordinating a workshop returns after an interruption. A room request was sent, but there is no recorded confirmation. Sending invitations now assumes success; repeating the request risks doing it twice. OneClearStep focuses on this small handoff problem: preserve what was last known and ask for the missing check before a dependent action.

What it does

A local plan has tasks, prerequisites, context and three recorded states: pending, done and uncertain. The planner selects one actionable check or ready task. A prerequisite that is not effectively done blocks descendants, even if a descendant has an old done record. The user records a result; the app never contacts a booking system, sends a message or claims external completion.

The browser supports new plans, task creation with prerequisites, context editing, local history and JSON export/import. A separate Python CLI exposes the same resumption decisions using a locked append-only JSONL journal. The two journal formats are explicitly different.

How it was built

New implementation on October 19, 2026, using native HTML/CSS/JavaScript and Python standard-library code. The browser uses Web Crypto, Web Locks, local storage, native dialogs and labeled controls. The CLI uses file locks, revision checks, caller-supplied operation IDs, hashes and fsync. No paid API, external AI inference or account is required at runtime.

Codex generated source, tests, synthetic examples and copy. Image Gen supplied a visual reference. No previous contest application's source was reused. The current implementation is code, not a clickable screenshot.

Demonstrated change

In the synthetic workshop example, an uncertain booking is the next check and invitations are blocked. Recording the booking as done unlocks invitations. Reopening the booking as uncertain blocks them again. This demonstrates decision behavior, not measured productivity gains.

Technical evidence

Fourteen Python tests pass, including two actual competing processes where only one revision commits, idempotent retries, stale-write refusal, torn/tampered history and Unicode separators inside journal strings. Eleven JavaScript checks pass, including Python/browser decision agreement and hash-chain validation.

The actual browser exercised task creation, new plans, dependency blocking, two-tab stale-state protection, JSON download/import and reload persistence. A 390 CSS-pixel iframe layout was inspected. No physical-device, screen-reader, field-user or quantified productivity study has been performed.

Design and implementation findings

A visible uncertain state needs a corresponding dependency rule; a color label alone would still permit the wrong next action. Likewise, a saved-looking interface is insufficient: the implementation commits browser storage before changing its displayed revision and refuses stale writes. These are observed implementation decisions, not claims about the account owner's personal learning experience.

Limits and next steps

Task states are user assertions. Hashes are not signatures. Local browser and file locks cover cooperating writers, not hostile scripts, distributed teams or every storage failure. Exports contain context and earlier history and should be kept private when that content is sensitive. The browser and CLI journal formats are separate.

Planned: controlled usability sessions with students returning after interruptions, keyboard/screen-reader testing with participants, and user-controlled migration between clients. No diagnosis, cognitive benefit, real-world reliability or time savings is claimed.

Built With

• javascript
• python