Safety and refusals

HullForge refuses more often than most tools. Each refusal exists because the alternative is losing work quietly, which is worse than an error.

Every refusal names the cause, and every one has a specific override, so you have to state which risk you are accepting rather than passing a blanket force flag.

It will not edit what it cannot save

If an asset’s file cannot be written, HullForge declines to change it in the first place.

The usual cause is revision control being configured but not connected. Files are read-only, nothing can be checked out, and everything looks normal right up until the save fails. Without this check you make twenty edits and discover all twenty are gone.

The message distinguishes four different situations, because they need four different responses:

Situation	What to do
Read-only, no revision control	Clear the read-only attribute
Provider configured but not connected	Log in
Not checked out	Check it out, or enable auto-checkout
Checked out by someone else	Nothing local fixes this. The message names who holds it

This is provider-agnostic. Perforce, Git, Plastic and Subversion all behave the same way here.

Override: force: true, which edits in memory anyway and accepts that the work may be lost.

It will not delete something you still need

Deleting an asset that other assets reference breaks them, and the breakage does not surface until something loads the other asset. So deletion is refused, and the referencers are listed.

Override: delete_referenced: true. Show the list to whoever is asking before you use it.

One caveat worth knowing: the asset registry only records saved references. Something created this session and not yet written to disk can reference your asset and be invisible to that list. HullForge handles this case too, but a clean referencer list is not proof of safety.

It will not discard unsaved work

Opening a level throws away unsaved changes with no prompt. HullForge refuses while anything is unsaved, and names the packages that would be lost.

Override: discard_unsaved: true.

It has no exec tool

There is deliberately no arbitrary code execution capability. Every operation is a specific, typed tool with a schema, so what HullForge can do is knowable by reading its tool list.

The cost of this decision is real: anything not implemented is simply unreachable, and no clever prompt gets around it. That is the intended trade-off.

Destructive operations are labelled

Tools that change your project are annotated as writes. Five that can destroy work carry a stronger annotation: the three delete tools, rename (which breaks references to the old path), and open-level (which discards unsaved changes).

Creating an asset is a write, not a hazard. Marking every mutation destructive would make the flag meaningless, and a reader who learns to ignore it also ignores it where it matters.