@agent-native/core-corpus 0.213.1 → 0.216.0

package/corpus/templates/slides-2/.agents/skills/portability/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: portability
+description: >-
+  How to keep template code PostgreSQL-specific and hosting-agnostic. Use when
+  defining schemas, writing raw SQL, or creating server routes.
+scope: dev
+metadata:
+  internal: true
+---
+
+# Portability
+
+## Rule
+
+Templates use one PostgreSQL schema and query contract. Local PGlite and hosted
+PostgreSQL share the same SQL semantics.
+
+## Database
+
+Use Drizzle's PostgreSQL exports directly for schemas and its query builder for reads/writes:
+
+```ts
+import { sql } from "drizzle-orm";
+import {
+  boolean,
+  doublePrecision,
+  integer,
+  pgTable,
+  text,
+} from "drizzle-orm/pg-core";
+
+export const meals = pgTable("meals", {
+  id: text("id").primaryKey(),
+  name: text("name").notNull(),
+  calories: integer("calories").notNull(),
+  weight: doublePrecision("weight"),
+  archived: boolean("archived").notNull().default(false),
+  createdAt: text("created_at").notNull().default(sql`now()`),
+});
+```
+
+| Export            | Purpose                                      |
+| ----------------- | -------------------------------------------- |
+| `pgTable`         | Defines a PostgreSQL table                   |
+| `text`            | Defines a text column, with optional enum values |
+| `integer`         | Defines an integer column                    |
+| `boolean`         | Defines a boolean column                     |
+| `doublePrecision` | Defines a double-precision column            |
+| `sql`             | Builds SQL expressions such as `now()`       |
+
+Use `@agent-native/core/db/schema` only for framework-owned sharing helpers such
+as `ownableColumns()` and `createSharesTable()`.
+
+Use Drizzle's PostgreSQL query builder for app code:
+
+```ts
+import { and, desc, eq } from "drizzle-orm";
+
+const rows = await db
+  .select()
+  .from(meals)
+  .where(and(eq(meals.ownerEmail, userEmail), eq(meals.archived, false)))
+  .orderBy(desc(meals.createdAt));
+```
+
+Avoid `db.execute(...)`, `getDbExec()`, and handwritten SQL in actions, handlers, and stores when Drizzle can express the query. Raw SQL should be limited to additive migrations, health checks, carefully reviewed advanced queries, or one-off maintenance scripts. For timestamps in Drizzle schemas, use `.default(now())`; for migration SQL, use `runMigrations()`.
+
+### Raw SQL helpers
+
+- `getDbExec()` — executes parameterized PostgreSQL SQL
+- Use PostgreSQL types such as `BIGINT` directly in raw SQL.
+
+### Never
+
+When writing docs, say "PostgreSQL" or "PGlite" precisely.
+
+Use Postgres syntax deliberately in advanced queries and migrations, and prefer
+Drizzle APIs or framework helpers for ordinary application code.
+
+When giving deployment guidance, be precise about durability: local PGlite is for development, while shared and production environments need a persistent hosted PostgreSQL `DATABASE_URL`.
+
+## Hosting Agnostic
+
+The server runs on **Nitro** with **H3** as the HTTP framework. Templates must be deployable to any Nitro-supported target.
+
+### Never use Express
+
+All server code uses H3/Nitro: `defineEventHandler`, `readBody`, `getMethod`, `setResponseHeader`, etc. Express is not a dependency. If you see Express types or patterns anywhere, replace them with H3 equivalents.
+
+### No platform-specific config in scaffolded template source
+
+Files like `netlify.toml`, `wrangler.toml`, `vercel.json`, and `netlify/functions/` must NOT appear in the CLI scaffold source (`packages/core/src/templates/`) — apps generated for users stay hosting-agnostic, with platform configuration living in CI/hosting dashboards.
+
+This monorepo's own first-party deployed apps keep platform configuration in app-specific hosting manifests such as `templates/*/netlify.toml`; this rule only applies to the CLI scaffold source.
+
+### No Node APIs in server routes/plugins
+
+Never use `fs`, `child_process`, or `path` in server routes and plugins. Use Nitro abstractions. (Actions in `actions/` run in Node.js and can use Node APIs freely.)
+
+### No persistent-process assumptions
+
+Never assume a persistent server process. Use the SQL database for all state.
+
+## Related Skills
+
+- `storing-data` — Schema patterns and the core SQL stores
+- `server-plugins` — Framework routes and H3 handler patterns
+- `security` — SQL injection prevention via parameterized queries

