Logs

The Logs panel holds the project's decisions, the history of its spec, and the queue of file changes waiting for review. You use it to record decisions and triage drift. Agents read the same data through MCP.

Where to find it

Open Logs from the sidebar (item 5) or press Ctrl+5. The panel has 4 tabs:

When the Drift Log has pending items that need attention, a count appears next to Logs in the sidebar. Clicking the count opens the Drift Log tab directly. The count shows "99+" above 99, and a collapsed sidebar shows a dot instead.

Decisions

A decision is a recorded choice about the project, with the reasoning behind it. Each decision record holds:

• Decision: what was decided.
• Rationale: why.
• Alternatives considered: what else was weighed (optional).
• Made by: a person or an agent, shown as a badge.
• Forbids: an optional list of dependencies this decision rules out.

The filter box above the list matches text in the decision, the rationale, and the agent name.

Add a decision

1. Open Logs, then Decisions.
2. Click Add Decision. The Log Decision sheet opens.
3. Fill in Decision and Rationale. Alternatives Considered is optional.
4. Made By defaults to user. Agent Name is optional.
5. Click Log Decision.

Vibeless does not save a decision with an empty Decision field.

Edit forbids

The decision text has no edit control in this tab. The forbids list does.

1. On the decision card, click Forbids (N), where N is the current count.
2. The Forbidden Dependencies editor opens under the card.
3. Type a dependency name (for example openssl) and click the add button.
4. To remove one, click the trash icon beside it.

Each add or remove saves at once.

What forbids do

Forbids make a decision checkable. The decision detector in the drift check looks for each forbidden name in the project's dependency manifests and reports every match as a finding. A decision with no forbids is skipped as "not machine-enforceable", and the agent has to apply it by judgment.

Decisions and agents

A connected agent works with decisions through 3 MCP tools:

• vibeless_log_decision records a decision with its rationale and alternatives, and optionally a ticket. The record is marked as made by an agent. The tool also returns a list of earlier decisions that share keywords with the new one, so the agent can check for overlap.
• vibeless_list_decisions returns the decision log, newest first. By default it returns short summaries (20 per page, at most 100), including whether each decision has forbids. With full: true it returns complete records, forbids included.
• vibeless_check_constraint returns up to 3 decisions most relevant to an action the agent proposes, ranked against each decision's text, rationale, and forbids.

The SessionStart digest (the project summary an agent receives when a session starts) has a Key Decisions (binding) section. Decisions with forbids come first, then the rest by recency.

Agents never write forbids: vibeless_log_decision has no forbids field, and no MCP tool edits an existing decision. On a shared project, only a maintainer can change forbids. When an editor tries, the app refuses the change and tells them to ask a maintainer.

Changelog

The Changelog is a per-person view of changes on a shared project. Its purpose line reads: "Every change synced to this project, in plain language, tagged to whoever made it."

The tab appears only when the project is shared with your organization and your organization is on a team plan. If you switch to a project without the tab while Changelog is open, the panel shows Version History instead.

Each row has 3 parts: who made the change, one sentence describing it (for example, which field changed), and how long ago it happened. The Changelog reads the same events as the Version History events list, described below.

The person column shows:

• You for your own changes.
• A member's name for their changes.
• The member's name followed by "(agent)" when an agent made the change on that member's behalf.

Rows are grouped under Today, Yesterday, and earlier dates. Changes that match no current member, such as changes made before the project was shared, appear in a separate Before sharing group.

Filter by member

Use the member filter at the top right. Choose All members, one member, or Unattributed (changes that match no current member, including pre-sharing changes). The same filter appears above the event list in Version History on shared team projects.

Version History

Version History is the record of spec changes for the current project. Vibeless records each change as an event with the old value, the new value, and who made it. Version history is kept in a local database on your computer. On a shared project, changes that arrive from teammates through sync are recorded there as events too.

What you see

• Snapshots: the 5 most recent snapshots, each with its trigger (manual, auto, or milestone), its label if it has one, and its time. Vibeless takes an auto snapshot after every 50 events, and a milestone snapshot when a phase is completed. Snapshots are not per project. Each one captures every project on this computer, and the 50 events are counted across all of them, so the list is the same whichever project is open.
• Events: events recorded against the project record itself, newest first, such as changes to its goal statement, tech stack, constraints, or non-goals. Each card shows the event type, what changed (for example project / goal_statement), who made it, and when. Changes to individual phases, tickets, decisions, and the architecture document are recorded under those items and do not appear in this list. An agent can read them with vibeless_get_version_history.

View a diff

Click the arrow on an event card to expand it. A side-by-side diff shows the old value against the new one. Events with neither value have no arrow.

The verified shield

On a shared project, some events show a small shield after the author. Hovering over it shows: "Signed by the author's device and verified on this computer." The shield appears only on changes that arrived from another device and passed signature verification. Changes made on your own computer never show it.

Rollback and agents

The Version History tab has no rollback control. It is a read-only record, and viewing events or diffs never changes the project.

