FE-1573: Add workpiece, construction and explanation groundwork (Mission 7a)

[lunelson]

🌟 What is the purpose of this PR?

Deliver Mission 7a's workpiece, native construction and record-backed explanation groundwork. Brunch can save an evolving account, apply a bounded set of Petrinaut edits through the browser, and retrieve an edit's declared workpiece basis and linked conversation evidence through chat.

This is now an implementation PR, not the original authority-only cut. The workpiece appears in a Workpiece tab beside AI inside the existing assistant panel, replacing the intrusive overlay. Tab switches preserve the conversation, draft and active controls. The result establishes mechanical integration, not semantic model quality or the complete September demo.

Lu has split the remaining demo work into Mission 7b under the same FE-1573 issue. This PR remains draft pending UI review and integration with FE-1645.

🔗 Related links

• FE-1573 (internal) — tracks both the explicitly split 7a and 7b deliveries; this PR does not complete all issue scope.
• FE-1478 (internal) — provenance outcome.
• #9564 — merged Voice/recovery foundation, with its narrower claim retained.
• #9634 — colleague-owned opt-in prepared-fixture selector; distinct from this workpiece tab.
• Current mission
• Mission 7b proposal

🚫 Blocked by

• Lu's review of the tabbed workpiece placement.
• Coordinate FE-1645: Show the prepared-fixture selector only in Brunch demo mode #9634 landing/integration and verify the combined host: no default prepared-fixture chrome, opt-in selector preserved, workpiece tab unaffected.
• Required PR checks and code review. Local checks below do not imply CI acceptance.

🔍 What does this change?

• Saves revisioned Markdown workpieces with optional explicit source links and makes successful saved output visible without a second model-chosen query.
• Carries canonical Petrinaut inputs, declared operation basis, bound browser observations and complete edit effects; retains failed/unknown attempts without turning them into causes.
• Resolves recorded element/field origins, workpiece passages and supplied source-message links through brunch_why. Current versus historical observation, missing basis and outside changes remain explicit.
• Integrates root node/arc, typed-state/scenario and bounded parameter/equation operations. This is not full Petrinaut tool parity or automatic evidence coverage.
• Supplies the maintained isolated persona/browser launcher, startup/cleanup fixes, original-store recovery checks and all-authorized-source-ID discovery after folding.
• Adds optional generic aiAssistant.additionalTab host content using Petrinaut's existing horizontal tabs. Brunch owns document rendering; raw IDs/Markdown/why JSON are expandable details. Composer, Stop, Voice and resizing remain the existing controls.
• Removes the construction debug strip that covered the title. Does not copy or change FE-1645: Show the prepared-fixture selector only in Brunch demo mode #9634's selector/settings implementation.
• Re-triages the mission: UI closeout in 7a; live open/explain/correct/update and the desired complete elicitation/construction video in 7b; broader modelling/evaluation portfolios after the demo.

🏗️ Agent notes

The current six-section mission contract follows. Code/tests and native local records carry implementation evidence; no new repository run packet is introduced.

Mission 7a — Workpiece, construction and explanation groundwork

Status

Part A closeout in progress; tabbed workpiece implemented, pending Lu's UI review and FE-1645 integration before merge. Not a demo or semantic-quality acceptance. Lu has directed a split: this branch and PR #9562 carry the mechanical groundwork; Mission 7b continues under the same FE-1573 issue on a child branch. The former full-region/100%-useful-explanation acceptance programme is not a prerequisite to this engineering split. Its surviving evaluation obligations live in the after-demo evaluation draft; the focused demo successor is the Mission 7b draft.

The current implementation saves and displays evolving workpieces, observes a bounded set of native Petrinaut mutations, and resolves their recorded basis through chat. Controlled browser tests exercise the broader surface. The retained persona session contains one parameter, one type and one equation, not a connected process model. Its lineage queries and original-store reopening were observed; semantic correspondence, automatic citation coverage, a complete construction flow, portability and demo readiness are not established. No persona, browser or paid run is active.

Local-only / not portable: the actual-session oracle is apps/brunch-agent/.data-wipe-me/persona-runs/run-7ceo9j/ and the original apps/brunch-agent/.data-wipe-me/conversations.db. Inspect the native history, saved revisions and observed definitions, not an invented reconstruction. These local records establish observed behaviour without claiming repository-reproducible fixtures or teammate access. Commits, tests and the PR are the engineering record.

Imperative

Deliver the working integration from conversation to saved workpiece, browser-applied net edits and record-backed explanation, with a usable workpiece surface rather than an intrusive debug overlay. Make that bounded result reviewable and landable independently of the complete September demo and evaluation of the prompt/skill architecture's modelling effectiveness.

The harness is structurally checked, not a semantic acceptance engine. A valid reference, applied edit or successful lookup is a mechanical result; a good model or persuasive rationale is a different judgment. Preserve that distinction without making the latter a universal execution gate.

Throughline

Petrinaut Brunch chat / attached persona
→ mounted Flue ChatAgent
→ core workpiece revision + optional passage/source relations
→ plugin mutation request + declared workpiece basis
→ browser executes canonical Petrinaut operation and returns observed effects
→ chat why resolves element/field → edit → revision/passage → linked source messages
→ reopen the original session and continue querying

Delivered construction boundary

In conversation-bound construction mode, the observed mutation catalog is:

Object	Operations
Root place / transition	addPlace, updatePlace, addTransition, updateTransition
Root place–transition arc	addArc, updateArcWeight
Type / ordered attribute	addType, updateType, addTypeElement, updateTypeElement
Scenario	addScenario, updateScenario
Root parameter / differential equation	addParameter, addDifferentialEquation

