Document workbench #

Outcome #

Build one useful interaction in thought stream:

Open an event → create a working document linked to it → select supporting context → inspect a proposed edit → accept or reject it → retain the version and judgment.

The Stream should become a persistent workspace that agents can operate on. This assignment proves one document workflow; it does not implement a general task scheduler, a new agent runtime, or an entire collaborative editor.

Starting point #

Start from the current remote main in an isolated worktree. Read AGENTS.md and spec/README.md, then the relevant specifications before editing. Inspect these existing surfaces rather than building equivalents:

• src/jazz/schema.ts, src/jazz/store.ts: document versions, document projections, events, and the async alpha.55 store API.
• src/connectors/filesystem.ts: observed-file provenance.
• src/agent-proposals/, src/review/, src/training/: proposal/decision, review, and judgment contracts.
• src/agents/context.ts: selected-document context and exact input snapshots.
• src/web/inspector.ts: existing feed and evidence UI.
• src/web/authenticated-proxy.ts, spec/web-auth.md, spec/security.md: owner authentication and mutation permissions.
• spec/jazz-alpha55-port.md: dedicated storage ownership and runtime requirements.

Current documents are primarily observed file versions, not a general writable editor. Decide explicitly whether an editable working document extends that contract or needs a separate kind. Do not make editing an imported document silently modify its original file. Tasks remain outside this slice unless a minimal status field is necessary for the document interaction.

Implement #

1. Write a short contract in the owning specs: document identity, source links, version identity, current-head projection, proposal state, access, and judgment lineage. Name the specific existing mechanisms you will reuse.
2. From an event detail view, create an operator-owned working document that retains the event reference. Use a title and editable body with minimal controls.
3. Allow explicit selection of supporting events/document versions. Record the exact versions used, not just mutable current titles or model-generated citations. Clearly distinguish selected evidence from any broader context the execution harness actually supplies.
4. Accept a structured proposed edit from a pluggable runner seam. Start with a deterministic fixture runner for the end-to-end demonstration. There is separate fx-consumer work: coordinate the request/result contract rather than implementing another fx adapter or assuming its current capabilities.
5. Show the proposed diff against its exact base version. Acceptance appends a version and advances the head through the trusted mutation path; rejection appends a decision without changing the document. A proposal based on a stale head must fail closed or require a new proposal. Do not silently merge or overwrite.
6. Record the accepted/rejected judgment with links to the proposal, base version, resulting version if any, source/context snapshot, and run when present. A completed model run is not training consent; do not automatically export judgments or private documents into training data.

UI #

Use the existing Stream layout, neutral light/dark colors, purple accents, and compact typography. Keep the interaction inside the current app navigation. No separate brand, onboarding essay, uppercase eyebrow, oversized hero, decorative numbered steps, or marketing copy.

The operator should be able to find the working document again, see its sources, inspect a proposal, make the decision, and inspect what changed. Explain errors at the action that failed. Preserve unsaved work and make uncertain request outcomes explicit; do not blindly resend mutations.

Limits #

• No Co or other agent memory migration, agent creation, history import, credential changes, or model-default changes.
• No public posting, notifications, live connector changes, deployment, or root web-server changes.
• Use synthetic fixtures and isolated stores only. Never run tests against a production database or mount production environment files into a test worker.
• Keep model-generated text untrusted. Do not render active HTML, allow arbitrary URLs/file access, or turn a document into authority to execute actions.
• Keep Jazz owner/backend credentials server-side. Existing fixture policies are permissive and do not establish safe direct browser synchronization. Route writes through the authenticated trusted server; richer multi-user editing needs a separate permission contract.
• No real-time multi-user collaboration, broad editor framework, or new workflow language in this slice. Preserve a path to future collaboration without claiming it is implemented.
• Do not touch unrelated worktrees or another worker's fx changes. Do not commit, push, or deploy without an explicit instruction from the coordinating operator.

Acceptance evidence #

Test the real application path with synthetic data:

• Create a document from an event; source reference survives reload.
• Select exact supporting versions and inspect the retained context snapshot.
• Generate a deterministic proposal and inspect its diff.
• Accept once: exactly one new version and one attributable decision; duplicate submission does not create extra versions.
• Reject: decision retained, document unchanged.
• Change the document before accepting an old proposal: stale-base conflict shown, newer work preserved.
• Cancel or interrupt the request: no silent mutation replay; reconcile uncertain state before another effect.
• Unauthenticated, wrong-owner, and cross-origin mutation attempts are rejected before private objects or effects are exposed.
• A second independent client and an owner restart see accepted versions consistently. State which clean-restart/crash guarantees were actually tested.
• Browser checks at desktop and narrow mobile widths, in light and dark themes: no overflow, usable editing/review controls, no unexpected external requests, no model-authored HTML execution.

Run pnpm check, pnpm build, pnpm test, and git diff --check in the compatible Jazz runtime. Keep nested-sandbox test permissions separate from deployment. If the environment cannot run a gate, report the exact blocker; do not replace it with a mock and call it equivalent.

Handoff #

Return source branch/base, changed files/specs, screenshots, exact commands and exit results, a short reproduction walkthrough, and remaining limitations. Separate implemented code, verified fixture behavior, and anything requiring deployment or real model execution. The finished artifact should make one workflow understandable and usable, not merely expose database tables.