vibeless_get_version_history is the agent's read-only view. The agent passes an entity type (such as project, phase, or task), the entity's ID, and an optional limit, and gets back each event's field, old and new values, and actor.

Drift Log

The Drift Log is the review queue for file changes in the project's repo. Drift is any change that departs from what the spec says the project should be. Nothing in this tab ever adds to the spec map that agents read: the map is maintained by people in the app, and reviewing a change does not create or edit a context node.

Where changes come from

Changes reach the queue from 2 watchers:

• A file watcher reports file changes as they happen.
• A git monitor checks for new commits every 5 seconds and reads their diffs.

Paths on the project's agent-artifact ignore list (agent plans, reports, worktrees under .worktrees/, and your own extras) stay out of the queue. You manage that list in the Agent-artifact paths card on the Dashboard's Agents tab.

Classifications

Vibeless scores each change against the spec and gives it one of 4 classifications:

Each entry shows the file path, classification, confidence percentage, and time. Expand it to see the diff summary and the reasons for the classification. The sidebar count is the number of pending entries classified drift or unknown.

Filter the queue

The classification buttons toggle which entries appear. The tab opens with Drift and Unknown selected, and at least one stays selected. The status buttons on the right show All, Pending, Accepted, Dismissed, or Flagged entries.

Review one entry

A pending entry has 3 buttons:

• Accept marks the change as reviewed. It does not add anything to the spec.
• Dismiss marks the change as not relevant.
• Flag marks the change for follow-up.

After you choose, the buttons are replaced by a badge showing the result.

Bulk actions

On the All and Pending views, when the current filter has entries, a bulk bar appears above the list. Every bulk action opens a confirmation dialog with a live count of the entries it will touch, and the confirm button stays disabled at 0. Bulk actions only touch pending entries. Accepted, dismissed, and flagged entries are never rewritten.

• Mark reviewed marks every pending entry in the selected classifications as reviewed. Nothing is added to the spec.
• Dismiss under path… dismisses every pending entry in the selected classifications whose path matches the glob in the box beside it (for example .worktrees/**). The glob must be repo-relative, with no leading / or ... This match is case-sensitive, and ** behaves like *, which already crosses folders. The ignore list matches without case sensitivity, so the same pattern can select different files in the two places.
• Purge ignored paths deletes every pending entry whose path falls under the project's ignore list. Use it after a new worktree appears or after you add an extra path. Purged entries cannot be recovered.

The staleness warning

The spec map only changes when a person edits it in the app, so it can fall behind the code. The project context, vibeless_declare_intent, and the SessionStart digest warn the agent that the map may be stale when any of these is true:

• Any change is still pending review.
• The map has not been edited in 7 or more days.
• The map is empty.

The warning tells the agent to treat suggested starting points as hints. It changes nothing in the map or the queue, and clears once the queue is triaged and the map has been edited within the last 7 days.

The drift check

The Drift Log shows the change-event queue, not drift check reports. The drift check is a separate, rule-based run that an agent starts with vibeless_run_drift_check. The app has no button for it. Each run re-checks the repo, so agents should not call it in a loop.

The app also runs the detectors that apply to a single file each time the file watcher sees a change in the open project. If one finds a problem, the app shows a "Drift detected" message. These findings do not appear in the Drift Log tab.

The check runs 5 detectors. A detector counts as applicable only when the spec gives it something to enforce:

The drift baseline is a record of the repo's files, captured when a project import is applied. The scope and phase checks only look at files changed since then. Agents cannot reset the baseline.

The tool's reply starts with a header line, then one skipped: line per detector that did not apply, then the full report. The header is one of:

• N finding(s) from M applicable detector(s). The check found problems.
• No drift found by N applicable detector(s). The applicable detectors ran and found nothing.
• No detectors applicable, followed by a list of what to add (phase path globs, constraint patterns, non-goal path globs, decision forbids, or pinned tech-stack versions). Nothing was enforceable, so an empty report proves nothing.

Each skipped: line names the detector and its reason, such as "no decision carries forbids" or "no drift baseline set". To make more detectors apply, a person adds the missing piece in the app (on a shared project, a maintainer). Agents never write constraints, non-goals, forbids, or path globs.

Rules and limits

• On a shared project, only a maintainer can change forbids. Agents never write forbids, constraints, non-goals, or path globs.
• Purge ignored paths cannot be undone. Mark reviewed and Dismiss keep the entries and change their status.
• Nothing in the Drift Log, single or bulk, adds to the spec map.

If something looks wrong

• The Changelog tab is missing. The project is not shared, or your organization is not on a team plan.
• A decision is ignored by the drift check. It has no forbids, or the repo has no manifest the check can read. Add forbids in the Decisions tab.
• The drift check says no detectors are applicable. The spec has nothing enforceable yet. Read the skipped: lines to see what each detector is missing.
• Dismiss under path matched fewer entries than expected. The match is case-sensitive. Check the capitalization of the path.
• Agent worktree changes fill the queue. Click Purge ignored paths. If the folder is not on the ignore list yet, add it in Agent-artifact paths first.
• Agents keep reporting a stale spec map. Triage the pending queue and update the map in the app.