The legacy config path is still allow-by-default

[M-ballabio1]

An installation with no policy falls back to the old permission manager, which permits by default. On a product whose claim is a verifiable perimeter, the default configuration should not be the permissive one.

Today. annona policy init is what switches an installation onto the policy engine. Until somebody runs it, the old path applies.

Wanted. A fresh install is fail-closed without anyone having to know a command exists. Either the default config carries a policy, or the absence of a policy denies rather than allows.

Worth deciding explicitly what happens to installations that are already running on the legacy path — silently tightening them is a behaviour change, and should be one people are told about.

Source: README, "What is built, and what is not".

[M-ballabio1]

The counter-argument to this issue is already written in the code, and it is a good one. AIClient._build_enforcement (runner/ai_client.py:523):

Absence of a policy file is not treated as "enforce with defaults": turning a working installation into a default-deny one because a file appeared elsewhere would be a hostile upgrade. It is turned on by writing a policy (annona init) or by asking for it in the config.

That is correct for an installation that is already running, and it is the whole of the objection this issue raised at the end. It is not correct for an installation that has never run, and conflating the two is what leaves the default permissive.

The distinction to make. A fresh install has no working behaviour to break. It cannot be upgraded hostilely, because there is nothing there yet. So "no policy" should mean deny at the moment the installation is created, and keep meaning legacy for one that predates the policy engine.

There is already a place to do it. Two functions exist and are never called together:

• ConfigManager.create_default_config (runner/config.py:41) — what a fresh install gets, called from the unattended path added for containers (runner/cli.py:228, "wrote the defaults (local-only, cloud off)... three read-only tools").
• write_default_policy (runner/policy/loader.py, used today only by annona policy init at runner/cli_perimeter.py:69).

A fresh install that writes one and not the other is the entire bug. Writing the policy alongside the config makes annona init and annona run-on-an-empty-home both fail-closed, without touching the semantics of _build_enforcement at all — which stays exactly as the docstring argues it should, because an existing install still has no policy file and still gets the legacy path.

What is left over, and is the real decision. Installations already on the legacy path. Three options, in the order I would rank them:

1. Leave them, and say so. They keep working; annona policy init is the opt-in. Honest, and the gap stays open forever.
2. Warn on every run that this installation is unenforced, with the one command that changes it. Costs nothing, cannot break anyone, and makes the state visible rather than silent — which is the actual complaint, since today an operator cannot tell which of the two wirings they are on without reading the source.
3. Tighten on a version boundary, announced in CHANGELOG.md.

(2) is not a compromise between the other two, it is a prerequisite for either — nobody should be running unenforced without knowing it. Worth doing under this issue regardless of where the migration lands.

Milestoned v0.2 and labelled blocker: the README says the perimeter is the product, and the default configuration is the one that does not have it.