One delivery. A better next plan.

See what the workflow leaves behind

1. A request becomes a concrete proposal

   The request: “Let me download my bookmarks so I can keep a copy and move them elsewhere.” The agent writes a proposal with a file format, acceptance criteria and exclusions.

   Add one visible, enabled Export button to Beacon’s existing local interface. Activating it downloads the current saved bookmark collection as a single local JSON file named beacon-bookmarks.json. The export is generated entirely in the browser without fetching stored URLs or sending bookmark data over the network.

   Actual proposal excerpt · proposal-only work, before acceptance

2. Review determines the next step

   The test harness supplied an explicitly synthetic acceptance of that exact proposal and authorized tracked implementation. The agent then created the epic/tasks and built export. In the rejected and unanswered cases, it left implementation untouched. A changed proposal required another review.

3. Verification earns a local handoff

   Contract tests passed, but the agent could not start its browser checker's local server. It recorded the failure and withheld a handoff. The supervisor ran the unchanged checker on the same application revision in a clean clone. Real Chrome clicks produced populated and empty downloads; their bytes and storage behavior were checked.

   A fresh agent matched that browser receipt to the application and checker sources, retained the earlier failures, and completed the local handoff. This was assisted verification, not an unattended browser run.

   Beacon now provides a visible Export bookmarks button that downloads the collection currently shown as beacon-bookmarks.json. The version-one JSON preserves bookmark titles, URLs and tags, including Unicode, and exports an explicitly empty collection successfully. Export stays local, leaves stored bookmarks unchanged and does not fetch stored URLs. Import, selective export, alternate formats, cloud services, sharing, encryption, compression and filename customization are not included.

   Final verification excerpt · Actual handoff excerpt · ready for release review, not published

4. The project retains the decision

   Beacon version-one export is a whole-library local JSON download with the exact envelope { "schemaVersion": 1, "bookmarks": [...] }. Each bookmark contains only the existing title, url and tags fields in their existing order, with Unicode preserved. The fixed filename is beacon-bookmarks.json; an explicitly empty saved collection exports bookmarks: []. Export does not mutate storage, fetch stored URLs or add a dependency.

   Actual decision excerpt · retained in project Markdown

5. A fresh session uses it

   The new prompt supplied no export decisions: “Plan support for importing a previously exported Beacon bookmark file.” The agent found the retained decision and proposed import validation and confirmation behavior. Two excerpts from its response:

   - Accept .json files using the verified schema { "schemaVersion": 1, "bookmarks": [...] }. - Have the effective product owner review these new decisions; the existing export approval does not settle validation, conflict, or storage-write behavior.

   It distinguished the established export format from new import choices needing review. The planning request changed no files or tasks.

   Actual fresh-session excerpts

Try with a 0.4.1 candidate

Prerequisites: GitDocket 0.4.1 installed with Homebrew or npm, Git and a coding agent. This example app and its scripts also need Bun 1.3.14+. Full verification needs Chrome/Chromium and permission to run a local server. Codex was the host used for the recorded agent tests.

The download below contains the workflow, starting app, checks and guide, not the CLI or a pre-completed delivery. Bun is needed by the example app; the installed GitDocket commands do not need a separate Bun runtime.

1. Prepare a disposable project

Download the workflow examples and extract them. From the extracted directory, run the following, replacing both absolute paths. The destination must not already exist.

bun scripts/extensions/prepare-example.ts --dest=/absolute/new/beacon --cli=/absolute/installed/docket
cd /absolute/new/beacon
bun run docket -- extension show product-delivery --json

The helper initializes GitDocket and installs/enables the canonical product-delivery and incident-review packages through that CLI. It creates no proposal, acceptance, implementation tasks or export feature. The synthetic issue text is already saved in docket/requests/BEC-42.md; the default example needs no issue-tracker connection.

2. Make one project choice

bun run docket -- extension configure product-delivery --set '{"reviewer":"release owner"}' --json
bun run docket -- extension show product-delivery --json

Check that the effective reviewer is release owner, owned by the project. This names the required reviewer; it does not approve anything. The earlier observed run used the default product owner.

3. Ask for a proposal, then review it

Open the prepared repository in a fresh coding-agent session and ask:

Use product-delivery:deliver to prepare a proposal for Beacon issue BEC-42. Bring it back for review before planning implementation.

Read the actual proposal and retain its exact hash or commit. The configured reviewer can accept it, request changes or reject it. Any review supplied for a test must be labeled synthetic. Acceptance must identify the proposal revision and state whether planning or implementation is authorized. Ask explicitly for task creation if you want a tracked plan. You can stop after the proposal.

4. Deliver the accepted change

After authorized implementation, the agent runs these supplied checks and retains the results:

bun run test:baseline
bun run test
bun run test:browser -- --output=/tmp/beacon-browser.json

The starting app intentionally fails export checks. After implementation, all required checks must pass, including actual completed browser downloads. A missing browser, denied local server or failed assertion leaves delivery unresolved. The local handoff links the reviewed proposal, implementation, verification and decision. Sending it or publishing a release is a separate action.

5. Let the next session use the decision

After the verified handoff, open another fresh session in the same repository:

Plan support for importing a previously exported Beacon bookmark file.

Look for a source-backed plan that reuses the saved export contract and identifies new import decisions needing review. This prompt asks for planning; it should create no tasks or code.

To adopt the package in an existing project or write a different process, use the extension reference. The archive's examples/product-delivery/README.md documents the application interface and optional local MCP fixture.

What we verified

Actual Codex sessions exercised the installed workflow. The successful path produced the records above, with the disclosed browser assistance. Other sessions tested what should happen when work cannot proceed:

• Review stops: rejected or unanswered proposals produced no implementation; revised proposals remained unaccepted.
• Failed checks: an intentionally broken schema failed real assertions, even with a prematurely completed task.
• Continuation: fresh sessions resumed from retained records and reused accepted decisions.
• Tool uncertainty: a local synthetic MCP provider exercised missing tools, wrong-revision checks, definite post failure and uncertain delivery. Status reconciliation avoided a duplicate post, including after a fresh session.