These fourteen operations are not stock-tool parity or fourteen genuine-persona demonstrations. Deletion, parameter/equation update, nested nets/components and component-port arcs are outside this observed surface. Typed-state operations also reject documents containing subnets/components. Canonical input/refinement rules still apply. Necessary native reads and compilation checks accompany this surface; compilation does not prove simulation.

UI closeout before merge

FE-1645 / PR #9634 gates the existing prepared-fixture selector behind an opt-in Brunch demo setting and moves it below the top bar. That selector is distinct from this branch's fixed BrunchWorkpiecePane. Preserve the colleague's selector/provider behaviour when integrating; do not restore default fixture chrome or copy a competing settings mechanism.

The workpiece now uses AI / Workpiece tabs in the existing assistant panel, selected by Lu in place of the separate dock. Reuse Petrinaut's tab patterns and the assistant's existing resize/collapse behaviour. Keep chat mounted across tab switches so drafts, requests and Voice lifecycle survive; maintain reachable active controls. The additional-tab extension point is generic, while workpiece/provenance semantics stay in the website host. The surface remains readable as it evolves and does not obstruct the canvas, top bar, assistant opener or composer. Keep engineering IDs, hashes and raw why payloads out of the primary reading surface while preserving inspectable provenance and honest freshness/unknown-state reporting. Hiding the useful workpiece together with fixture controls is not the fix. Inspect integration against #9634 without rewriting the colleague's branch; no full editor redesign or construction-tool rewrite belongs in this closeout.

What is linked

Petrinaut references connect net objects; they do not propagate provenance. Separately, workpiece evidence relations link revision-local text spans to authorized conversation message IDs. A construction request cites a saved revision/hash, passage locators and an operation-level rationale, or an explicit absent-basis reason. The matching browser result records actual changes. Why traverses those records; it does not infer source links from adjacency, graph connectivity or plausible prose. Brunch metadata remains outside canonical Petrinaut documents.

The implemented positive declared-basis path reports partially-supported: operation-level links are not independently established field-level intention mappings or semantic grades. Queries can identify an object/field by unique name or ID; canvas-selection-to-source-navigation UX is not claimed by this part.

Proof

Review the existing code/tests and actual-session records under their respective claim scopes. No new model-quality campaign is required to submit Part A.

Claim	Oracle and limit
Saved workpiece is visible and remains queryable	packages/core/test/update-workpiece.test.ts, apps/brunch-agent/test/workpiece-revisions.test.ts, website brunch-workpiece-pane.test.tsx, and actual persona history/display observations. Pointer-only historical results remain readable but do not invent Markdown.
Native mutations carry shape, binding and complete effects	Plugin test/root-node.test.ts, test/root-state.test.ts, test/declared-basis.test.ts; app test/root-creation.integration.ts and test/typed-state.integration.ts. Broader controlled-browser evidence, not a claim of a complete persona-built model.
Why resolves recorded changes and citations honestly	App test/reconciliation.test.ts, test/reopened-why.integration.ts and the retained ordinary persona-session why results. Source linkage may be absent; prose quality is not guaranteed by the structured result.
All authorized source IDs remain discoverable	Core test/update-workpiece.test.ts and app test/reopened-why-retention.integration.ts, implemented in 367d4994fa. Source text may be clipped; IDs are not windowed.
Original-store stop/reopen preserves the actual conversation	Native session history and browser observations under the run above. This is verified local-only evidence, not a fresh-store import, clone or remote durability claim.
Persona launching and shutdown use the maintained entrypoint	src/evaluations/persona/launch.test.ts, test/persona-browser.integration.ts, actual launcher cleanup observations. Run-local Pi trust does not add persona tools or persistent trust.
Workpiece UI is usable and compatible with FE-1645	A real-browser witness at the integrated revision: ordinary mode has no unsolicited fixture chrome; demo mode retains the selector; a long evolving workpiece remains readable with canvas/chat controls reachable; saved-query/freshness behaviour survives. Use the website workpiece and host tests for regression, then Lu reviews the placement before merge. No provider run is required solely to test layout.
The PR accurately states the bounded result	Review #9562's purpose, tests, known issues and six-section mission summary against this contract; retain existing package checks and changed-package publication obligations. Review/merge acceptance remains external.

Before the branch transition, retain unresolved obligations in the future record, remove the consumed ownership side quest after recording its outcome, and archive this contract with the engineering-split status explicit. Do not mark the former full Step A acceptance programme passed.

Constraints

Earned data and execution contracts

