Bac à sable d'entraînement

Save draft — fictional first-run sandbox

This local exercise gives a Product Builder one bounded outcome: an author can recover a confirmed draft after returning, while a second user cannot read it. A failed save must leave the edit visible in the current page with an error and Retry action; reloading before a successful retry restores only the last confirmed draft.

The starter application is intentionally incomplete. Its acceptance tests are meant to fail at first. Do not call a green server startup, a design mockup, or a successful POST a completed product outcome.

Requirements and run

• Python 3.9 or newer (checked with 3.9.6, the version macOS ships). No package installation, external service, account, or internet connection is needed.
• From this directory, run python3 app.py and open http://127.0.0.1:8766/.
• Run the acceptance checks with python3 -m unittest -v test_acceptance.py.
• The server binds to 127.0.0.1 only. It creates sandbox.sqlite3 beside the app; delete that generated file to reset the manual exercise. Tests use a temporary database and do not touch the manual one.

The only identities are Avery Example (author) and Blair Example (reviewer). They are fictional buttons backed by a local test cookie, not real authentication. There is no password or credential. This fixture is for practicing owner-specific behavior; a real product needs its organization's approved authentication and authorization design. Never deploy this server or put real user data into it.

Starting evidence

The database begins with one confirmed draft, ID fictional-draft-001, owned by Avery and containing “The imaginary library opens next Tuesday.” The direct read route is GET /api/drafts/fictional-draft-001. The form posts to POST /save. The Simulate failed save button sends simulate_failure=1, making the failure reproducible without an external service.

Three deliberate defects make the exercise meaningful:

1. Save says “Saved” but does not persist the submitted text, so Avery cannot recover it after reload.
2. The direct read route returns Avery's draft to Blair, although the UI does not show it.
3. The failure switch causes a deterministic write failure inside the storage layer, but the handler swallows it. The response claims success, drops the edit from the current page, and offers no Retry.

The three acceptance tests are written against the intended behavior, not the starter defects. Expect 3 failures before implementation. Three errors instead mean the environment stopped the tests from starting their local server on 127.0.0.1.

Running the tests from Codex. Codex's default workspace-write sandbox blocks that local server, so the tests end in three PermissionError errors before reaching the intended failures. Allow network access for the session, for example codex --sandbox workspace-write -c sandbox_workspace_write.network_access=true, or run the test command yourself outside the sandbox. Checked with Codex CLI 0.155.0-alpha.9.2. A future passing test run checks the server behavior, but an independent reviewer should also inspect the running UI, including the error message, keyboard use, and narrow-screen state against an accepted design.

Exercise task

Use the method core and first-case worksheet. Classify this synthetic case, write a bounded brief, identify the Design, Frontend, and Backend/API contributions, and record a human-reviewed design for empty, editing, saving, saved, failed, and return states. Check the available conventions and service routes; this tiny sandbox has no approved organizational frontend starter or production access path. Treat those as exercise gaps to record, not as permission to invent another organization's standards.

After the design and capability decisions are recorded, implement the behavior inside this directory. Use the tests as acceptance evidence and inspect the rendered experience as both identities. Preserve Avery's last confirmed text when a save fails. Deny Blair through the direct endpoint as well as the interface. Report the exact behavior observed and leave the independent QA verdict to another reviewer.

Deletion, expiration, offline edits, concurrent writers, and real authentication are outside this exercise. No public publishing or deployment is part of the run.