finding(skills): two published guides name `app` as an expression scope root, which the #8155 ruling removes

[os-justin]

Filed unassigned and unlabelled for PM triage by the #7727 dev (session session_01YBWFb5YgMU5dw8p2VKj16S), found while implementing the #8155 ruling in PR #8164. ⛔ Deliberately not folded into that PR — see "Why not folded in" below; the reason is a merge-route change, not effort.

What

PR #8164 executes the #8155 ruling: app is removed from app-shell's expression scope, because neither ADR-0068 nor @objectstack/formula's SCOPE_ROOTS declares such a root. After it lands, two lines in the published skills tree state something false:

• skills/objectui/guides/auth-permissions.md:312 — a table row reading, in effect, that app and features come from "the ambient host scope".
• skills/objectui/rules/protocol.md:283 — prose describing a predicate over features / current_user / app / data.

Both name app as a readable expression/predicate root. It is not one any more.

Why it matters more than a typo

This is the same defect class the #8155 ruling exists to remove: a surface advertising a root that nothing binds. Unresolvable visibility predicates fail open, so a reader who follows this guidance writes a gate that silently reads as "yes" rather than erroring. The published skills tree is what customers author against, so the blast radius is larger than the in-repo docs.

Not in scope, and still true

Two other app. mentions in the same tree are a different mechanism and must not be swept up:

• skills/objectui/guides/schema-expressions.md:305 and skills/objectui/rules/protocol.md:215 — both read, in effect, that a nested bind path of the form app.settings.users resolves against dataSource. That is data binding, not the predicate scope, and it is unaffected.

skills/objectui/guides/app-composition.md mentions of *.app.ts and app.zod.ts are filenames.

Why not folded into PR #8164

skills/** is a governed surface (AGENTS.md, and scripts/check-governed-queue-guard.mjs's GOVERNED_SURFACES — the skills-catalog entry). A PR whose diff touches one governed path is governed entirely, and governed PRs stop in draft for a human to merge rather than taking the normal review-and-queue route.

PR #8164 is currently not governed — verified: node scripts/check-governed-queue-guard.mjs --test over its 10 paths returns NOT GOVERNED. Adding these two files would move it onto the human-merge path and change how it lands. That is a routing decision for the PM and the maintainer, not something for the implementing dev to take unilaterally, so it is filed rather than folded.

The equivalent non-governed corrections were made in #8164: content/docs/core/enhanced-actions.mdx, content/docs/guide/console-architecture.md and content/docs/plugins/plugin-form.mdx.

Note for whoever picks this up

The ASCII diagram at content/docs/guide/console-architecture.md:44 shows ExpressionProvider (user, app, evaluator) and is correct as it stands — it describes the React context value, which does still carry app. Only the expression scope lost it. The same distinction applies when judging the two skills lines: if either turns out to be describing the context value rather than the predicate scope, it is fine as written.

Dedup

MCP search_issues (REST /search/issues is 403 from this seat — the container's egress proxy restricts to repository-scoped paths, which says nothing about GitHub scope). Query returned 5 results, so the channel was live and the reading self-validating. Nearest: #7728 (same file family, but the bare-field / data.* spellings, and already shut), #7636, #7015. None names the app root.

Attribution, in prose because issue creation strips footer blocks: generated by Claude Code, session session_01YBWFb5YgMU5dw8p2VKj16S.

---

Generated by Claude Code