Suggestions and self-audit

Team knowledge rots. Paths get renamed, milestones ship, dependency pins drift, a rule stops matching anything. Pathrule's answer is a refresh task: a flag on a memory or rule that looks stale, with a plain-language reason, which your own assistant repairs under your control.

The important property: a refresh task only ever suggests. Pathrule never edits or deletes your memories, rules or skills on its own.

What the self-audit checks

The audit happens where the drift is noticed: in the work itself. An assistant reading your code is the first to see that a memory describes a file that moved, or that a rule contradicts what the code now does. When that happens in its normal work, it flags the entry with the pathrule_request_refresh MCP tool, naming the memory or rule and why it looks wrong. Typical reasons:

• Drift. The entry describes a state that no longer matches the code, for example a file it cites has moved or no longer exists.
• Contradicts the code. The entry says one thing and the code clearly does another.
• Duplicate. Another memory or rule already covers the same ground better.
• Too narrow. The entry only applies to a case that is long gone.
• Unclear. It is not possible to tell what the entry asks for.

Flagging is idempotent: flagging the same entry twice returns the same task, so repeated sessions do not pile up duplicates. Assistants are told to flag only drift they actually noticed, not to go looking for it.

Nothing about your source code is stored in a refresh task. It names the entry and carries the reason; the assistant that later repairs it reads the current code with its own file tools.

Reviewing suggestions

A refresh task is a prompt for a decision, not an action. On a Pathrule Cloud workspace you can work with them from the terminal:

pathrule refresh list
pathrule refresh claim <refresh-id>
pathrule refresh resolve <refresh-id> --status applied

list shows the pending tasks for the current workspace, claim returns the full brief for one task and marks it in progress, and resolve closes it as applied or rejected. An assistant does the same through MCP with pathrule_list_pending_refreshes, pathrule_get_refresh_brief and pathrule_resolve_refresh.

For each task you can let your assistant apply the fix (see below), edit the entry yourself, or reject the task when the entry is still right.

Repair through your assistant

Pathrule does not patch your knowledge automatically. Ask your assistant to work through the pending refresh tasks. It then:

1. Lists the pending tasks and claims one, which marks it in progress so another session does not take it at the same time.
2. Inspects the current code and the flagged entry with its own file-access tools.
3. Drafts the update and writes it back through the Pathrule write tools. Passing the task id with the update closes the task as applied.
4. Otherwise marks the task applied or rejected explicitly.

You stay in control at both ends: the fix runs through your own assistant, and the change is an ordinary versioned edit you can review. See the MCP tools reference for the refresh tools the assistant uses.

Nothing is one-way

A repair is a normal versioned edit. Every change keeps its history, and on a Pathrule Cloud workspace a deleted entry remains in the workspace archive until permanently deleted, where an owner or admin can restore it from the web console settings. In VS Code, a delete offers Undo straight away. If a fix turns out to be wrong, you can change it back like any other edit.