• Core owns brunch_mark_question, durable nonterminating update_workpiece and current-workpiece query semantics. Keep one current revision: native tool-call ID, Markdown/hash and display ordinal. A saved version is not an owner-approved meaning.
• Preserve settled revision/basis/locators/rationale/scope or an explicit absent reason in canonical history. Source relations resolve to authorized true-user messages in the same conversation; assistant, signal, prepared and foreign material is not elicited testimony. brunch_workpiece returns every authorized source ID; per-source text may be truncated. Unique unchanged same-span carry is bounded; candidate locator queries create no revision, authority or semantic-continuity claim.
• Preserve the current complete-proposal checks, single-browser-call continuation and refusal of mixed browser/server proposals. A future tool-surface redesign must explicitly revisit those contracts where necessary; this split does not weaken or canonize them as the only future design.
• Browser edits use the bound document/incarnation and a prior verified full read. Account independently for all direct and derived effects. Defaults, coercions, generated values and migrations do not inherit testimony or declared intent automatically. Duplicate/retired IDs and conflicting/unknown outcomes remain explicit; failed, no-op, stale and unknown attempts are not causes or permission to replay.
• Keep origin, current changes and attempts distinct. Why uses a verified observation or an explicit as-of scope; a historical call ID alone is not live evidence. Object-key-order equivalence does not relax arrays, field presence, values or mutation base hashes. Outside edits are not attributed to Brunch.
• Petrinaut owns canonical schemas, native input semantics/refinements, mutations, compilation and simulation. Preserve the maintained Flue/Pi carriage/recovery patches, stock-assistant isolation, capacity absence/null/zero/positive semantics, visible Not applied outcomes and publication obligations. No copied schema catalog, second provenance store, graph, observer, runner or generic projection engine.
• Preserve Mission 6b's causal Voice/tool results and active Stop. Direct spoken-user attribution after hydration, durable withholding after settled steps and comparative latency remain unproved. Workpiece/basis/tool payloads are not spoken assistant prose.
• Keep useBrunchAgent() plus useSdcpnPlugin(), inward dependencies and dedicated ./flue resources. Prepared fixtures stay test-authored; diagnostic exports are not restoration APIs. No content-bearing telemetry, hidden persona-pack leakage or guessed operational facts labelled as testimony.

Continuing operating limits

The persona's pack grounds a realistic role, not a closed factual whitelist. Natural improvisation, uncertainty and correction are allowed. Only the actor receives private background; it supplies interview utterances, not construction instructions. Keep persona and operator submissions serial, distinguish operator technical choices from testimony, and never replay old unanswered browser requests.

The maintained launcher uses Pi's run-local --approve with its explicit tool/extension allowlist and disabled context/skill/template discovery. Both persona and ChatAgent use anthropic/claude-sonnet-4-6 with BRUNCH_STEP_A_ACCOUNTING unset. Do not revive retired per-request holds, response deadlines, call-count gates or ledger writes; the historical ledger retains its unresolved row and released hold. Existing owner spending/escalation policy remains; this documentation split starts no provider run. Remote writes, release and Linear writes remain separately authorized.

Owner decisions

• 2026-09-10 — Part A/7b split. Lu directs this engineering groundwork to its own PR and a focused Mission 7b child branch under the same FE-1573 issue. This is the specific exception to one-issue/one-PR bookkeeping; one live mission per branch remains. It supersedes treating the former semantic-quality/full-region programme as the condition for landing Part A, not the validity of its historical findings.
• 2026-09-10 — UI before Part A merge. Lu requires UI remediation before merging 7a, coordinated with FE-1645/FE-1645: Show the prepared-fixture selector only in Brunch demo mode #9634. This moves the workpiece-placement fix from the proposed 7b scope into Part A closeout. Lu initially selected a separate dock, then replaced it with AI / Workpiece tabs in the existing assistant panel to conserve visual space and limit implementation. The tab choice is current.
• 2026-09-10 — Demo priority. Live open → explain → correct → update is the assumed demo story; a prerecorded complete elicitation/construction video is the desired additional output. UI remediation and an effective construction path are pre-demo concerns. The tool approach will be discussed separately; neither allowlist expansion nor a replacement construction tool is selected here. The 7b draft owns the successor detail.

Fog-line

• Construction surface: individual instrumented operations work; a smooth complete conversation-driven construction sequence remains unproved. Mission 7b must settle the tool approach before broadening or redesigning it.
• Link coverage: optional relations preserve supplied links, not automatic completeness. The demo needs ordinary interaction that creates and retrieves the links it shows, without operator citation-offset instructions.
• UI: the tabbed surface is implemented and browser-tested; Lu's placement review and combined verification with FE-1645: Show the prepared-fixture selector only in Brunch demo mode #9634 remain pre-merge. Source-navigation polish and the complete correction interaction remain successor work. Confirm FE-1645: Show the prepared-fixture selector only in Brunch demo mode #9634 integration/landing order rather than copying its selector/settings changes.
• Delivery: original-store recovery is observed. Actual demo host, independent-copy requirements, source selection and current deployed frontend/backend revisions remain to be inspected/decided.
• Modelling: the inert clock is an exercised native operation, not an adopted stochastic/dynamics strategy. Modelling effectiveness and broader semantic acceptance remain separate evaluation work.

Stop or reorient

Stop Part A expansion if a task is building the full demo rather than fixing the explicitly admitted UI blocker or a defect in the PR's stated mechanical claim. Preserve and report source/identity corruption, false effect attribution and unavailable native state; a fluently explained result must not conceal them. Do not gate this engineering split on full model fidelity, a new persona campaign, an optimiser, a new tool design or every historical proof-matrix row. Do not claim the deferred evaluation or demo passed.

Deferred

• Mission 7b: the focused September live flow, desired construction video, UI/tool ownership work and necessary delivery joins.
• After-demo construction/explanation evaluation: full-region semantic/behavioural and useful-explanation evaluation, broad passage/adversarial and lifecycle matrices. These remain evaluation questions, not automatic runtime semantic gates.
• Future spine: template delivery and current-host inspection; Missions 9/10 broader repeat/change/retirement/concurrency/reviewer scenarios; Mission 11 consumer-defined optimisation; assumption-preview and other plugin/source work. Bring forward only what the agreed demo actually consumes.

Pre-Merge Checklist 🚀

🚢 Has this modified a publishable library?

This PR:

• modifies an npm-publishable library and I have added a changeset file(s)

📜 Does this require a change to the docs?

The changes in this PR:

• require changes to docs which are made as part of this PR

The assistant guide covers the Workpiece tab and retained controls. Screenshots pending: maintainer capture/upload for the opening-panel and Workpiece sections.

