egress-class-core.ts: USER/WORK/CUSTOMERS/ RESTRICTED anchor never matches — install scaffold ships no such directory

[JohnnyDisco7]

install/hooks/lib/egress-class-core.ts includes this path-classification rule:

{ re: /(?:LIFEOS|PAI)\/USER\/WORK\/CUSTOMERS\//, cls: "RESTRICTED" },

but the install scaffold (install/USER/WORK/) creates MY_ORG/, YOUR_COMPANIES/,
SAMPLE_CONSULTING/, and SAMPLE_CUSTOMER/ — there is no CUSTOMERS/ directory anywhere
in the shipped tree, and nothing in the docs instructs users to create one. The rule is a
dead anchor: it can never match on a stock install, so customer data placed where the
scaffold actually puts it (e.g. under YOUR_COMPANIES/) never gets the RESTRICTED class.

Practical impact is softened by the LIFEOS\/USER\// catch-all later in PATH_CLASS_RULES
(everything under USER still classifies CONFIDENTIAL, which blocks identically at the
PUBLIC ceiling on the GLM route), but the RESTRICTED-vs-CONFIDENTIAL distinction is lost,
which matters for any future route whose ceiling sits between the two.

Suggested fix — either:

1. Re-anchor the rule to the shipped schema (e.g. USER\/WORK\/(?:YOUR_COMPANIES|MY_ORG)\//
   or whatever directory the schema intends for customer/client data), or
2. Ship a USER/WORK/CUSTOMERS/ directory in the scaffold and document it as the home for
   customer-restricted material.

[JohnnyDisco7]

One more detail that makes this slightly worse than described above: the rule immediately after it depends on the dead one.

{ re: /(?:LIFEOS|PAI)\/USER\/WORK\/CUSTOMERS\//, cls: "RESTRICTED" },
{ re: /skills\/_[A-Z]/, cls: "CONFIDENTIAL" }, // any private (underscore-prefixed) skill dir — generalized off a hardcoded customer prefix. Customer-RESTRICTED data is caught by USER/WORK/CUSTOMERS above + the release deny-list; ...

The comment on the skills/_[A-Z] rule justifies its relaxation from RESTRICTED to CONFIDENTIAL on the grounds that "Customer-RESTRICTED data is caught by USER/WORK/CUSTOMERS above" — but that rule can never match on a stock install, so the stated backstop is not actually there. The relaxation may still be the right call on its own merits given the LIFEOS/USER/ catch-all, but the reasoning recorded in the comment rests on a rule that never fires.

Worth fixing the anchor and the comment together, so the next person generalizing a nearby rule isn't reasoning from the same premise.

[danielmiessler]

Confirmed. The anchor was live on this install (a real CUSTOMERS/ dir exists here), which is why the tests stayed green while every stock install shipped it dead — your diagnosis was right where it counted. The rule now covers the shipped scaffold names (CUSTOMERS|YOUR_COMPANIES|SAMPLE_CUSTOMER|SAMPLE_CONSULTING) with tests for each, and the phantom data-classification.json mirror claim is gone. Credited at the fix site.