@agent-native/core 0.122.4 → 0.123.1

package/corpus/templates/crm/.agents/skills/crm/SKILL.md

@@ -0,0 +1,205 @@
+---
+name: crm
+description: How to run typed CRM work — attributes and options, lists and pipelines, saved and board views, provider proposals, duplicates and merge, gated enrichment, and evidence-grounded call signals. Use for any CRM read, write, setup, or provider question.
+---
+
+# CRM
+
+`AGENTS.md` owns the invariants (attribute typing, bitemporal values, list
+authority, the provider handoff, credential and evidence boundaries). This skill
+is the how: which action, in what order, and the traps in between. Do not
+restate a rule here that `AGENTS.md` already states — fix it there instead.
+
+Model source of truth: `shared/crm-contract.ts`. Type registry:
+`shared/crm-attributes.ts`. Every field-value write goes through
+`server/lib/record-fields.ts`.
+
+## Pick the starting action
+
+- `get-crm-workspace` — "what should I work on", who the caller is, whether
+  their provider owner identity resolved. Read `ownerStatus` before trusting an
+  empty book: `unmapped`, `ambiguous`, and `unreadable` are different failures,
+  and none of them mean "no records".
+- `view-screen` — only when the request depends on the visible record,
+  selection, list, or view. `navigate` to show a view rather than describing it.
+- `list-crm-records` / `get-crm-record` / `get-crm-record-page` — ordinary reads.
+- `sync-crm` — one declared, bounded provider cohort. It is not an export-all,
+  and Native SQL never needs it.
+
+## Setup and modes
+
+- `configure-native-crm` starts a local-authoritative CRM with no provider,
+  portable across SQLite, Postgres, and D1. Then use the normal record, list,
+  task, view, and evidence actions. Never require a connection for Native SQL.
+- After HubSpot or Salesforce is authorized in workspace Connections, register
+  it with `configure-crm-connection`. Never pass a token. HubSpot starts with
+  companies/contacts/deals; Salesforce with Account/Contact/Opportunity.
+- `list-crm-connections` shows which object types a connection carries — read it
+  before authoring attributes on an object type.
+- Salesforce reads are revalidated against the current connection actor and
+  field permissions. Never infer a user's access from a service-account mirror
+  or a previously visible local row; fail closed when access is ambiguous.
+
+## Typed attributes and options
+
+- `list-crm-attributes` before any read, write, filter, or grouping. It returns
+  the type, cardinality (`multi`), authority, and managed options.
+- `create-crm-attribute` derives an immutable snake_case `apiSlug` from the
+  title. `update-crm-attribute` can change presentation, `required`,
+  `historyTracked`, config, `archived`, and `fillMode` — never the slug or the
+  type, because every stored value row is keyed and typed by them.
+- `manage-crm-attribute-option` adds an option *before* a value that uses it is
+  written. Archiving an option removes it from pickers only; records already
+  holding it keep the value.
+- `archive-crm-attribute` is a soft archive. Values and history stay. Restore
+  with `update-crm-attribute` and `archived: false`.
+- Status options may carry `targetDays` (a stage SLA the grid shows as overrun)
+  and `celebrate`.
+
+## Reading the grid
+
+- `list-crm-records` returns row summaries; `list-crm-record-values` returns the
+  cells for those rows with provenance. Filter, sort, and pagination all run in
+  SQL, so a filtered page is the real result set, not one page narrowed
+  afterwards. Pass `viewId` to apply a saved view's stored filter.
+- A filter naming an unknown or archived attribute fails rather than quietly
+  returning unfiltered rows. Do not "fix" that by dropping the filter.
+- `get-crm-record-page` is the whole record surface in one call: attribute
+  definitions, current values with actor and time, every list the record is in
+  with that entry's values, and the provider deep link.
+
+## Lists and pipelines
+
+- A list is a workflow overlay over one object type; entry attributes belong to
+  the list, not the record. `create-crm-list` seeds a Stage attribute unless you
+  pass `seedStageAttribute: false`.
+- `add-crm-record-to-list` never de-duplicates — it returns `existingEntryIds`
+  and lets you decide. Two open deals for one company are two entries.
+- **Moving a stage is `update-crm-list-entry`.** It closes the previous value's
+  row and opens a new one, so time-in-stage is derivable from the entry's own
+  history without a separate audit table.
+- Every `status` write goes through `server/lib/lifecycle.ts`. The enterable set
+  is the attribute's own options, so a move into an undeclared or archived stage
+  is refused with a sentence naming the values you may pick (`unknown-status`,
+  `archived-status`), and the move is claimed against the value it was decided
+  from, so a stage somebody else moved in between comes back as
+  `concurrent-transition` instead of being clobbered. Leaving any stage —
+  including a retired one — is always allowed. On a record, `update-crm-record`
+  applies the same gate to local targets; a provider target is still a proposal,
+  not a blocked transition.
+- `remove-crm-list-entry` deletes membership and that entry's values only. It is
+  not a way to delete a record.
+- `list-crm-record-field-history` reads either side: pass `entryId` for a stage
+  history, `recordId` for a record attribute.
+
+## Views and boards
+
+`save-crm-saved-view` stores filter, ordered sort, columns, `table`/`board`
+presentation, and personal/shared audience. A board view needs a
+`groupByAttributeId` pointing at a status attribute. Pass `expectedUpdatedAt` so
+a concurrent edit is rejected instead of silently overwritten. A view stores
+presentation, never provider rows. `run-crm-saved-view-program` runs the data
+program linked to one view.
+
+## Writes and the provider handoff
+
+- `update-crm-record` for a scoped typed edit. Provider-owned fields become
+  revision-aware, access-checked, idempotent, audited proposals.
+- `list-crm-proposals` then `apply-crm-proposals`: the second returns the exact
+  before/after diff and a deep link, and records the handoff. A proposal with
+  status `approved` and no `appliedAt` was prepared and handed off — present
+  that as the next step for the user, never as a failure and never as applied.
+- The only stored delegation pack is `crm-sales-routine-local-v1`: one routine,
+  compensatable local update to one record, supplied by a trusted automation
+  trigger, never by action input.
+
+## Duplicates and merge
+
+`find-crm-duplicates` is read-only and never merges. It matches on exact email,
+company domain, shared email root domain, and normalized name plus location, and
+returns a reason and confidence per candidate. A shared company domain is a
+signal between accounts only — colleagues are a relationship, not a duplicate.
+
+`merge-crm-records` needs an explicit survivor. It promotes only the values the
+survivor lacks, moves list entries, tasks, interactions, evidence, signals, and
+relationships from both sides, and tombstones the loser with a `merged-into`
+link instead of deleting it. It is idempotent and approval-gated for non-human
+callers. Show the candidate reasons and let a human pick the survivor.
+
+## Enrichment (money changes hands)
+
+1. `list-crm-enrichment-slots` — which capability slots are usable. A slot's
+   `credential.status` of `unknown` means the lookup itself failed and is *not*
+   the same as `missing`.
+2. `estimate-crm-enrichment` — line-item cost and period-to-date spend. Quote it
+   to the user. `spendToDate.actorUnits` is theirs and is what the cap applies
+   to; `workspaceUnits` is everyone's and is context only.
+3. `run-crm-enrichment` with `phase: "verify"` — free evidence pass, never
+   touches contact data. A human reviews its per-record evidence.
+4. `run-crm-enrichment` with `phase: "spend"` — requires `sourceRunId` and the
+   explicit `approvedRecordIds` from that review. The paid input set is built
+   from those approvals, so an unapproved record is never visible to the paid
+   job. Both phases refuse a duplicate in-flight run for the same scope.
+
+A slot outcome is one of `unconfigured`, `skipped`, `ok`, `empty`, or `error` —
+report the one you got. "We could not find out" is not "there is none".
+
+## Agent attribute fill
+
+`run-crm-attribute-fill` is manual only. Call it with no `values` to get the
+brief (attribute, managed options, each record's current value and context),
+reason over that yourself, then call again with `values`. Never call a model
+inline. Writes merge: a human edit or a purchased value is kept and reported as
+`kept-existing`, an equal value is not rewritten. Classifying against a
+status/select attribute must produce one of its managed options; an unknown one
+rejects the whole call and writes nothing.
+
+## Evidence and signals
+
+- `attach-call-evidence` stores only a source URL/id, bounded quote, timestamp,
+  speaker, and metadata. For Clips use a durable `/share/<id>` or `/r/<id>` page
+  URL with no access token or transcript fragment — never a `clip.created` event
+  URL.
+- `run-crm-signal-trackers` runs only over evidence already attached to the
+  record. Keyword hits are deterministic; smart detectors and summaries are
+  delegated through agent chat, never a direct model call, and persisted with
+  `record-crm-smart-signal` or one atomic `record-crm-call-insight` batch whose
+  every quote and timestamp cites an exact stored evidence row.
+- `create-crm-signal-tracker` / `manage-crm-signal-tracker` need editor access.
+  Enabling, disabling, and deleting a tracker are local configuration only:
+  never a model call, never a provider mutation. Their settings tab is
+  `navigate({ view: "settings", settingsSection: "intelligence" })`.
+- `review-crm-signal` is the human confirm/dismiss step.
+- `get-crm-automation-recipe` returns the default-off Clips review recipe for
+  one explicitly selected record. The recipe is a configuration aid, not
+  permission to activate it: show the exact Clips-owned `clip.created` trigger,
+  the selected record, and its one bounded local evidence write, then get a fresh
+  approval. The trigger must call `prepare-crm-call-evidence` with the clip id
+  and hand back only the durable `/r/<id>` reference. It cannot create tasks,
+  field updates, proposals, or provider mutations.
+
+## Dashboards
+
+`install-crm-pipeline-dashboard` is idempotent and owns one per-user data
+program that calls the bounded `get-crm-pipeline-data` through `appAction`. Do
+not reimplement that aggregate with a provider request or put CRM rows in
+dashboard config. Edit with `save-crm-dashboard` plus `expectedUpdatedAt`;
+inspect and roll back with `list-crm-dashboard-revisions` /
+`restore-crm-dashboard-revision`.
+
+## Provider API escape hatch
+
+CRM actions are convenience workflows, not a capability ceiling. For an
+endpoint, object, filter, pagination mode, or schema no action expresses, use
+`provider-api-catalog`, then `provider-api-docs`, then the read-only
+`provider-api-request`. Declare a cohort, selected fields, and a page/row budget
+first; stage only that result and reduce it with `query-staged-dataset` or a
+data program. Report provider, scope, filters, page/row counts, truncation, and
+gaps. Always pass the selected workspace `connectionId` for Salesforce so its
+actor-bound token and instance URL cannot be separated.
+
+## Out of scope
+
+No provider migration, no page builder, no raw provider payload or media in CRM
+SQL. Native SQL supports the canonical CRM objects plus generic custom records; a
+separate object-authoring engine is not part of this template.

package/corpus/templates/crm/.agents/skills/customizing-agent-native/SKILL.md

@@ -0,0 +1,220 @@
+---
+name: customizing-agent-native
+description: >-
+  How to configure, compose, or eject Agent Native features into app-owned
+  code. Use when overriding shared components or integrations, customizing a
+  template, adding UI to chat or headless apps, or inspecting package source.
+scope: dev
+metadata:
+  internal: true
+---
+
+# Customizing Agent Native
+
+## Rule
+
+Start with the app's registered design system and local UI adapters, then use
+the public feature's props, semantic components, controller, product slots,
+and callbacks. If those seams are not enough, use the eject CLI to transfer
+the smallest supported feature into the app and make that copy app-owned.
+Never edit `node_modules`, deep-import a private source file at runtime, or
+patch an `@agent-native/*` package.
+
+Use this order:
+
+1. Set brand tokens with the build-time theme configuration when tokens are
+   enough.
+2. Register company components in `app/design-system.ts` with
+   `defineDesignSystem`, then pass that definition to `ToolkitProvider`.
+3. Configure a public feature through its semantic components, headless
+   controller, and product-level render slots.
+4. Compose app primitives behind the app's local UI adapter layer.
+5. Eject the smallest feature into app-owned source.
+6. Propose a new Toolkit seam when the same override is useful in two apps.
+
+Ejection is for intentional product customization, not for hiding an upgrade
+failure or replacing Core runtime behavior.
+
+## Use A Company Design System
+
+Keep the explicit, typed registration seam in `app/design-system.ts`:
+
+```tsx
+import { defineDesignSystem } from "@agent-native/toolkit/design-system";
+import {
+  AcmeActionButtonAdapter,
+  AcmeDialogAdapter,
+} from "./design-system/acme-adapter";
+
+export const designSystem = defineDesignSystem({
+  name: "Acme",
+  components: {
+    ActionButton: AcmeActionButtonAdapter,
+    Dialog: AcmeDialogAdapter,
+  },
+});
+```
+
+Adapters translate the semantic Toolkit contract into company component props.
+They are ordinary React components and may use MUI-style providers, React Aria,
+CSS modules, CSS-in-JS, or another styling runtime. `className` and `style` are
+optional interoperability hooks, not Tailwind or CVA requirements.
+
+The contract has nine leaf components (`ActionButton`, `IconButton`,
+`TextField`, `TextArea`, `Spinner`, `Skeleton`, `Status`, `Surface`, `Avatar`)
+and eight behavior components (`Tooltip`, `Menu`, `Popover`, `Dialog`,
+`Picker`, `Checkbox`, `Switch`, `Tabs`). `Picker` covers select and combobox
+behavior, not date picking. Behavior adapters own their portal, focus,
+keyboard, dismissal, and stacking implementation while honoring the semantic
+props and `portalContainer` interop contract.
+
+App product code imports standard controls from its local adapter path, usually
+`@/components/ui/*`. Do not import `@agent-native/toolkit/ui/*` directly from
+pages, routes, or domain components. That bypasses the app seam and makes a
+future design-system replacement incomplete. Toolkit feature packages remain
+valid imports; configure their presentation through the registered semantic
+components, controller, and product slots.
+
+Run the published conformance kit against a complete adapter in its own CI:
+
+```tsx
+import { assertDesignSystemConformance } from "@agent-native/toolkit/conformance";
+import { DESIGN_SYSTEM_CONTRACT_VERSION } from "@agent-native/toolkit/design-system";
+
+await assertDesignSystemConformance({
+  adapterName: "Acme",
+  components,
+  contractVersion: DESIGN_SYSTEM_CONTRACT_VERSION,
+});
+```
+
+New components and optional props are minor contract changes. Required props,
+removed APIs, or behavioral changes require a new contract major.
+
+## Customize A Shared Feature
+
+Prefer feature-level headless controllers over rebuilding individual widgets.
+One controller must power both the Toolkit default view and every custom render
+path so behavior, actions, analytics, accessibility state, and error handling
+cannot drift. Use a product-level render slot to replace the view while keeping
+that controller. Eject only when the controller and slots cannot express the
+required product behavior.
+
+## Eject A Feature
+
+Discover and inspect the ejection units published by installed first-party
+packages before changing source:
+
+```bash
+agent-native eject --list
+agent-native eject inspect <unit>
+agent-native eject <unit> --app <app>
+agent-native eject <unit> --app <app> --apply
+```
+
+The command is dry-run by default. It prints the file closure, consumer import
+rewrites, protected package contracts, and verification commands before
+writing. `--apply` copies the package-version-matched source into the app and
+rewrites only imports covered by the unit manifest.
+
+Every first-party public ejection unit must have a complete manifest. If one is
+missing, treat that as a framework coverage bug instead of inventing a copy
+recipe. For an unknown third-party package, use the emitted add-style blueprint
+as a starting point. Protected runtime behavior is never copied; follow the
+reported configuration, adapter, or extension seam instead.
+
+Applied ejections are recorded in the committed
+`agent-native.ejections.json`, including package version, manifest digest,
+target hashes, and import rewrites. Use the recorded state to review drift or
+undo an unchanged ejection:
+
+```bash
+agent-native eject diff <unit> --app <app>
+agent-native eject restore <unit> --app <app>
+agent-native eject restore <unit> --app <app> --apply
+```
+
+Restore is hash-gated. It refuses to remove locally edited files or reverse
+changed imports and prints their diff instead. Keep an edited ejection as
+app-owned code, or reconcile those edits before restoring it.
+
+## Find The Installed Implementation
+
+Use the source that matches the installed package version:
+
+```bash
+pnpm action docs-search --query "<component or feature>"
+pnpm action source-search --query "<component or symbol>"
+rg -n "<component or symbol>" node_modules/@agent-native/toolkit/src
+rg -n "<component or symbol>" node_modules/@agent-native/core/corpus
+```
+
+- Toolkit publishes readable TypeScript under
+  `node_modules/@agent-native/toolkit/src/` for selective UI adoption.
+- Core and first-party template source lives under
+  `node_modules/@agent-native/core/corpus/core/` and
+  `node_modules/@agent-native/core/corpus/templates/`.
+- Treat those trees as read-only references. Prefer `agent-native eject` so the
+  package manifest selects the complete source closure and rewrites imports.
+  Manual inspection is still useful for deciding whether to configure,
+  compose, eject, or propose a shared seam.
+
+Do not manually guess at sibling dependencies. The ejection manifest owns the
+required file closure and keeps protected contracts on public package imports.
+
+## Preserve The Agent-Native Contract
+
+UI ownership may change; product contracts should not:
+
+- Keep app operations in `defineAction` actions and call them through
+  `useActionQuery`, `useActionMutation`, or another named client helper.
+- Keep navigation, selection, and focused-object state visible through the
+  existing application-state keys.
+- Keep AI work in the shared agent chat instead of adding direct LLM calls.
+- Keep auth, access checks, persistence, chat transport, and agent execution in
+  Core. Do not copy those runtimes into the app.
+- Keep local adapters narrow so package upgrades still improve every surface
+  the app has not intentionally taken ownership of.
+- Keep page, route, and domain code on local UI adapter imports. Never reach
+  around the registered design system with direct Toolkit UI primitive imports.
+
+## App Shapes
+
+- **Template app:** begin with `app/design-system.ts`, its local UI adapters,
+  and domain UI. Use Toolkit features for repeated workspace behavior; eject
+  only the unit being customized.
+- **Chat app:** keep `AgentChatSurface`, thread state, and chat transport in
+  Core. Compose or eject Toolkit presentation such as chat-history UI around it.
+- **Headless app:** stay action-first while no UI is needed. When adding a UI,
+  use the Chat template as the on-ramp or add Toolkit components without
+  replacing the existing actions.
+- **Workspace:** put one-app overrides in that app. Promote a local component
+  to `packages/shared` only when multiple workspace apps use it.
+
+## After Ejecting
+
+- Commit `agent-native.ejections.json` with the app-owned files and rewrites.
+- Remove unused dependencies and imports from the ejected files.
+- Keep visible text in the app's localization catalogs.
+- Run the manifest verification commands plus the app's formatter, typecheck,
+  and focused tests.
+- Re-check the installed source during future package upgrades; the app-owned
+  ejection does not receive upstream fixes automatically. Use `eject diff` to
+  distinguish recorded output from subsequent local edits.
+
+## Don't
+
+- Don't edit or import from `node_modules/@agent-native/*/src` at runtime.
+- Don't add `pnpm.overrides`, patches, or resolutions for Agent Native packages.
+- Don't copy Core auth, DB, action, agent-loop, or transport internals.
+- Don't manually copy a first-party unit with a missing recipe; fix its manifest.
+- Don't eject a full package when a prop, slot, wrapper, or smaller unit works.
+- Don't fork feature state into a custom view; consume the feature's controller.
+
+## Related Skills
+
+- `agent-native-docs` — version-matched docs and source lookup
+- `agent-native-toolkit` — shared-vs-app-owned architecture boundary
+- `self-modifying-code` — safe app source edits
+- `upgrade-agent-native` — supported package upgrade path
+- `adding-a-feature` — UI/action/instructions/application-state parity

package/corpus/templates/crm/.agents/skills/feature-flags/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: feature-flags
+description: >-
+  Declare, evaluate, manage, and remove framework feature flags. Use when
+  shipping a capability gradually, targeting users or organizations, or
+  replacing a compile-time rollout switch with a production-safe runtime flag.
+scope: dev
+metadata:
+  internal: true
+---
+
+# Feature Flags
+
+A feature flag is a boolean declared in app code, evaluated locally by Core,
+and managed from the Analytics fleet control plane. Code owns whether a flag
+exists. Runtime settings own only its rollout state.
+
+Flags let an app deploy dormant code and turn it on in the real environment
+without another deployment. They are not experiments: do not add variants,
+hypotheses, conversion metrics, exposure tracking, or lifecycle states.
+
+## When to use one
+
+Use a flag for a reversible rollout of a user-facing capability whose dormant
+code is safe to deploy. Flags are useful for production dogfooding, exact-user
+or organization pilots, and deterministic percentage rollouts.
+
+Do not use a flag for authentication, authorization, secrets, audit enablement,
+SSR cache behavior, or another security boundary. Client hiding is presentation
+only; every guarded server action must evaluate the same registered flag.
+
+## Agent workflow
+
+### 1. Declare
+
+Keep definitions in a shared TypeScript module so server and client code use the
+same stable key. Flags are boolean and default-off.
+
+```ts
+import { defineFeatureFlag } from "@agent-native/core/feature-flags/registry";
+
+export const FULL_APP_BUILDING = defineFeatureFlag({
+  key: "full-app-building",
+  displayName: "Full app building",
+  description: "Create and edit Fusion-backed applications.",
+});
+```
+
+Keys are immutable, never reused, and contain only letters, numbers, dots,
+underscores, or hyphens. Prefer a concise app-owned name. Do not create flag
+definitions or rollout rows from Analytics.
+
+### 2. Register
+
+Register app definitions from a Nitro plugin before actions are discovered.
+Do not add app-specific flags to a Core registry.
+
+```ts
+import { createFeatureFlagsPlugin } from "@agent-native/core/server";
+
+import { FULL_APP_BUILDING } from "../../shared/feature-flags.js";
+
+export default createFeatureFlagsPlugin({ flags: [FULL_APP_BUILDING] });
+```
+
+### 3. Guard server and client
+
+The server action is the enforcement boundary:
+
+```ts
+import { isFeatureFlagEnabled } from "@agent-native/core/feature-flags";
+
+run: async (args, ctx) => {
+  if (!(await isFeatureFlagEnabled(FULL_APP_BUILDING, ctx))) {
+    throw new Error("Full app building is not enabled for this account.");
+  }
+  // guarded operation
+}
+```
+
+Use the client hook only to hide or reveal hydrated UI:
+
+```tsx
+import { useFeatureFlag } from "@agent-native/core/client/feature-flags";
+
+const enabled = useFeatureFlag(FULL_APP_BUILDING.key);
+return enabled ? <FullAppOption /> : null;
+```
+
+The client hook intentionally returns false while loading or for an unknown
+flag. Never replace that fail-closed behavior with app-local bucketing or a
+compile-time fallback. Never evaluate personalized flags in the public SSR
+shell; it is shared and cached for every visitor.
+
+### 4. Verify and roll out
+
+1. Verify the off path before changing rollout state.
+2. Confirm the registered flag appears in **Analytics → Feature flags** for the
+   app and is Off by default.
+3. Use **Enable for me** for initial production dogfood.
+4. Expand to exact emails, organization IDs, or a percentage only from
+   Analytics.
+5. Confirm the client presentation and authoritative server action agree.
+
+## Management contract
+
+Core mounts three actions in registered apps:
+
+| Action | Purpose |
+| --- | --- |
+| `get-feature-flags` | Return the current caller's evaluated boolean values. |
+| `list-feature-flags` | Return definitions and rollout metadata to an authorized operator. |
+| `set-feature-flag` | Atomically turn a flag off, enable it for the operator, or replace targeting rules. |
+
+Analytics calls the app-local operator actions through narrowly scoped A2A
+delegation. Tokens require an exact audience, organization, scope, operator
+role, and audit correlation id. Management is permission-checked and audited
+by the target app. Never manage flags through generic settings routes, raw SQL,
+or per-app toggle UIs.
+
+## Rollout semantics
+
+The operator modes are **Off**, **Targeted**, and **Everyone**. Core stores them
+as `off`, `rules`, and `on`.
+
+Targeted rules combine exact normalized emails, exact organization IDs, and a
+percentage with OR semantics. Exact matches are checked first. Percentage
+buckets use Core's stable hash of the flag key and authenticated user identity;
+anonymous callers fail closed. Raising a percentage preserves the users already
+included at a lower percentage. Do not implement bucketing in app code.
+
+Unknown definitions, missing state, malformed state, storage errors, and
+evaluation errors all return the code default (`false` in v1). Explicit Off
+wins over every target; Everyone enables every authenticated caller.
+
+## Remove a flag
+
+After a rollout is permanent:
+
+1. Replace guarded branches with the chosen behavior.
+2. Delete the server and client gates.
+3. Delete the definition and registration entry.
+4. Verify the flag disappears from the Analytics fleet.
+5. Remove stale tests and rollout instructions.
+
+A permanent flag is just an if statement with a pension plan.
+
+## Verification checklist
+
+- Unknown and unregistered keys evaluate false.
+- UI hiding and server enforcement use the same registered key.
+- Exact-user, organization, deterministic percentage, Everyone, and Off paths
+  have focused tests.
+- Increasing a percentage is monotonic; anonymous percentage evaluation is off.
+- Unauthorized callers cannot list targeting details or mutate flags.
+- Mutations are atomic, read back stored state, emit refresh, and appear in the
+  audit log with the flag key.
+- Analytics represents ready, no-definition, unsupported, forbidden, legacy,
+  and unreachable directory apps honestly.
+- Future agents can find this skill from root `AGENTS.md`, and
+  `pnpm guard:workspace-skills` passes after syncing generated copies.
+
+## Related skills
+
+- **adding-a-feature** — preserve UI/action/instruction/application-state parity
+- **actions** — define and call guarded app operations
+- **audit-log** — inspect automatic action mutation history
+- **reliable-mutations** — make rollout changes atomic and provable
+- **security** — keep security controls out of feature flags