package/corpus/templates/slides-2/.agents/skills/real-time-sync/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: real-time-sync
+description: >-
+  Decide whether a page needs external changes before refresh, then use the
+  opt-in shared SSE and polling transport safely.
+scope: dev
+metadata:
+  internal: true
+---
+
+# Real-Time Sync
+
+## Decision rule
+
+Opt in only when both are true:
+
+1. The data can change without the current user acting.
+2. The user needs to see that change before refreshing or navigating.
+
+A local agent edit does not meet this rule. The chat run stream already
+invalidates action queries and source counters after each side-effecting tool
+and again at run end, without opening a background poll.
+
+### Opt in
+
+- **Slides deck editor:** another collaborator can edit the open deck.
+- **Mail inbox:** new mail can arrive while the inbox is open.
+- **A watched job:** a background job changes progress while the user watches it.
+- **Cross-tab state:** state must converge across this user's open tabs without a
+  new action.
+
+### Keep it off
+
+- Public, anonymous, marketing, docs, and SSR pages.
+- Settings, forms, and read-mostly lists or dashboards. Refresh them on focus or
+  navigation instead.
+- Single-user agent edits. The chat run stream handles those.
+- Pages where an update is useful eventually but not before the next refresh.
+
+## Cost and behavior
+
+`useDbSync()` has no background transport unless the page opts in with a
+non-empty reason. One transport is shared per tab. A visible opted-in tab polls
+at 1 minute, then 2, then 5 minutes while idle; user activity or a local
+mutation resets that sequence. Hidden tabs pause by default. During an active
+agent run, opted-in sync can poll at its configured `interval`; local tool
+completion and run-end invalidation do not depend on that poll.
+
+On a long-lived host, same-process changes stream over
+`/_agent-native/events`; polling is the cross-process fallback. On a production
+serverless host, the local events endpoint refuses the long-lived stream and
+`/_agent-native/poll` carries remote changes. The paid Hosted Realtime Sync
+Gateway is not required for this pattern.
+
+While a collab doc shows another person present, the transport polls every
+2.5 s instead (`acquireCollabPollBoost()`, held by the collab client, not by
+pages). It is a no-op whenever a stream is connected, lapses after 3 minutes
+without input or remote events, and never applies to lone tabs.
+
+## Use the hook
+
+Declare the reason beside the route gate so reviewers can see why the page pays
+for remote sync:
+
+```tsx
+useDbSync({
+  queryClient,
+  realtime: isPrivateDeckEditorPath(location.pathname)
+    ? { reason: "other collaborators can edit this deck while it is open" }
+    : undefined,
+  pauseWhenHidden: true,
+});
+```
+
+The reason is required by the TypeScript API. Opt in only for a named private
+or authenticated route; public, documentation, and SSR pages should not start a
+background transport.
+
+An opted-in page only hears about an action when its change event reaches the
+current user. By default an `action` event reaches the actor alone, so a
+collaborator's comment, save, or agent edit never arrives. Declare
+`changeResource: (input, result) => ({ resourceType, resourceId })` on the
+mutating action and the event also reaches everyone who can read that resource.
+Name it from `input` when the call carries the resource id (Content's
+`documentChangeResource`, Slides' comment actions) and from `result` when the
+call is keyed by a child id (Design's `designChangeResource` for
+`delete-file`); return `null` for a call that changed nothing. Do not publish a
+parallel per-template event for the same purpose.
+
+Do not start `subscribeSyncEvents()` or an `EventSource` in a feature to bypass
+the decision. `subscribeSyncEvents()` is a lower-level transport subscription
+used by the existing Yjs collaboration client and narrow framework plumbing.
+Keep Yjs collaborative editing on its existing channel.
+
+## Query freshness
+
+Prefer `useActionQuery()` for action-backed data. Mutating actions refresh local
+action observers; the chat run stream also invalidates them for agent tool
+side effects. Raw queries should include the relevant source counters:
+
+```tsx
+const versions = useChangeVersions(["dashboards", "action"]);
+useQuery({
+  queryKey: ["dashboard", id, versions],
+  queryFn: () => fetchDashboard(id),
+  placeholderData: (previous) => previous,
+});
+```
+
+That covers local chat-run edits. Remote edits reach the counter through
+`useDbSync()` only on an opted-in page. Use `useReconciledState` when a form or
+inline editor copies a query value into local state so incoming data does not
+replace active typing.
+
+URL commands (`__set_url__`, `set-url`, and `set-search-params`) and
+`refresh-screen` also flow through local chat events. The sidebar listens for
+screen refresh only while its panel is open or a chat run is active; public docs
+can disable that boundary with `screenRefreshEnabled={false}`.
+
+## Source counters
+
+On local tool completion, `useDbSync()` advances the action counter and any
+other raw-query source counters currently observed by the page. Generic tool
+completion events do not identify their data domain, so keep raw-query source
+lists narrow. Remote sync events advance their specific source counters.
+
+| Source | Changed by |
+| --- | --- |
+| `action` | A successful mutating action or local chat-run side-effect completion |
+| `app-state` | Writes to `application_state`, including URL commands |
+| `settings` | Writes to `settings` |
+| `dashboards`, `analyses`, `extensions` | Domain-specific mutations that emit those sources |
+| `collab` | Yjs collaborative document updates |
+| `screen-refresh` | The explicit `refresh-screen` agent tool |
+
+Use `useChangeVersions()` when one query depends on more than one source.
+
+## Avoid
+
+- Do not create manual polling loops or a second `EventSource`.
+- Do not enable background sync for a whole app root when only one private
+  route needs remote updates.
+- Do not assume a successful local action is a reason for a background
+  subscriber; use local mutation invalidation and the chat run stream.
+- Do not blanket-invalidate template queries when a source-versioned query or
+  action-backed query can target the refreshed data.

package/corpus/templates/slides-2/.agents/skills/reliable-mutations/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: reliable-mutations
+description: >-
+  How the agent must perform writes so they actually persist under the hosted
+  foreground run budget and long-running background handoffs. Use whenever you
+  create, update, delete, or batch-write app data — especially "do this for many
+  items" loops, or any task where the user expects N things to end up saved.
+scope: dev
+---
+
+# Reliable Mutations
+
+## Rule
+
+Make a change in **one atomic call** when the action supports it, then **verify
+the persisted end state and report concrete proof** (counts/ids). Never drive a
+multi-step change by looping many small writes, and never report success from a
+tool ✓ alone.
+
+## Why
+
+Hosted foreground agent runs have a short soft budget so they can hand off
+cleanly under synchronous serverless walls. Durable background runs get a much
+longer budget, but they still should not rely on loops of many small writes:
+continuations can retry the same intent and leave partial state if each item is
+committed separately. One atomic call commits or fails as a unit; verification
+turns a hopeful ✓ into a fact.
+
+## How
+
+1. **Prefer a single atomic call.** If an action accepts the whole set (add
+   many, set all, bulk update), pass the full batch in one call so it commits
+   atomically. Check the action surface for a batch/plural form before reaching
+   for a loop.
+2. **Do not loop many small writes under any run budget.** A sequence of N
+   per-item writes can still leave partial or no state when a foreground run
+   hands off, a background run continues, or an upstream provider fails. If no
+   batch action exists, that is a gap in the action layer — add or extend an
+   action that accepts the batch (see the `actions` skill) rather than papering
+   over it with a loop.
+3. **Verify the end state after writing.** Re-read the data (a list/read action,
+   a count query) and confirm the result matches intent — the right number of
+   rows, the expected ids/fields. Do this before you tell the user it worked,
+   and include the relevant verification expectation in the app's `AGENTS.md`.
+4. **Report proof-of-done, not vibes.** State concrete evidence: "saved 12 of 12
+   panels (ids …)" or "updated 5 rows". Do not infer success from the presence
+   of a tool ✓ on an individual call.
+5. **On a time-budget cutoff, fail loud.** If the turn is cut before the change
+   is fully committed and verified, say so explicitly and report what *did*
+   persist (M of N) and what remains. Never round a partial or unverified write
+   up to "done".
+
+## Don't
+
+- Don't loop `for each item: write(item)` for a large set in a single hosted
+  turn.
+- Don't claim completion because every tool call returned ✓ — a ✓ on an aborted
+  chunk does not mean the row was committed.
+- Don't silently shrink the scope ("I added a few of them") and present it as the
+  finished task.
+- Don't try to "fix" this by asking for a longer run timeout — the budget is
+  correct; restructure the write instead.
+
+## Related
+
+- `actions` — define or extend a batch/atomic action when only per-item writes
+  exist.
+- `storing-data` — where app data lives and how reads/writes are scoped.
+- `performance` — avoid query waterfalls when verifying end state.
+- Design doc: `packages/core/docs/design/durable-agent-runs.md` — the real
+  ceiling fix (checkpointed and durable runs); this skill is the agent-facing
+  mitigation that reduces how often the ceiling is hit.

package/corpus/templates/slides-2/.agents/skills/secrets/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: secrets
+description: >-
+  Connect external services and keep app credentials scoped. Use before adding
+  an API key, OAuth connection, provider setup, or server-side request that
+  needs a user's or workspace's credential.
+scope: dev
+---
+
+# Secrets
+
+## Rule
+
+Credentials belong to the user, organization, workspace, or deployment that
+owns them. Reuse the strongest shared connection or credential flow available;
+never copy a value into app code or client-visible state.
+
+## Choose the credential source
+
+1. Check the workspace connection catalog first. If the provider is already
+   connected, request the app grant and resolve its vault-backed credential
+   reference through the workspace-connection API.
+2. For OAuth, use the shared authorization and token flow. Do not store access
+   or refresh tokens as ordinary settings or API-key values.
+3. If the app truly needs its own API key, register it with the shared secrets
+   surface. Do not build a parallel key form or storage table.
+4. Use deployment configuration only for a secret owned by the deployed app,
+   such as a webhook verification secret. LLM inference keys are an app-owned
+   exception: self-hosted apps may use provider keys from deployment env as a
+   shared fallback, while scoped user or organization keys take precedence.
+   Hosted-workspace deployments backed by a shared database must not share
+   those env keys across apps or tenants. This exception does not authorize
+   using env credentials to access user-owned provider data.
+
+## Register an app-local API key
+
+Register the key once so Settings can manage it and the app can describe why it
+is needed. Supported scopes are `user`, `org`, and `workspace`; choose the
+narrowest scope that matches who owns the credential and how the app resolves
+it. Put the registration in a server module imported by a loaded server plugin.
+
+```ts
+import { registerRequiredSecret } from "@agent-native/core/secrets";
+
+registerRequiredSecret({
+  key: "EXAMPLE_SERVICE_API_KEY",
+  label: "Example service API key",
+  description: "Connects this app to the example service.",
+  docsUrl: "https://example.com/api-keys",
+  scope: "user",
+  kind: "api-key",
+  required: true,
+});
+```
+
+Use `kind: "oauth"` for an OAuth-backed connection and set `oauthProvider` and
+`oauthConnectUrl` for the shared Connect flow. Set `required` only when the app
+cannot perform its primary workflow without that connection. A validator may
+check a key before save; never log or include the value in a validation error.
+
+## Resolve credentials on the server
+
+Resolve credentials only inside server-side actions or server helpers, using
+the request's user and organization context. Keep a missing key separate from
+a failed credential-store lookup: ask the user to connect the provider only
+when the credential is absent; make a store failure retryable.
+
+For an app-local key, use `resolveSecretDetailed()` from
+`@agent-native/core/server` in the request context. Check `lookupFailed` before
+checking `value`; do not turn a failed lookup into a setup prompt.
+
+Never read a user's or workspace's API key from `process.env`, or add a raw
+environment fallback to a scoped lookup. Do not put credentials in action
+arguments or results, agent messages or hidden context, application state,
+browser storage, client bundles, logs, or error text. Send them only in the
+provider request that needs them, and redact provider responses before
+returning an error.
+
+## Related skills
+
+- `security` — protect access to app data and external requests.
+- `actions` — expose server-side operations to both the agent and UI.

package/corpus/templates/slides-2/.agents/skills/security/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: security
+description: >-
+  Secure app data, actions, routes, and external input. Use when changing
+  authentication, authorization, database access, uploads, untrusted content,
+  or server-side requests to user-provided URLs.
+scope: dev
+---
+
+# Security
+
+## Rule
+
+Treat each action, route, query, and external request as a trust boundary.
+Validate inputs, check the caller's authority for every row, and fail closed
+when access cannot be established.
+
+## Validate input and queries
+
+- Define action inputs with a Zod `schema`; validate data from forms, URLs,
+  providers, and files before using it.
+- Build database queries with Drizzle. For raw SQL, bind values as parameters;
+  never concatenate user input into SQL text.
+- Keep large uploads and file contents in file storage. Store only their
+  returned ids or URLs in SQL.
+
+## Authorize rows and actions
+
+Choose a table's access model when designing its data:
+
+| Data | Access model |
+| --- | --- |
+| Private user rows | Store `owner_email` and filter every read and write by the current caller. |
+| Organization-wide catalog | Store `org_id` and scope action queries to the active org; gate restricted mutations by org or app role. |
+| Team-shared or individually shareable resources | Use `ownableColumns()`, register the resource type, and check access with the sharing helpers. |
+| Child rows | Check access to the parent before reading or changing children; add any child-specific rules in the action. |
+
+Do not make a team-wide catalog private by adding a per-user owner filter. For
+an organization-owned catalog, `org_id` without `owner_email` is valid: scoped
+database tools expose only the active organization's rows, while app actions
+still need their own org filter and authorization. For resources users can
+share, use these helpers:
+
+- Add `accessFilter(table, sharesTable)` to list and read-many queries.
+- Use `resolveAccess(type, id)` for an optional read by id, or
+  `assertAccess(type, id, role)` before a read or write that requires access.
+- Use an action's `authorize` gate for role-wide restrictions. It decides who
+  may call the operation; it does not replace row-level access checks.
+
+Prefer actions for normal app data. A custom HTTP route is appropriate for
+protocols such as uploads, streaming, webhooks, OAuth callbacks, or public
+unauthenticated resources. An authenticated custom route must establish the
+session/request context and apply the same row-level access checks as an action.
+
+## Handle untrusted content and URLs
+
+- React escapes rendered text. Do not pass untrusted content to
+  `dangerouslySetInnerHTML`, `innerHTML`, `eval`, or `document.write`.
+- Use `ssrfSafeFetch` from `@agent-native/core/extensions/url-safety` for
+  server-side requests to user- or agent-controlled URLs. It checks private
+  network destinations and redirects.
+- Treat provider error bodies and uploaded files as untrusted input. Return a
+  useful, bounded error to the user without exposing internal details.
+
+## Protect credentials and consequential actions
+
+Never put credential values in source, prompts, action arguments or results,
+application state, client bundles, logs, or error messages. Use the shared
+credential flow in the `secrets` skill.
+
+For a genuinely high-consequence outward action, such as sending a message,
+charging a payment method, or publishing publicly, use `needsApproval` to ask
+the user to approve that call. Approval does not grant access: keep the normal
+`authorize` and row-level checks as well.
+
+## Related skills
+
+- `actions` — define validated operations shared by the agent and UI.
+- `secrets` — connect external services and resolve credentials safely.
+- `sharing` — configure access to shareable resources.

package/corpus/templates/slides-2/.agents/skills/self-modifying-code/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: self-modifying-code
+description: >-
+  Tiers, checkpoints, and off-limits paths for an agent editing the app's own
+  source. Use when designing UI for agent editability, deciding whether a file
+  is safe for the agent to change, or when tempted to patch config, `.env`, or
+  an `@agent-native/*` package. Do not load it for ordinary source edits.
+scope: dev
+metadata:
+  internal: true
+---
+
+# Self-Modifying Code
+
+## Rule
+
+The agent can edit the app's own source code — components, routes, styles, scripts. This is a feature, not a bug. Design your app expecting this.
+
+## Why
+
+An agent-native app isn't just an app the agent can _use_ — it's an app the agent can _change_. The agent can fix bugs, add features, adjust styles, and restructure code. This makes the agent a true collaborator, not just an operator.
+
+## Modification Taxonomy
+
+Not all modifications are equal. Use this to decide what level of care is needed:
+
+| Tier          | What                  | Examples                                         | After modifying                   |
+| ------------- | --------------------- | ------------------------------------------------ | --------------------------------- |
+| 1: Data       | Files in `data/`      | JSON state, generated content, markdown          | Nothing — these are routine       |
+| 2: Source     | App code              | Components, routes, styles, scripts              | Run `pnpm typecheck && pnpm lint` |
+| 3: Config     | Project config        | `package.json`, `tsconfig.json`, `vite.config.*` | Ask for explicit approval first   |
+| 4: Off limits | Secrets and framework | `.env`, `@agent-native/*` packages & overrides   | Never modify these                |
+
+Tier 4 includes **all** of the following — not only editing package source:
+
+- Files under `node_modules/@agent-native/*` (core, dispatch, scheduling, …)
+- `pnpm.overrides`, `overrides`, `resolutions`, or `patchedDependencies` that
+  target any `@agent-native/*` package
+- `pnpm patch`, `pnpm patch-commit`, or local package patch artifacts for any
+  dependency
+- Invented "dispatch/core behavior" shims meant to paper over a version skew
+  or failed upgrade
+
+This does not prohibit intentional app-owned UI customization. When public
+props and composition are insufficient, the `customizing-agent-native` skill
+uses `agent-native eject` to transfer the smallest supported unit from the
+installed package into the app. The ejected unit must keep public runtime
+contracts and must not replace Core auth, DB, actions, agent execution, or
+transport behavior. Manual copying is only the fallback described by an unknown
+third-party package's add-style blueprint.
+
+When an older branch needs current packages, use **`agent-native upgrade`**
+(see the `upgrade-agent-native` skill). If upgrade or typecheck fails, fix
+**app** code or stop and ask — do not patch the framework.
+
+## Git Checkpoint Pattern
+
+Before modifying source code (Tier 2+), create a rollback point:
+
+1. Commit or stash current state
+2. Make the edit
+3. Run `pnpm typecheck && pnpm lint`
+4. If verification fails → revert with `git checkout -- <file>`
+5. If verification passes → continue
+
+This ensures the agent can experiment without breaking the app.
+
+## Designing for Agent Editability
+
+Make your app easy for the agent to understand and modify:
+
+**Expose UI state via `data-*` attributes** so the agent knows what's selected:
+
+```ts
+const el = document.documentElement;
+el.dataset.currentView = view;
+el.dataset.selectedId = selectedItem?.id || "";
+```
+
+**Expose richer context via `window.__appState`** for complex state:
+
+```ts
+(window as any).__appState = {
+  selectedId: id,
+  currentLayout: layout,
+  itemCount: items.length,
+};
+```
+
+**Use configuration-driven rendering** — Extract visual decisions (colors, layouts, sizes) into JSON config files in `data/`. The agent can modify the config (Tier 1) instead of the component source (Tier 2).
+
+**Keep localized copy in catalogs** — When editing visible UI copy, labels,
+toasts, empty states, prompts, or formatting, update the English source catalog.
+Read the optional `internationalization` skill and update additional catalogs
+only when `translations.locales` in `agent-native.config.ts` includes them.
+
+## Don't
+
+- Don't modify `.env` files or files containing secrets
+- Don't modify `@agent-native/core`, `@agent-native/dispatch`, or other
+  `@agent-native/*` package internals (including under `node_modules`)
+- Don't confuse readable package source with app-owned code: use
+  `customizing-agent-native` and `agent-native eject` for supported ownership
+  transfer
+- Don't use `pnpm patch` / `pnpm patch-commit`, commit `patches/` artifacts, or
+  add `pnpm.patchedDependencies` to "make the app run" after a version bump
+- Don't add `pnpm.overrides` / `patchedDependencies` / `resolutions` for
+  `@agent-native/*` to paper over a broken upgrade
+- Don't invent local dispatch/core behavior overrides when upgrade fails —
+  run `npx @agent-native/core@latest upgrade`, then fix app-level errors only
+- Don't modify `.agents/skills/` or `AGENTS.md` unless explicitly requested
+- Don't skip the typecheck/lint step after editing source code
+- Don't make source changes without a git checkpoint to roll back to
+
+## Related Skills
+
+- **upgrade-agent-native** — supported path to bring an older app/workspace current
+- **customizing-agent-native** — configure, compose, or eject installed features safely
+- **storing-data** — Tier 1 modifications (data files) are the safest and most common
+- **actions** — The agent can create or modify actions to add new capabilities
+- **delegate-to-agent** — Self-modification requests come through the agent chat
+- **real-time-sync** — Database writes trigger change events to update the UI
+- **internationalization** — UI copy, language catalogs, locale switching, and RTL-safe edits