Superseded by 0138: the pipeline order is fixed (tenancy,
iam, policy, entitlement); apps toggle and parameterise the gates.
Context
Routes, navigation, endpoints and features are filtered by a chain of gates: authentication, tenancy, IAMcheck(), feature flags and entitlements. Claude recommended locking tenancy and IAM into every chain, so an app could not forget them. The owner overrode that: each app configures its own chain, and the risk is handled by a warning instead.
Decision
- Each app configures its gate chain fully: which gates run, and in what order. The framework imposes no mandatory gate.
- Gates share one contract. Tenancy, IAM, feature flags (
@stackra/feature-flags), entitlements (@stackra/entitlements) and app-defined gates all plug into the chain the same way. - Consumers of the chain filter through it: the router,
@stackra/navigationand generated endpoints. pnpm validatewarns when an area’s chain omits the tenancy gate or the IAM gate. The warning names the app, the area and the missing gate. It does not fail the build.
Consequences
- An app with unusual needs (a public site, an operator console) is not forced through gates it does not use.
- A forgotten tenancy or IAM gate is a warning, not an error. Review must read the warnings, and the
security-tenancy-revieweragent treats an unexplained one as a blocking finding. - How an intended omission (for example, the public API area of 0082) is acknowledged so that it stops warning is TODO, settled in the gate-chain spec.
Enforcement
Planned: a warning-level check intools/scripts/validate-repository.mjs that reads each app’s gate configuration. Nothing checks this today.