feat(templates,agent): installable template recipes + board-as-memory (#60, #61)#75
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 2 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (41)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
evaOS review status: stale headPR: #75 - feat(templates,agent): installable template recipes + board-as-memory (#60, #61) evaOS review stopped because this queued head is no longer the live PR head. Automation note: agents should wait for this comment to reach PR URL: #75 |
Adversarial verify REFUTED the snapshot bound: memory:"board" embedded every note's FULL text per turn (a 24-widget/64KB-note tab shipped uncapped — prompt blowout + cost, with only a post-hoc usage ceiling). Now: 600-char per-note cap + 4KB total budget, each cut carrying an explicit '[truncated — read the board widget for the full text]' marker (the agent fetches the rest via dashboard_workspace_get when it matters; never a silent cut). Also moved the treat-as-DATA framing INSIDE the memory block header — it sat distal to the 'ground truth' language, softening the injection posture. Delta-sensitive test: 20K note → marker present, total bounded, framing adjacent.
Adversarial verify — verdict
Merging when CI re-greens. |
evaOS review status: closed or merged before reviewPR: #75 - feat(templates,agent): installable template recipes + board-as-memory (#60, #61) evaOS review stopped because the PR closed or merged before this queued head could be reviewed. Automation note: agents should wait for this comment to reach PR URL: #75 Details: state=closed |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1002e084fa
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const system = | ||
| buildSystemPrompt(tools) + (options.systemExtras ? `\n\n${options.systemExtras}` : ""); | ||
| buildSystemPrompt(tools, memoryOn ? { memory: "board" } : {}) + | ||
| (memorySnapshot ? `\n\n${memorySnapshot}` : "") + |
There was a problem hiding this comment.
When memory: "board" is enabled, note and journal text from ordinary board widgets is concatenated directly into the provider's system prompt. If a memory note contains untrusted or agent-written text such as instructions to ignore safety rules or call mutating tools, it is delivered at system priority rather than as framed board data, contradicting the repo's “board content is data, not instructions” invariant. Please wrap/label this snapshot as untrusted data outside the system instruction channel or otherwise delimit and cap it so it cannot become executable prompt policy.
Useful? React with 👍 / 👎.
| caps[connector] = { | ||
| status: "requested", | ||
| methods: grant.methods ?? [], | ||
| streams: grant.streams ?? [], | ||
| ...(tools.length > 0 ? { tools } : {}), | ||
| ...(description !== undefined ? { description } : {}), |
There was a problem hiding this comment.
Recipe-installed tool grants are created with tools but no toolsHash. The dashboard.capability.approve approve-all path preserves existing.toolsHash when no tools subset is passed, so API/CLI callers that approve the recipe grant without an explicit subset store a granted tool list with an undefined hash; the first dashboard.connector.read then compares the live hash to undefined and re-pends the grant. This only works when the UI sends the checked tool subset or a refresh has already populated the hash, so recipe grants should either be installed/approved with a hash or the approve-all path should recompute one when it is missing.
Useful? React with 👍 / 👎.
| "grantsManifest": { | ||
| "officecli": { |
There was a problem hiding this comment.
When this gallery recipe is installed it replaces the workspace with a doc that requests officecli grants but contains no builtin:approvals widget. I checked the UI wiring: capability approvals are only exposed through the approvals builtin (buildBuiltinContext passes approveCapability into buildApprovalsSource for that widget), while chat inline approvals handle only custom widgets; so after installing this recipe from the gallery, browser users have no in-board way to approve the requested grant and the live table/action stay pending. Add an approvals widget (same for saas-metrics) or provide another visible approval surface.
Useful? React with 👍 / 👎.
| const [entries, recipes] = await Promise.all([ | ||
| fetchGalleryIndex(url), | ||
| fetchGalleryRecipes(url), |
There was a problem hiding this comment.
Because Browse now Promise.alls fetchGalleryIndex with fetchGalleryRecipes, a registry that publishes only recipes (no widgets key) fails before Templates can render: parseGalleryIndex throws for { recipes: [...] }, even though the dialog has a separate Templates tab. This blocks template-only registries; load each half independently or treat a missing widgets array as empty.
Useful? React with 👍 / 👎.
| const text = | ||
| isRecord(widget.props) && typeof widget.props.text === "string" ? widget.props.text : ""; | ||
| sections.push(`### ${heading}\n${text.trim() || "(empty)"}`); |
There was a problem hiding this comment.
In the live UI, builtin:notes edits are stored via the separate dashboard.widget.state.* path, not back into widget.props.text; the workspace doc only carries author seed data. Priming memory from props.text therefore misses any human edits made in the notes widgets (and can even show stale seed text), breaking the memory: "board" guarantee that the next turn sees the human's latest memory as ground truth. The snapshot needs to read the bound widget state or use a memory widget whose content lives in the workspace doc.
Useful? React with 👍 / 👎.
| const methods = optionalStringArray(record, "methods", path); | ||
| const streams = optionalStringArray(record, "streams", path); |
There was a problem hiding this comment.
methods and streams from a recipe manifest are copied into capabilitiesRegistry at install time, where the workspace validator only accepts allowlisted RPC methods and stream channels, but validateRecipe currently accepts any non-empty string array. A remote recipe can pass parseRecipeBundle and be shown in the Templates preview, then always fail on dashboard.workspace.replace during install because those grant fields are invalid. Validate these arrays against the same allowlists or validate the constructed install doc before accepting the recipe.
Useful? React with 👍 / 👎.
1 participant
Closes #60
Closes #61