🕸️ Does this require a change to the Turbo Graph?

The changes in this PR:

• affected the execution graph, and the turbo.json's have been updated to reflect this

⚠️ Known issues

• The observed construction mode instruments fourteen mutation operations, not all native operations: add/update place, transition, type, type element and scenario; add arc/update arc weight; add parameter and differential equation. No delete operations, parameter/equation updates or nested/component-port construction on that surface.
• Links are explicitly authored. The machinery validates and follows them; it does not infer absent evidence or propagate provenance along net connectivity. Positive declared-basis answers are operation-scoped and report partially-supported, not a semantic quality score.
• The retained persona session created only a parameter, type and equation. It is not a connected process model or full construction demonstration. The clock probe is not an adopted dynamics/stochastics design.
• Original-store reopening is observed locally. Portable templates, independent copies, exact deployed-version verification and the complete live correction/video flow remain unproved.
• Browser mutation and Flue result admission are not one cross-store transaction. If admission fails or the tab reloads after a browser edit, the document may retain an unexplained change; reconciliation fails closed as unknown/external and never replays or invents provenance.
• Construction is single-tab only. Concurrent tabs can hold stale copies of the same document incarnation and localStorage remains last-writer-wins; multi-tab locking, stale-write arbitration and durable cross-store recovery are deferred concurrency work.
• Direct spoken-user attribution after hydration, durable recovery of locally withheld post-settlement work, and comparative Voice latency remain inherited limits.
• FE-1645: Show the prepared-fixture selector only in Brunch demo mode #9634 is open. Combined integration and owner UI review remain necessary before merge. This PR remains draft.

🐾 Next steps

• Review the Workpiece tab, integrate compatibly with FE-1645: Show the prepared-fixture selector only in Brunch demo mode #9634, and finish Part A review/CI.
• Cut ln/fe-1573-mission-7b from the inspected Part A boundary under the same issue, with one live mission on that branch.
• Discuss construction-tool design before broadening or replacing the current surface. No new stochastic/dynamics policy or full semantic evaluation programme is implied by the demo.

🛡 What tests cover this?

• Forced local Turbo gate at this implementation: 52 successful build/unit/typecheck/lint tasks, zero cached. Selected packages: @hashintel/petrinaut, @apps/petrinaut-website, @apps/brunch-agent, with their dependencies.
• Focused assistant-panel/content suites: 116 passing tests, including host-tab forwarding without a submission, tab withdrawal, keyboard navigation, draft/Stop retention and Voice-slot survival.
• Real Chrome persona/browser integration: 10 checked assertions, 14 faux-provider requests. Exercises two visible saved revisions, tab switching, actual mouse resizing, draft retention, reload, ordinary browser mutation/guide continuation, and preservation of old unanswered calls. Synthetic model responses; not a persona-quality result.
• Root formatting check passed. Existing construction, reconciliation, source-discovery and retention suites remain in the branch; their scoped proof limits are in the mission.

❓ How to test this?

1. Run the affected gate: VITE_BRUNCH_CHAT_ENDPOINT=/agents/chat turbo run build test:unit lint:tsc lint:eslint --filter @hashintel/petrinaut --filter @apps/petrinaut-website --filter @apps/brunch-agent.
2. For the synthetic complete browser wiring check, run node --experimental-transform-types test/persona-browser.integration.ts from apps/brunch-agent after building with that endpoint. The test uses a local faux provider, writes screenshots/native test records to its reported temporary directory, and makes no live model call.
3. In a Brunch construction conversation, open the assistant and switch between AI and Workpiece. Verify the saved document renders, the draft survives, resize/close/reopen work, and active controls remain reachable. Expand Recorded details for raw records.
4. After FE-1645: Show the prepared-fixture selector only in Brunch demo mode #9634 integration, verify ordinary mode has no unsolicited fixture selector and its demo-mode toggle still works. Do not use a private retained run as a claim of portable setup.

📹 Demo

The local browser witness includes screenshots of the new Workpiece tab and a long document; maintainer upload is pending. The complete elicitation/construction recording and live review/correction demo are Mission 7b targets, not completed results of this PR.

---

• FE-1573: Construct and correct Petrinaut nets through Brunch #9649
• ln/fe-1573-construct-and-explain 👈
• main

^{Stack generated by Git Town}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
hash	Ready	Preview	Sep 11, 2026 7:53am UTC
hashdotdesign-tokens	Ready	Preview	Sep 11, 2026 7:53am UTC
petrinaut	Ready	Preview	Sep 11, 2026 7:53am UTC
petrinaut-docs	Ready	Preview	Sep 11, 2026 7:53am UTC

[lunelson]

• FE-1573: Add workpiece, construction and explanation groundwork (Mission 7a) #9562 👈 (View in Graphite)
• FE-1580: Reconcile Voice turn behavior on the shared Brunch conversation #9564
• FE-1575: Resume one Brunch workpiece and Petrinaut document across tabs #9537
• FE-1574: Let Voice speak through canonical Brunch conversations #9528 : 1 other dependent PR (#9531 )
• FE-1563: Establish Brunch elicitation skill boundaries #9468
• FE-1525: Establish the runbook-to-workpiece control and expose the construction gap #9405
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[semgrep-code-hashintel]

Semgrep found 3 prototype-pollution-loop findings:

• libs/@hashintel/brunch-agent/packages/plugin-sdcpn/src/root-state.ts
  • L132 - Triage
• libs/@hashintel/brunch-agent/docs/evidence/implementations/fe-1573-step-a/typed-state-checkpoint/audit.mjs
  • L107 - Triage
  • L115 - Triage

