Hi — I found Lime while looking at desktop agent projects where file edits, terminal commands, MCP/tool calls, multi-agent work, generated artifacts, or exported task results may need evidence that survives outside the original runtime.
I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected claims, actions, artifacts, or handoffs that cross trust boundaries:
https://github.com/cullenmeyers/BoundaryAttest
The idea is not to replace Lime’s local Thread/Turn/Item state, workspace history, permissions, tool lifecycle, Skills, MCP integrations, command output, diffs, artifacts, or normal local logs. The receipt only proves a narrow claim:
a specific signer signed a specific claim, and the signed claim has not been altered.
Lime seemed relevant because it can understand workspace context, edit files, run terminal commands, call tools/MCP/Skills, preserve task state, coordinate multiple agents, and produce reviewable plans, diffs, test results, reports, and other artifacts.
A receipt could potentially bind selected boundary events like:
- Lime Thread / task ID;
- workspace or repository reference;
- plan hash;
- permission / approval decision reference;
- file-edit or patch digest;
- terminal command digest and output hash;
- MCP/tool/Skill call reference;
- multi-agent subtask result hash;
- generated artifact hash;
- test/build result hash;
- exported task summary hash;
- status, such as planned, approved, edited, command-run, tool-called, tested, completed, failed, exported, or handed off;
- timestamp/event ID;
- signer/public key ID.
The strongest use case would be when a Lime task summary, code diff, test result, command output, tool result, generated artifact, multi-agent result, or exported Thread is handed to another developer, reviewer, teammate, CI/debugging workflow, downstream agent, or future audit trail.
BoundaryAttest would not prove the code is correct, the command was safe, the plan was good, the tool result was truthful, the approval was wise, or the runtime was uncompromised. It would only prove that a specific claim about a selected Lime artifact/action/handoff was signed and has not been altered after export.
Does this kind of portable signed receipt fit any workflow you imagine for Lime, especially around task exports, file changes, command results, MCP/tool calls, Skills, multi-agent results, generated artifacts, or debugging/review handoffs? Or are Lime’s current local workspace state, permissions, artifacts, diffs, command output, and task history enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn where signed receipts are actually useful around desktop agent workspaces.
Hi — I found Lime while looking at desktop agent projects where file edits, terminal commands, MCP/tool calls, multi-agent work, generated artifacts, or exported task results may need evidence that survives outside the original runtime.
I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected claims, actions, artifacts, or handoffs that cross trust boundaries:
https://github.com/cullenmeyers/BoundaryAttest
The idea is not to replace Lime’s local Thread/Turn/Item state, workspace history, permissions, tool lifecycle, Skills, MCP integrations, command output, diffs, artifacts, or normal local logs. The receipt only proves a narrow claim:
Lime seemed relevant because it can understand workspace context, edit files, run terminal commands, call tools/MCP/Skills, preserve task state, coordinate multiple agents, and produce reviewable plans, diffs, test results, reports, and other artifacts.
A receipt could potentially bind selected boundary events like:
The strongest use case would be when a Lime task summary, code diff, test result, command output, tool result, generated artifact, multi-agent result, or exported Thread is handed to another developer, reviewer, teammate, CI/debugging workflow, downstream agent, or future audit trail.
BoundaryAttest would not prove the code is correct, the command was safe, the plan was good, the tool result was truthful, the approval was wise, or the runtime was uncompromised. It would only prove that a specific claim about a selected Lime artifact/action/handoff was signed and has not been altered after export.
Does this kind of portable signed receipt fit any workflow you imagine for Lime, especially around task exports, file changes, command results, MCP/tool calls, Skills, multi-agent results, generated artifacts, or debugging/review handoffs? Or are Lime’s current local workspace state, permissions, artifacts, diffs, command output, and task history enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn where signed receipts are actually useful around desktop agent workspaces.