Command extension: add Xencode CLI safety coverage

[sreevarshan-xenoz]

Capability boundary

I’m proposing a community command-safety extension for Xencode, a Rust CLI/TUI AI coding assistant.

Proposed stable ID:

command.xencode

The goal is to let HOL Guard review Xencode’s state-changing CLI operations when they are invoked by an agent or external command layer.

Initial command coverage

Xencode currently exposes:

• xencode worktree list
• xencode worktree add <path> [branch]
• xencode worktree remove <path>
• xencode plugin list
• xencode plugin install <path>
• xencode plugin remove <name>

I propose review coverage for the state-changing operations:

• worktree add
• worktree remove
• plugin install
• plugin remove

Read-only worktree list and plugin list would remain outside the destructive rules.

One important correction from the initial discussion: the current Xencode CLI does not expose a worktree remove --force flag. Its current worktree remove path delegates to Git’s normal dirty-worktree refusal. I therefore do not want the extension to claim a nonexistent force flag. If Xencode later adds a force/removal override, that should get a separate rule and fixture.

Proposed safety model

State-changing operations should default to review rather than silently allowing an agent to mutate local state.

For worktree removal in particular, the extension should preserve the distinction between:

• normal removal
• Git refusing removal because the worktree is dirty
• any future explicit force/destructive variant

For plugin installation/removal, the extension should review the mutation because it changes the local agent/plugin environment.

Fixtures

I plan to add portable cases covering:

• inactive extension
• enabled extension
• disabled permission
• unrelated command
• compound commands
• quoted paths / paths with spaces
• malformed or unsupported input
• worktree list and plugin list as non-matching read-only cases
• state-changing worktree/plugin operations reaching review

Implementation

I’ll submit:

1. contributions/command-sources/command.xencode.json
2. tests/fixtures/command-source-xencode.v1.json
3. the external trust-map entry

I’ll use the existing native matcher operations and follow the documented preparation/handoff workflow rather than adding a Python detector or generated artifacts by hand.

This proposal is based on the current Xencode CLI source and the existing command.git extension as the closest native analogue.

Happy to adjust the capability boundary or stable IDs before implementation.

[sreevarshan-xenoz]

I’ve prepared a draft implementation in #3058 based on the current Xencode CLI and the documented extension workflow. I kept the scope to worktree add/remove and plugin install/remove, left read-only list commands unmatched, and did not invent a worktree remove --force flag that Xencode does not currently expose. The PR is draft so the capability boundary and matcher details can be adjusted with maintainer feedback before it is marked ready.