Possibility of prototype polluting function detected. By adding or modifying attributes of an object prototype, it is possible to create attributes that exist on every object, or replace critical attributes with malicious ones. This can be problematic if the software depends on existence or non-existence of certain attributes, or uses pre-defined attributes of object prototype (such as hasOwnProperty, toString or valueOf). Possible mitigations might be: freezing the object prototype, using an object without prototypes (via Object.create(null) ), blocking modifications of attributes that resolve to object prototype, using Map instead of object.

Semgrep found 2 unencrypted-socket findings:

• libs/@hashintel/brunch-agent/docs/evidence/implementations/fe-1573-step-a/native-local-delivery/NetworkGuard.java
  • L10 - Triage
  • L19 - Triage

Detected use of a Java socket that is not encrypted. As a result, the traffic could be read by an attacker intercepting the network traffic. Use an SSLSocket created by 'SSLSocketFactory' or 'SSLServerSocketFactory' instead.

[cursor]

PR Summary

High Risk
Changes span AI tool validation, conversation durability, and browser-verified construction identity with client-tool sidecars—errors could mis-attribute edits, drop state on recovery, or break provider tool schemas.

Overview
Mission 7a wires Brunch’s Flue ChatAgent to revisioned workpieces, browser-bound Petrinaut construction, and brunch_why explanations over verified transition records—not full editor parity or semantic model acceptance.

Petrinaut / website: Hosts can add an AI / Workpiece (or other) additional assistant tab that keeps chat, composer, Voice, and resize behavior mounted across switches. Construction mode gains an optional synchronous executeMutation hook so embedders can inspect or refuse canonical mutations while the panel still owns results and continuation. UI shows unapplied operations with reasons, groups tool calls as operations, and can follow canonical AI history after local turns settle (external/reloaded tools become display-only). @hashintel/petrinaut-core preserves place capacities (including zero/unbounded) when normalizing or reopening documents.

Runtime / provider stack: Patched @flue/runtime, pi-agent-core, and pi-ai carry full JSON Schema to Anthropic, per-tool validateArguments / prepareArguments, and Standard Schema tool inputs; usePersistentState commits with tool outcomes to close recovery gaps. Brunch registers buffered tool admission and optional Step A request accounting on the pinned Anthropic provider.

apps/brunch-agent: ChatAgent composes SDCPN with construction/browser context, verifies root-arc and identity on client-tool results, exposes workpiece read and why tools, and recovers revisions from canonical history. A maintained yarn brunch:persona launcher opens a real Chrome Petrinaut session, captures session.json, and runs an isolated Pi persona via brunch_turn (no mock construction hosting when attached). Adds optional local Postgres (BRUNCH_DB_KIND), dev configuration preflight, deployment-smoke tweaks, and broad integration tests (persona-browser, construction, native schema carriage).

Ops: Deploy workflow writes changed paths to a temp JSON file to avoid ARG_MAX on large merge diffs.

^{Reviewed by Cursor Bugbot for commit e4490ae. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Copilot]

🟡 Changes recommended

Result reconciliation incorrectly treats reordered JSON keys as conflicting, and duplicate Petrinaut changesets must be consolidated.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds Mission 7a’s revisioned workpieces, bounded Petrinaut construction operations, provenance-backed explanations, and tabbed assistant-panel integration.

Changes:

• Adds durable workpiece revisions, evidence links, mutation recording, and brunch_why.
• Integrates AI/Workpiece tabs while preserving chat and Voice state.
• Expands construction operations, tests, documentation, and runtime patches.

File summaries

