# Installed search scope

Both `/metadata/search/scope-order` and `/search/scopeOrder` assemble their
candidates from the installed pack declarations and effective object shape in
one AppMetadataView V3 revision. The original signed AppRelease components are
not effective tenant metadata. In particular, selecting the L1 business key
`crm_search_scope_order` silently excludes declarations with a different L2 key.

## Ownership and read path

1. L1/L2 pack authors own `search_scope_order` payloads. The existing pack
   compiler validates object ownership and rejects conflicting declarations.
2. Controlplane reads `RuntimeSearchScopeOrder` from verified active immutable
   PackGenerations in the same transaction as the effective object metadata.
   It preserves pack-name order and authored item order, restricts the projection
   to the effective object closure, and publishes
   `metadata.effective.search-scope.v1` / `search-scope` (format 1).
3. The neutral contract owns the component identity. The component behavior is
   the existing ordered JSON array of `{name, label}` declarations. There is no
   new transport operation, tenant literal, process registry or alternate
   source of truth in L0.
4. SF CRM AppService owns assembly: resolve canonical names and labels from
   effective object metadata, exclude non-searchable objects, and apply current
   Runtime read permissions. The v63 endpoint preserves Runtime scope ordering;
   the metadata endpoint preserves declared order. Runtime requests carry the
   same minimum Catalog revision and response receipts must reconcile.

Missing, conflicting, unsupported or malformed effective scope fails closed.
The old AppRelease scope and raw object-spec readers are removed. An explicit
empty installed declaration returns an empty list without a Runtime request.
The existing permission batching helper owns response bounds and batch receipt
consistency; the search adapter does not implement another permission reader.

## Release closure

The 0.74.0 capability mapping consolidates the former standalone
search-scope handler into the existing search handler. Its dependencies are the
actual V3 metadata, search, query and permission capabilities. Keeping the old V1
metadata grant merely to occupy a Catalog serving slot would be false authority.
Historical release mappings and signed artifacts remain unchanged.

Contract #232 and Controlplane #458 are merged. The AppService and release
builder pin those immutable published Go module revisions. The 0.74.0 package
and one-shot attestation are built from the frozen source commit using the
existing exact-commit flow in `application-navigation-cutover.md`.
The Catalog image must include the installed search-scope projection before
this AppService and AppRelease are selected for deployment. Do not combine the new AppService with an
old Catalog projection or a release that still requires the removed standalone
scope handler. L2 must select these exact release and image identities together.

## Verification

The regression presents an unchanged L1 AppRelease with only standard objects
and an effective snapshot with additional installed custom objects. Both HTTP
endpoints must expose readable/searchable custom objects, exclude denied and
non-searchable objects, preserve ordering and use effective labels. Removing
the effective scope must fail even while the old L1 defaults remain valid.

Controlplane tests cover installed ordering/conflicts, the complete V3 producer
path, transaction preservation and real TiDB generation identity checks.
Release tests cover the consolidated dependency closure and preserve the prior
release mapping. AppService tests cover permissions, malformed authority,
revision/security consistency, cancellation and both public wire shapes.