TraceRookOverview and menu bar
Overview summarizes the selected data source, recent findings, pending reviews, and integration coverage. The current demo uses seeded fixtures. Actual coverage remains visibly separate from sample findings.
The native menu bar is the quick entry point into the dashboard and pending approvals. The MVP1 design requires its state to follow real service and integration health, rather than showing a permanently green shield. Closing a dashboard window and stopping background protection are distinct operations once the background service is implemented.
Sessions and timelines
A session ties activity to a provider, the host’s session identifier, and a subagent identifier when one exists. Its task anchor records a concise, redacted summary of the user’s intent. If the task is unavailable, the UI must say Task unknown.
A timeline should let you connect a proposal to local evidence, review, and observed execution. Sessions sharing the same repository are not automatically one session. A post-tool event describes an action that already happened.
Read an incident
Each finding should answer four questions: what was attempted, what evidence raised concern, how the action related to the task, and what TraceRook did. Rule IDs and contextual rationale explain the decision; a score is a routing aid, not proof of malicious intent.
Keep execution certainty separate from the policy outcome. Allowed by TraceRook does not mean the host executed the call. An asynchronous drift finding cannot retroactively prevent earlier work.
Demo incidents use sample evidence. They do not describe current activity on your Mac.
Approvals and native review
The review panel presents one pending action, its agent, task relevance, evidence, and deadline. Allow once and Block are bound to that exact pending invocation. A stale notification must open an expired state rather than provide permission for a new attempt.
Read the approval state machine for the intended live guarantees.
Integrations and settings
Integrations shows installation, trust, version compatibility, and verification as separate facts. Settings includes provider selection, appearance, notification authorization, privacy previews, and explicitly simulated Cloud Account, Usage, and Plans.
Enabling notification permission is an explicit user action. Notifications may be suppressed by Focus or system settings; the approvals queue remains necessary. The current build does not accept an API key or install integrations.