File	Description
.changeset/*	Adds Petrinaut and core release notes.
.github/workflows/deploy.yml	Handles large changed-file lists safely.
.yarn/patches/*	Extends Pi/Flue schema validation and recovery behavior.
apps/brunch-agent/**	Implements agent orchestration, provenance, ownership, accounting, persona tooling, and integration tests.
apps/petrinaut-website/**	Connects Brunch transport, mutation recording, history, and the Workpiece pane.
libs/@hashintel/brunch-agent/**	Adds workpiece, transport, SDCPN construction, evidence, and supporting documentation.
libs/@hashintel/petrinaut/**	Adds assistant tabs, mutation execution boundaries, history following, and UI tests.
libs/@hashintel/petrinaut-core/**	Preserves place capacity and extends canonical mutation support.
Mission and evidence documents	Reframes Mission 7a and archives or removes superseded evidence.
Workspace configuration	Updates package wiring, tasks, and dependency metadata.

Review details

• Files reviewed: 107/560 changed files
• Comments generated: 2
• Review effort level: Balanced

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Stale Bugbot comment from a previous run.

[kostandinang]

Self-note:

After this rebases post #9619 merge: test (and possibly extend voice-browser-tools.integration.test.tsx) to verify playback-only cancellation, one completed mutation, one retained submission, stable Voice state across Workpiece tabs, and no spoken tool/workpiece payloads.

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit aaa135f. Configure here.}

[kostandinang]

Looks good, but may need to check these durability risks:

• Write ordering: persistence follows asynchronous tool completion rather than setter invocation. Parallel A→B updates could therefore be stored as B→A, restoring stale state after restart.

• Provenance loss: the browser document is mutated before the corresponding result metadata is durably admitted. If admission fails and the page reloads, the change remains but brunch_why can no longer explain it.

• Concurrent tabs: tabs share the persisted conversation and incarnation while holding independent document handles. Concurrent edits can fork state, with localStorage resolving them last-writer-wins.

There are also stale references to moved integration fixtures, which currently break website checks.

[lunelson]

@kostandinang Thanks — I checked all four points against the current implementation.

• Write ordering: confirmed as a generic Flue patch defect. Mission 7b only orders operations inside mutate_petrinet; it does not touch usePersistentState. The parent now sequences buffered writes at setter invocation and suppresses an older same-name write when its tool completes after a newer owner. flue-persistent-state-order.test.ts drives A-set/block → B-set/complete → A-complete, reduces the emitted writes, and reopens the buffer; restored state remains B. Brunch workpieces were already protected separately by their revision fence.
• Stale integration references: confirmed and fixed. The website admission test now imports the relocated integration helper/probe, and test:native-schema points to its moved integration path. Full website integration, Brunch unit/integration, native schema carriage, typecheck and lint/format checks pass locally.
• Mutation before result admission / concurrent tabs: both schedules are real cross-store limitations, but current reconciliation fails closed as unknown/external and never replays or invents provenance. An actual fix requires a durable cross-store protocol and concurrency arbitration, not a local lock. I added explicit single-tab/best-effort bounds to the PR Known issues rather than implying durability we do not provide.

Current parent head: e4490aef17.

[TimDiekmann]

Two clarification questions, but none-blocking, they can easily be addressed later.

[github-actions]

Benchmark results

@rust/hash-graph-benches – Integrations

policy_resolution_large

Function	Value	Mean	Flame graphs
resolve_policies_for_actor	user: empty, selectivity: high, policies: 2002	$$27.3 \mathrm{ms} \pm 197 \mathrm{μs}\left({\color{gray}-2.235 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: empty, selectivity: low, policies: 1	$$3.03 \mathrm{ms} \pm 23.5 \mathrm{μs}\left({\color{lightgreen}-5.287 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: empty, selectivity: medium, policies: 1002	$$13.8 \mathrm{ms} \pm 151 \mathrm{μs}\left({\color{gray}3.37 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: seeded, selectivity: high, policies: 3314	$$38.4 \mathrm{ms} \pm 280 \mathrm{μs}\left({\color{lightgreen}-13.965 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: seeded, selectivity: low, policies: 1	$$13.1 \mathrm{ms} \pm 198 \mathrm{μs}\left({\color{red}6.37 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: seeded, selectivity: medium, policies: 1527	$$22.1 \mathrm{ms} \pm 178 \mathrm{μs}\left({\color{lightgreen}-5.449 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: high, policies: 2078	$$29.7 \mathrm{ms} \pm 252 \mathrm{μs}\left({\color{red}8.26 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: low, policies: 1	$$3.20 \mathrm{ms} \pm 18.4 \mathrm{μs}\left({\color{lightgreen}-21.860 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: medium, policies: 1033	$$13.6 \mathrm{ms} \pm 114 \mathrm{μs}\left({\color{gray}0.714 \mathrm{\%}}\right) $$	Flame Graph

policy_resolution_medium

Function	Value	Mean	Flame graphs
resolve_policies_for_actor	user: empty, selectivity: high, policies: 102	$$3.46 \mathrm{ms} \pm 26.9 \mathrm{μs}\left({\color{gray}1.61 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: empty, selectivity: low, policies: 1	$$2.75 \mathrm{ms} \pm 28.1 \mathrm{μs}\left({\color{lightgreen}-10.846 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: empty, selectivity: medium, policies: 52	$$2.93 \mathrm{ms} \pm 25.3 \mathrm{μs}\left({\color{gray}-0.087 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: seeded, selectivity: high, policies: 269	$$4.60 \mathrm{ms} \pm 47.3 \mathrm{μs}\left({\color{lightgreen}-6.819 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: seeded, selectivity: low, policies: 1	$$3.24 \mathrm{ms} \pm 29.1 \mathrm{μs}\left({\color{gray}0.402 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: seeded, selectivity: medium, policies: 108	$$3.65 \mathrm{ms} \pm 32.2 \mathrm{μs}\left({\color{lightgreen}-13.202 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: high, policies: 133	$$3.95 \mathrm{ms} \pm 29.4 \mathrm{μs}\left({\color{gray}-1.725 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: low, policies: 1	$$3.21 \mathrm{ms} \pm 36.5 \mathrm{μs}\left({\color{red}6.10 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: medium, policies: 63	$$3.64 \mathrm{ms} \pm 28.3 \mathrm{μs}\left({\color{gray}3.15 \mathrm{\%}}\right) $$	Flame Graph

policy_resolution_none

Function	Value	Mean	Flame graphs
resolve_policies_for_actor	user: empty, selectivity: high, policies: 2	$$2.50 \mathrm{ms} \pm 19.2 \mathrm{μs}\left({\color{gray}4.26 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: empty, selectivity: low, policies: 1	$$2.35 \mathrm{ms} \pm 12.5 \mathrm{μs}\left({\color{gray}-2.587 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: empty, selectivity: medium, policies: 2	$$2.40 \mathrm{ms} \pm 15.4 \mathrm{μs}\left({\color{gray}-4.915 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: high, policies: 8	$$2.70 \mathrm{ms} \pm 20.9 \mathrm{μs}\left({\color{gray}0.040 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: low, policies: 1	$$2.59 \mathrm{ms} \pm 17.7 \mathrm{μs}\left({\color{gray}4.78 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: medium, policies: 3	$$2.73 \mathrm{ms} \pm 23.0 \mathrm{μs}\left({\color{lightgreen}-6.878 \mathrm{\%}}\right) $$	Flame Graph

policy_resolution_small

Function	Value	Mean	Flame graphs
resolve_policies_for_actor	user: empty, selectivity: high, policies: 52	$$2.77 \mathrm{ms} \pm 20.8 \mathrm{μs}\left({\color{red}5.07 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: empty, selectivity: low, policies: 1	$$2.48 \mathrm{ms} \pm 18.9 \mathrm{μs}\left({\color{gray}4.77 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: empty, selectivity: medium, policies: 26	$$2.65 \mathrm{ms} \pm 18.5 \mathrm{μs}\left({\color{red}6.06 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: seeded, selectivity: high, policies: 94	$$3.09 \mathrm{ms} \pm 24.8 \mathrm{μs}\left({\color{gray}1.66 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: seeded, selectivity: low, policies: 1	$$2.65 \mathrm{ms} \pm 16.5 \mathrm{μs}\left({\color{gray}-3.373 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: seeded, selectivity: medium, policies: 27	$$3.01 \mathrm{ms} \pm 27.8 \mathrm{μs}\left({\color{red}5.80 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: high, policies: 66	$$3.06 \mathrm{ms} \pm 24.8 \mathrm{μs}\left({\color{gray}-3.136 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: low, policies: 1	$$2.62 \mathrm{ms} \pm 14.4 \mathrm{μs}\left({\color{gray}0.122 \mathrm{\%}}\right) $$	Flame Graph
resolve_policies_for_actor	user: system, selectivity: medium, policies: 29	$$2.90 \mathrm{ms} \pm 22.4 \mathrm{μs}\left({\color{gray}0.262 \mathrm{\%}}\right) $$	Flame Graph

read_scaling_complete

Function	Value	Mean	Flame graphs
entity_by_id;one_depth	1 entities	$$31.8 \mathrm{ms} \pm 309 \mathrm{μs}\left({\color{red}5.52 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;one_depth	10 entities	$$71.5 \mathrm{ms} \pm 370 \mathrm{μs}\left({\color{red}6.64 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;one_depth	25 entities	$$38.3 \mathrm{ms} \pm 306 \mathrm{μs}\left({\color{red}5.79 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;one_depth	5 entities	$$39.2 \mathrm{ms} \pm 239 \mathrm{μs}\left({\color{gray}3.43 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;one_depth	50 entities	$$38.4 \mathrm{ms} \pm 208 \mathrm{μs}\left({\color{lightgreen}-13.336 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;two_depth	1 entities	$$31.1 \mathrm{ms} \pm 172 \mathrm{μs}\left({\color{lightgreen}-6.119 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;two_depth	10 entities	$$392 \mathrm{ms} \pm 1.21 \mathrm{ms}\left({\color{gray}-0.364 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;two_depth	25 entities	$$82.5 \mathrm{ms} \pm 532 \mathrm{μs}\left({\color{gray}0.794 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;two_depth	5 entities	$$85.5 \mathrm{ms} \pm 545 \mathrm{μs}\left({\color{red}5.81 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;two_depth	50 entities	$$248 \mathrm{ms} \pm 1.09 \mathrm{ms}\left({\color{gray}0.333 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;zero_depth	1 entities	$$9.96 \mathrm{ms} \pm 109 \mathrm{μs}\left({\color{gray}0.494 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;zero_depth	10 entities	$$11.2 \mathrm{ms} \pm 81.3 \mathrm{μs}\left({\color{red}10.2 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;zero_depth	25 entities	$$10.1 \mathrm{ms} \pm 86.6 \mathrm{μs}\left({\color{lightgreen}-10.542 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;zero_depth	5 entities	$$10.2 \mathrm{ms} \pm 73.7 \mathrm{μs}\left({\color{gray}3.27 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id;zero_depth	50 entities	$$10.3 \mathrm{ms} \pm 92.8 \mathrm{μs}\left({\color{lightgreen}-10.643 \mathrm{\%}}\right) $$	Flame Graph

read_scaling_linkless

Function	Value	Mean	Flame graphs
entity_by_id	1 entities	$$9.24 \mathrm{ms} \pm 67.5 \mathrm{μs}\left({\color{gray}-3.820 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	10 entities	$$9.92 \mathrm{ms} \pm 101 \mathrm{μs}\left({\color{red}7.85 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	100 entities	$$9.21 \mathrm{ms} \pm 48.1 \mathrm{μs}\left({\color{lightgreen}-12.283 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	1000 entities	$$10.5 \mathrm{ms} \pm 96.9 \mathrm{μs}\left({\color{gray}-1.923 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	10000 entities	$$10.1 \mathrm{ms} \pm 81.3 \mathrm{μs}\left({\color{lightgreen}-7.599 \mathrm{\%}}\right) $$	Flame Graph

representative_read_entity

Function	Value	Mean	Flame graphs
entity_by_id	entity type ID: https://blockprotocol.org/@alice/types/entity-type/block/v/1	$$11.0 \mathrm{ms} \pm 130 \mathrm{μs}\left({\color{red}11.4 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	entity type ID: https://blockprotocol.org/@alice/types/entity-type/book/v/1	$$10.2 \mathrm{ms} \pm 74.5 \mathrm{μs}\left({\color{lightgreen}-6.984 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	entity type ID: https://blockprotocol.org/@alice/types/entity-type/building/v/1	$$11.3 \mathrm{ms} \pm 86.5 \mathrm{μs}\left({\color{red}17.8 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	entity type ID: https://blockprotocol.org/@alice/types/entity-type/organization/v/1	$$11.4 \mathrm{ms} \pm 79.9 \mathrm{μs}\left({\color{gray}2.15 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	entity type ID: https://blockprotocol.org/@alice/types/entity-type/page/v/2	$$12.1 \mathrm{ms} \pm 113 \mathrm{μs}\left({\color{red}8.87 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	entity type ID: https://blockprotocol.org/@alice/types/entity-type/person/v/1	$$10.8 \mathrm{ms} \pm 91.5 \mathrm{μs}\left({\color{red}6.65 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	entity type ID: https://blockprotocol.org/@alice/types/entity-type/playlist/v/1	$$10.0 \mathrm{ms} \pm 71.9 \mathrm{μs}\left({\color{gray}-4.037 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	entity type ID: https://blockprotocol.org/@alice/types/entity-type/song/v/1	$$10.8 \mathrm{ms} \pm 69.6 \mathrm{μs}\left({\color{red}5.81 \mathrm{\%}}\right) $$	Flame Graph
entity_by_id	entity type ID: https://blockprotocol.org/@alice/types/entity-type/uk-address/v/1	$$11.8 \mathrm{ms} \pm 162 \mathrm{μs}\left({\color{gray}4.73 \mathrm{\%}}\right) $$	Flame Graph

representative_read_entity_type

Function	Value	Mean	Flame graphs
get_entity_type_by_id	Account ID: bf5a9ef5-dc3b-43cf-a291-6210c0321eba	$$7.70 \mathrm{ms} \pm 46.2 \mathrm{μs}\left({\color{gray}-0.142 \mathrm{\%}}\right) $$	Flame Graph

representative_read_multiple_entities

Function	Value	Mean	Flame graphs
entity_by_property	traversal_paths=0	0	$$65.0 \mathrm{ms} \pm 705 \mathrm{μs}\left({\color{red}18.2 \mathrm{\%}}\right) $$
entity_by_property	traversal_paths=255	1,resolve_depths=inherit:1;values:255;properties:255;links:127;link_dests:126;type:true	$$108 \mathrm{ms} \pm 768 \mathrm{μs}\left({\color{red}5.65 \mathrm{\%}}\right) $$
entity_by_property	traversal_paths=2	1,resolve_depths=inherit:0;values:0;properties:0;links:0;link_dests:0;type:false	$$73.7 \mathrm{ms} \pm 717 \mathrm{μs}\left({\color{red}12.4 \mathrm{\%}}\right) $$
entity_by_property	traversal_paths=2	1,resolve_depths=inherit:0;values:0;properties:0;links:1;link_dests:0;type:true	$$74.8 \mathrm{ms} \pm 702 \mathrm{μs}\left({\color{gray}1.46 \mathrm{\%}}\right) $$
entity_by_property	traversal_paths=2	1,resolve_depths=inherit:0;values:0;properties:2;links:1;link_dests:0;type:true	$$84.1 \mathrm{ms} \pm 794 \mathrm{μs}\left({\color{gray}0.787 \mathrm{\%}}\right) $$
entity_by_property	traversal_paths=2	1,resolve_depths=inherit:0;values:2;properties:2;links:1;link_dests:0;type:true	$$87.9 \mathrm{ms} \pm 615 \mathrm{μs}\left({\color{lightgreen}-6.891 \mathrm{\%}}\right) $$
link_by_source_by_property	traversal_paths=0	0	$$45.3 \mathrm{ms} \pm 327 \mathrm{μs}\left({\color{gray}0.604 \mathrm{\%}}\right) $$
link_by_source_by_property	traversal_paths=255	1,resolve_depths=inherit:1;values:255;properties:255;links:127;link_dests:126;type:true	$$69.7 \mathrm{ms} \pm 389 \mathrm{μs}\left({\color{gray}0.664 \mathrm{\%}}\right) $$
link_by_source_by_property	traversal_paths=2	1,resolve_depths=inherit:0;values:0;properties:0;links:0;link_dests:0;type:false	$$50.1 \mathrm{ms} \pm 371 \mathrm{μs}\left({\color{gray}-0.584 \mathrm{\%}}\right) $$
link_by_source_by_property	traversal_paths=2	1,resolve_depths=inherit:0;values:0;properties:0;links:1;link_dests:0;type:true	$$57.6 \mathrm{ms} \pm 342 \mathrm{μs}\left({\color{gray}-1.246 \mathrm{\%}}\right) $$
link_by_source_by_property	traversal_paths=2	1,resolve_depths=inherit:0;values:0;properties:2;links:1;link_dests:0;type:true	$$62.7 \mathrm{ms} \pm 479 \mathrm{μs}\left({\color{gray}3.39 \mathrm{\%}}\right) $$
link_by_source_by_property	traversal_paths=2	1,resolve_depths=inherit:0;values:2;properties:2;links:1;link_dests:0;type:true	$$67.9 \mathrm{ms} \pm 507 \mathrm{μs}\left({\color{red}14.2 \mathrm{\%}}\right) $$

scenarios

Function	Value	Mean	Flame graphs
full_test	query-limited	$$105 \mathrm{ms} \pm 581 \mathrm{μs}\left({\color{gray}-1.494 \mathrm{\%}}\right) $$	Flame Graph
full_test	query-unlimited	$$115 \mathrm{ms} \pm 574 \mathrm{μs}\left({\color{gray}-3.091 \mathrm{\%}}\right) $$	Flame Graph
linked_queries	query-limited	$$21.8 \mathrm{ms} \pm 150 \mathrm{μs}\left({\color{gray}-0.249 \mathrm{\%}}\right) $$	Flame Graph
linked_queries	query-unlimited	$$479 \mathrm{ms} \pm 1.23 \mathrm{ms}\left({\color{gray}2.40 \mathrm{\%}}\right) $$	Flame Graph