@agent-native/core 0.141.6 → 0.141.7

package/dist/templates/chat/app/routes/agent.tsx

@@ -21,20 +21,20 @@ export default function AgentRoute() {
     "learnings",
   ]);
   const destination = resourceTabs.has(legacyTab)
-    ? `/settings#agent:resources:${legacyTab}`
+    ? `/settings/agent/resources/${legacyTab}`
     : legacyTab === "remote-agents"
-      ? "/settings#agent:agents"
+      ? "/settings/agent/agents"
       : legacyTab === "connections"
-        ? "/settings#integrations"
+        ? "/settings/integrations"
         : legacyTab === "jobs"
-          ? "/settings#agent:automations"
+          ? "/settings/agent/automations"
           : legacyTab === "access"
-            ? "/settings#agent:access"
+            ? "/settings/agent"
             : ["llm", "app-models", "limits", "voice", "background"].includes(
                   legacyTab,
                 )
-              ? `/settings#${legacyTab}`
-              : "/settings#agent";
+              ? `/settings/agent/${legacyTab}`
+              : "/settings/agent";
 
   return <Navigate to={destination} replace />;
 }

package/dist/templates/chat/app/routes/extensions._index.tsx

@@ -7,5 +7,5 @@ export function meta() {
 }
 
 export default function ExtensionsRoute() {
-  return <Navigate to="/settings#extensions" replace />;
+  return <Navigate to="/settings/extensions" replace />;
 }

package/dist/templates/chat/app/routes/settings.$.tsx

@@ -0,0 +1 @@
+export { default, meta } from "./settings.js";

package/dist/templates/chat/app/routes/team.tsx

@@ -7,5 +7,5 @@ export function meta() {
 }
 
 export default function TeamRoute() {
-  return <Navigate to="/settings#organization" replace />;
+  return <Navigate to="/settings/organization" replace />;
 }

package/dist/templates/workspace-core/.agents/skills/address-feedback/SKILL.md

@@ -38,7 +38,35 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
 
    Use web browsing only for public URLs. Auth-gated docs usually need their matching connector. For threads, read the parent and all replies; note when there are no replies, and inspect linked files or newer follow-ups when the source refers to them.
 
-2. Decompose and categorize every actionable item.
+2. Check whether this defect has already been reported.
+
+   A feedback channel holds months of reports and nobody remembers all of them,
+   so the same defect gets filed by different people weeks apart and every
+   filing reads as new. One recorded case: the same Clips recording bug was
+   filed almost word-for-word 29 days apart by the same reporter, and neither
+   message mentions the other. Another defect was reported fifteen times by
+   nine people across three months, was announced as fixed once in the middle,
+   and was reported again two weeks later.
+
+   Search before fixing, going back at least three months: the source channel
+   in the reporter's words and in your own, Sentry, and merged PR titles. Search
+   the feature name, the error text, and the surface separately — repeat reports
+   rarely share vocabulary.
+
+   - **No prior report** — proceed normally.
+   - **Prior report, no fix landed** — say how long it has been open. The person
+     forwarding it to you is likely seeing it for the second time too.
+   - **Prior report, fix landed** — this is a regression, and the bar is now
+     different. Patching it again and reporting done is exactly how it returns a
+     third time. Find why the first fix stopped holding, and leave behind
+     something that fails when it breaks again: a test that reproduces the
+     user's path, or an assertion in the flow the report names.
+
+   Report the repeat explicitly, with dates and reporters. A defect on its third
+   report is not a bug ticket, it is a missing check — and the missing check is
+   the deliverable, not the patch.
+
+3. Decompose and categorize every actionable item.
 
    Build a compact checklist before changing code. For each item, record the
    symptom, expected behavior, evidence, and owning surface: UI, action/tool,
@@ -49,7 +77,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - **Question or unclear**: Missing detail, contradictory feedback, or behavior you cannot inspect. Ask or flag it.
    - **Out of scope**: Outside this repo, already shipped, intentionally unsupported, or too low-signal. Note briefly and skip.
 
-3. For data, permissions, or resource-lifecycle feedback, verify the whole capability boundary before calling it UX.
+4. For data, permissions, or resource-lifecycle feedback, verify the whole capability boundary before calling it UX.
 
    - Check the supported create/read/update/delete lifecycle, including whether the backend/action exists when a UI control is missing.
    - Inspect both the UI and the shared action/tool surface so agent and UI behavior stay in parity.
@@ -57,7 +85,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - Treat possible cross-user or cross-organization exposure as a security/correctness bug and verify it before proposing polish.
    - Keep undefined product policy separate from implementation bugs. If supported source types or scope semantics are not defined, flag the contract question instead of inventing behavior.
 
-4. Check Sentry when the feedback smells like an error.
+5. Check Sentry when the feedback smells like an error.
 
    - Use the Sentry skill/plugin if available, or the repo's Sentry scripts if documented.
    - Search by route, stack symbol, error text, and symptom keywords.
@@ -65,7 +93,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - Cite issue IDs or links when you find a match.
    - If nothing matches, say that plainly.
 
-5. Fix only the clear bugs you agree with.
+6. Fix only the clear bugs you agree with.
 
    - Verify before fixing: reproduce locally, read the relevant code, inspect logs, or confirm with a stack trace.
    - Keep each fix narrow and mapped to a feedback item.
@@ -73,7 +101,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - Do not switch branches, stash, reset, force-push, or open a PR unless the user asks.
    - Add or update focused tests when the bug risk warrants it.
 
-6. Treat UX feedback with restraint.
+7. Treat UX feedback with restraint.
 
    Do not solve UX problems by adding more visible controls, helper text, banners, top-level nav, or always-open panels by default. Prefer cleaner interaction models:
 
@@ -85,7 +113,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
 
    When proposing a UX change, write it as: what to change, why it helps, and the tradeoff. Keep each proposal short.
 
-7. Verify changed behavior.
+8. Verify changed behavior.
 
    - Run the smallest relevant test or typecheck command.
    - For UI fixes, inspect the actual screen with a browser tool you already
@@ -100,6 +128,9 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
 Keep the final report short:
 
 ```md
+## Repeat Reports
+- [defect] - reported [N] times since [date] by [reporters]; [what now fails if it regresses]
+
 ## Bugs Fixed
 - [feedback item] - [what changed, file:line]
 

package/dist/templates/workspace-core/.agents/skills/authentication/SKILL.md

@@ -204,7 +204,7 @@ For public pages (share links, embeds, marketing pages) that need anonymous view
 ```ts
 const ret = window.location.pathname + window.location.search;
 window.location.href =
-  "/_agent-native/sign-in?return=" + encodeURIComponent(ret);
+  "/sign-in?return=" + encodeURIComponent(ret);
 ```
 
 After successful sign-in (token / email-password / Google OAuth), the framework redirects to `return`. The path is validated as same-origin via the URL parser — open-redirect / header-injection inputs fall back to `/`.
@@ -230,7 +230,9 @@ will be rejected.
 
 `AppProviders` applies `RequireSession` automatically on its private branch. It
 resolves the session on the client and redirects signed-out visitors to
-`/_agent-native/sign-in?return=…` before mounting the routed shell:
+`/sign-in?return=…` before mounting the routed shell. The legacy
+`/_agent-native/sign-in` path remains supported for older generated apps and
+bookmarks:
 
 ```tsx
 import { AppProviders } from "@agent-native/core/client/hooks";

package/docs/content/authentication.mdx

@@ -384,7 +384,7 @@ function MyComponent() {
 Templates with **public pages** (share links, embeds, marketing pages) often need an in-page CTA that asks anonymous viewers to sign in and brings them back to the page they were on. The framework provides a single entry point for this:
 
 ```
-/_agent-native/sign-in?return=<same-origin-path>
+/sign-in?return=<same-origin-path>
 ```
 
 When an anonymous viewer hits this URL, the framework's login page is served. After a successful sign-in (magic link, email/password, token, or Google OAuth), the browser returns to `return`.
@@ -399,8 +399,7 @@ import { Button } from "@/components/ui/button";
 function SignInCta() {
   const onClick = () => {
     const ret = window.location.pathname + window.location.search;
-    window.location.href =
-      "/_agent-native/sign-in?return=" + encodeURIComponent(ret);
+    window.location.href = "/sign-in?return=" + encodeURIComponent(ret);
   };
   return <Button onClick={onClick}>Sign in</Button>;
 }
@@ -408,13 +407,13 @@ function SignInCta() {
 
 ### Bookmarked private paths
 
-Normal app pages use one impersonal, public-cacheable SSR shell for every visitor. `AppProviders` checks the session on the client; on a private path such as `/dashboard`, it redirects an anonymous visitor to `/_agent-native/sign-in?return=%2Fdashboard` before mounting private app UI. After sign-in, the visitor returns to `/dashboard`. Pass `isPublicPath` for public/SEO routes, or `sessionBypass` for a surface that authenticates through another scoped mechanism such as an MCP embed token.
+Normal app pages use one impersonal, public-cacheable SSR shell for every visitor. `AppProviders` checks the session on the client; on a private path such as `/dashboard`, it redirects an anonymous visitor to `/sign-in?return=%2Fdashboard` before mounting private app UI. After sign-in, the visitor returns to `/dashboard`. Pass `isPublicPath` for public/SEO routes, or `sessionBypass` for a surface that authenticates through another scoped mechanism such as an MCP embed token.
 
 How long that shell is cached is a deployment-wide setting — see [SSR Caching](/docs/deployment#ssr-caching) for `AGENT_NATIVE_SSR_CACHE`. Shortening or disabling the cache changes duration only; SSR still renders the anonymous branch with cookies stripped.
 
 ### Behind the scenes: Google OAuth
 
-Both flows (the explicit `/_agent-native/sign-in` entrypoint and the bookmarked-path case) thread the return URL through the OAuth state. The state is HMAC-signed, so it can't be forged in transit. On the callback, the return URL is re-validated as same-origin before the redirect — so a leaked signing key still can't be turned into an open-redirect oracle.
+Both flows (the explicit `/sign-in` entrypoint and the bookmarked-path case) thread the return URL through the OAuth state. The legacy `/_agent-native/sign-in` alias remains accepted for older links. The state is HMAC-signed, so it can't be forged in transit. On the callback, the return URL is re-validated as same-origin before the redirect — so a leaked signing key still can't be turned into an open-redirect oracle.
 
 If your template wraps `/_agent-native/google/auth-url` directly (e.g. mail and calendar templates do, to widen scopes), accept a `?return=<path>` query and forward it via the options-object form of `encodeOAuthState`:
 

package/docs/content/template-analytics-developers.mdx

@@ -158,7 +158,7 @@ Plus the org tables (`organizations`, `org_members`, `org_invitations`) from `@a
 
 Every operation is a TypeScript file in `templates/analytics/actions/`, auto-mounted at `POST /_agent-native/actions/:name`.
 
-**Dashboards & panels** — `update-dashboard` (new/full-config saves), `mutate-dashboard` (existing-dashboard edits via a small typed script API), `compose-dashboard` (build a large first-party dashboard from a metric-key catalog in one atomic call), `get-sql-dashboard`, `list-sql-dashboards`, `archive-dashboard`, `delete-sql-dashboard` / `delete-explorer-dashboard`, `reorder-dashboard-panels`, `install-dashboard-template` / `list-dashboard-templates`.
+**Dashboards & panels** — `update-dashboard` (new/full-config saves), `mutate-dashboard` (existing-dashboard edits via a small typed script API), `compose-dashboard` (build a large first-party dashboard from a metric-key catalog in one atomic call), `get-sql-dashboard`, `list-sql-dashboards`, `archive-dashboard`, `delete-sql-dashboard` / `delete-explorer-dashboard`, and `reorder-dashboard-panels`.
 
 **Analyses** — `save-analysis`, `get-analysis`, `list-analyses`, `rename-analysis`, `hide-analysis`, `list-analysis-revisions` / `restore-analysis-revision`.
 

package/docs/content/template-calendar-developers.mdx

@@ -340,7 +340,7 @@ Availability rules live in per-user settings under the `calendar-availability` k
   ]}
 />
 
-Two legacy routes stay mounted for links shared before a URL scheme changed: `book.$slug.tsx` (no username segment) and `meet.$username.$slug.tsx`, both of which canonicalize to `/book/:username/:slug`. `_app.team.tsx` redirects to `/settings#organization` — team management lives in Settings, not a separate page.
+Two legacy routes stay mounted for links shared before a URL scheme changed: `book.$slug.tsx` (no username segment) and `meet.$username.$slug.tsx`, both of which canonicalize to `/book/:username/:slug`. `_app.team.tsx` redirects to `/settings/organization` — team management lives in Settings, not a separate page.
 
 ## Customizing it
 

package/docs/content/template-chat-developers.mdx

@@ -51,7 +51,7 @@ Three routes are mounted whether or not your app ever links to them:
     ],
     [
       "/extensions",
-      "redirects to /settings#extensions",
+      "redirects to /settings/extensions",
       "Extensions are managed from Settings, not a standalone list page",
     ],
     [
@@ -66,7 +66,7 @@ Three routes are mounted whether or not your app ever links to them:
     ],
     [
       "/team",
-      "redirects to /settings#organization",
+      "redirects to /settings/organization",
       "Organization membership lives under Settings",
     ],
   ]}

package/docs/content/template-content-developers.mdx

@@ -304,7 +304,7 @@ Every operation is a TypeScript file in `templates/content/actions/`, auto-mount
 | `_app.favorites.tsx`                                                                                               | Redirects into the current space's Favorites Files-database document                                                                                         |
 | `_app.local-files.tsx`                                                                                             | `/local-files` — connect, pull, check, and push local folders                                                                                                |
 | `_app.settings.tsx`                                                                                                | Settings                                                                                                                                                     |
-| `_app.team.tsx`                                                                                                    | `/team` redirects to `/settings#organization`                                                                                                                |
+| `_app.team.tsx`                                                                                                    | `/team` redirects to `/settings/organization`                                                                                                                |
 | `_app.agent.tsx`                                                                                                   | `/agent` — the full agent chat tab page                                                                                                                      |
 | `_app.extensions.tsx` + `_app.extensions._index.tsx` + `_app.extensions.$id.tsx` + `_app.extensions.$id.$slug.tsx` | `/extensions` — sandboxed widget routes (the framework's Alpine.js extension system; unrelated to the Tiptap "editor extensions" used elsewhere in this doc) |
 | `p.$id.tsx`                                                                                                        | `/p/:id` — public, read-only document view with a read-only agent chat                                                                                       |

package/docs/content/template-mail-developers.mdx

@@ -323,7 +323,7 @@ Emails flowing through the API have the shape `{ id, threadId, from, to, cc, sub
 - `/draft-queue` and `/draft-queue/:id` — the draft queue list and detail view
 - `/settings` — account connections, tracking, automations, aliases, Slack intake
 - `/team` — redirects to `/settings?section=team`
-- `/extensions` — installed extension widgets (redirects to `/settings#extensions` when no extension id is given)
+- `/extensions` — installed extension widgets (redirects to `/settings/extensions` when no extension id is given)
 
 ## Customizing it
 

package/docs/content/template-plan-developers.mdx

@@ -676,7 +676,7 @@ pnpm --filter plan test -- plan-mdx plan-block-registry
 />
 
 `app/routes/extensions.tsx` and `app/routes/team.tsx` are thin redirects to
-`/settings#extensions` and `/settings#organization` — Plan installs the same
+`/settings/extensions` and `/settings/organization` — Plan installs the same
 framework-wide [Extensions](/docs/extensions) mini-app system and organization
 management every other template gets, rather than a Plan-specific system.
 Extensions are sandboxed Alpine.js mini-apps a user installs at runtime from

package/docs/content/toolkit-command-navigation.mdx

@@ -88,12 +88,12 @@ export const resolveOpenPath = createStandardOpenPathResolver({
 
 Use a small predictable route set:
 
-| Route                       | Purpose                                                                    |
-| --------------------------- | -------------------------------------------------------------------------- |
-| `/`                         | Primary app surface.                                                       |
-| `/settings`                 | Standard settings tabs.                                                    |
-| `/team` or `/settings#team` | Team management.                                                           |
-| Resource routes             | `/documents/:id`, `/dashboards/:id`, or equivalent focused resource pages. |
+| Route                               | Purpose                                                                    |
+| ----------------------------------- | -------------------------------------------------------------------------- |
+| `/`                                 | Primary app surface.                                                       |
+| `/settings`                         | Standard settings tabs.                                                    |
+| `/team` or `/settings/organization` | Team management.                                                           |
+| Resource routes                     | `/documents/:id`, `/dashboards/:id`, or equivalent focused resource pages. |
 
 ## UX Standard {#ux-standard}
 

package/docs/content/toolkit-org-team.mdx

@@ -40,7 +40,7 @@ connections, service tokens, and app switching.
 ## API {#api}
 
 Render organization context wherever data scope changes. Put `OrgSwitcher` in
-the persistent shell and make `/settings#team` or `/team` open `TeamPage`.
+the persistent shell and make `/settings/organization` or `/team` open `TeamPage`.
 
 ```tsx
 import {

package/docs/content/toolkit-settings.mdx

@@ -27,14 +27,14 @@ free the moment an app adopts the shared page.
 
 ## Pieces {#pieces}
 
-| Piece                    | Purpose                                                                               |
-| ------------------------ | ------------------------------------------------------------------------------------- |
-| `<SettingsTabsPage>`     | Standard tabbed settings route surface with a built-in settings search box.           |
-| `useAgentSettingsTabs()` | Framework-provided agent, model, key, automation, and voice tabs that apps can mount. |
-| `SettingsSearchEntry`    | A deep-link target (label, keywords, tab, and hash) that makes a control findable.    |
-| `<LanguagePicker>`       | Standard language selector for app settings.                                          |
-| `openAgentSettings()`    | Compatibility escape hatch for opening the sidebar settings tab when needed.          |
-| Hash deep links          | Stable links such as `/settings#secrets:OPENAI_API_KEY` and `/settings#connections`.  |
+| Piece                    | Purpose                                                                                            |
+| ------------------------ | -------------------------------------------------------------------------------------------------- |
+| `<SettingsTabsPage>`     | Standard tabbed settings route surface with a built-in settings search box.                        |
+| `useAgentSettingsTabs()` | Framework-provided agent, model, key, automation, and voice tabs that apps can mount.              |
+| `SettingsSearchEntry`    | A deep-link target (label, keywords, tab, and hash) that makes a control findable.                 |
+| `<LanguagePicker>`       | Standard language selector for app settings.                                                       |
+| `openAgentSettings()`    | Compatibility escape hatch for opening the sidebar settings tab when needed.                       |
+| Deep links               | Stable links such as `/settings/integrations/secrets/OPENAI_API_KEY` and `/settings/integrations`. |
 
 ## Page Contract {#page-contract}
 

package/docs/content/toolkit-setup-connections.mdx

@@ -73,7 +73,7 @@ registerOnboardingStep({
       kind: "link",
       label: "Open settings",
       primary: true,
-      payload: { url: "/settings#secrets" },
+      payload: { url: "/settings/integrations#secrets" },
     },
   ],
   isComplete: async () => hasOpenAIKey(),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.141.6",
+  "version": "0.141.7",
   "description": "Framework for agent-native application development — where AI agents and UI share SQL state, actions, and context",
   "homepage": "https://github.com/BuilderIO/agent-native#readme",
   "bugs": {

package/src/templates/chat/app/components/layout/Layout.tsx

@@ -172,7 +172,7 @@ export function Layout({ children }: LayoutProps) {
             openOnChatRunning={chatHomeHandoffActive}
             onFullscreenRequest={openAskAgentFullscreen}
             emptyStateText={t("chat.inspectEmptyState")}
-            agentPageHref="/settings#agent"
+            agentPageHref="/settings/agent"
             suggestions={[
               t("chat.inspectSuggestionCapabilities"),
               t("chat.inspectSuggestionHello"),

package/src/templates/chat/app/hooks/use-navigation-state.ts

@@ -64,7 +64,7 @@ function pathForView(view?: string): string {
     case "settings":
       return "/settings";
     case "team":
-      return "/settings#organization";
+      return "/settings/organization";
     default:
       return "/";
   }

package/src/templates/chat/app/root.tsx

@@ -133,7 +133,7 @@ function AppContent() {
             {t("root.commandSearch")}
           </CommandMenu.Item>
           <CommandMenu.Item
-            onSelect={() => navigate("/settings#agent")}
+            onSelect={() => navigate("/settings/agent")}
             keywords={[
               "agent",
               "context",

package/src/templates/chat/app/routes/agent.tsx

@@ -21,20 +21,20 @@ export default function AgentRoute() {
     "learnings",
   ]);
   const destination = resourceTabs.has(legacyTab)
-    ? `/settings#agent:resources:${legacyTab}`
+    ? `/settings/agent/resources/${legacyTab}`
     : legacyTab === "remote-agents"
-      ? "/settings#agent:agents"
+      ? "/settings/agent/agents"
       : legacyTab === "connections"
-        ? "/settings#integrations"
+        ? "/settings/integrations"
         : legacyTab === "jobs"
-          ? "/settings#agent:automations"
+          ? "/settings/agent/automations"
           : legacyTab === "access"
-            ? "/settings#agent:access"
+            ? "/settings/agent"
             : ["llm", "app-models", "limits", "voice", "background"].includes(
                   legacyTab,
                 )
-              ? `/settings#${legacyTab}`
-              : "/settings#agent";
+              ? `/settings/agent/${legacyTab}`
+              : "/settings/agent";
 
   return <Navigate to={destination} replace />;
 }

package/src/templates/chat/app/routes/extensions._index.tsx

@@ -7,5 +7,5 @@ export function meta() {
 }
 
 export default function ExtensionsRoute() {
-  return <Navigate to="/settings#extensions" replace />;
+  return <Navigate to="/settings/extensions" replace />;
 }

package/src/templates/chat/app/routes/settings.$.tsx

@@ -0,0 +1 @@
+export { default, meta } from "./settings.js";

package/src/templates/chat/app/routes/team.tsx

@@ -7,5 +7,5 @@ export function meta() {
 }
 
 export default function TeamRoute() {
-  return <Navigate to="/settings#organization" replace />;
+  return <Navigate to="/settings/organization" replace />;
 }

package/src/templates/workspace-core/.agents/skills/address-feedback/SKILL.md

@@ -38,7 +38,35 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
 
    Use web browsing only for public URLs. Auth-gated docs usually need their matching connector. For threads, read the parent and all replies; note when there are no replies, and inspect linked files or newer follow-ups when the source refers to them.
 
-2. Decompose and categorize every actionable item.
+2. Check whether this defect has already been reported.
+
+   A feedback channel holds months of reports and nobody remembers all of them,
+   so the same defect gets filed by different people weeks apart and every
+   filing reads as new. One recorded case: the same Clips recording bug was
+   filed almost word-for-word 29 days apart by the same reporter, and neither
+   message mentions the other. Another defect was reported fifteen times by
+   nine people across three months, was announced as fixed once in the middle,
+   and was reported again two weeks later.
+
+   Search before fixing, going back at least three months: the source channel
+   in the reporter's words and in your own, Sentry, and merged PR titles. Search
+   the feature name, the error text, and the surface separately — repeat reports
+   rarely share vocabulary.
+
+   - **No prior report** — proceed normally.
+   - **Prior report, no fix landed** — say how long it has been open. The person
+     forwarding it to you is likely seeing it for the second time too.
+   - **Prior report, fix landed** — this is a regression, and the bar is now
+     different. Patching it again and reporting done is exactly how it returns a
+     third time. Find why the first fix stopped holding, and leave behind
+     something that fails when it breaks again: a test that reproduces the
+     user's path, or an assertion in the flow the report names.
+
+   Report the repeat explicitly, with dates and reporters. A defect on its third
+   report is not a bug ticket, it is a missing check — and the missing check is
+   the deliverable, not the patch.
+
+3. Decompose and categorize every actionable item.
 
    Build a compact checklist before changing code. For each item, record the
    symptom, expected behavior, evidence, and owning surface: UI, action/tool,
@@ -49,7 +77,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - **Question or unclear**: Missing detail, contradictory feedback, or behavior you cannot inspect. Ask or flag it.
    - **Out of scope**: Outside this repo, already shipped, intentionally unsupported, or too low-signal. Note briefly and skip.
 
-3. For data, permissions, or resource-lifecycle feedback, verify the whole capability boundary before calling it UX.
+4. For data, permissions, or resource-lifecycle feedback, verify the whole capability boundary before calling it UX.
 
    - Check the supported create/read/update/delete lifecycle, including whether the backend/action exists when a UI control is missing.
    - Inspect both the UI and the shared action/tool surface so agent and UI behavior stay in parity.
@@ -57,7 +85,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - Treat possible cross-user or cross-organization exposure as a security/correctness bug and verify it before proposing polish.
    - Keep undefined product policy separate from implementation bugs. If supported source types or scope semantics are not defined, flag the contract question instead of inventing behavior.
 
-4. Check Sentry when the feedback smells like an error.
+5. Check Sentry when the feedback smells like an error.
 
    - Use the Sentry skill/plugin if available, or the repo's Sentry scripts if documented.
    - Search by route, stack symbol, error text, and symptom keywords.
@@ -65,7 +93,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - Cite issue IDs or links when you find a match.
    - If nothing matches, say that plainly.
 
-5. Fix only the clear bugs you agree with.
+6. Fix only the clear bugs you agree with.
 
    - Verify before fixing: reproduce locally, read the relevant code, inspect logs, or confirm with a stack trace.
    - Keep each fix narrow and mapped to a feedback item.
@@ -73,7 +101,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - Do not switch branches, stash, reset, force-push, or open a PR unless the user asks.
    - Add or update focused tests when the bug risk warrants it.
 
-6. Treat UX feedback with restraint.
+7. Treat UX feedback with restraint.
 
    Do not solve UX problems by adding more visible controls, helper text, banners, top-level nav, or always-open panels by default. Prefer cleaner interaction models:
 
@@ -85,7 +113,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
 
    When proposing a UX change, write it as: what to change, why it helps, and the tradeoff. Keep each proposal short.
 
-7. Verify changed behavior.
+8. Verify changed behavior.
 
    - Run the smallest relevant test or typecheck command.
    - For UI fixes, inspect the actual screen with a browser tool you already
@@ -100,6 +128,9 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
 Keep the final report short:
 
 ```md
+## Repeat Reports
+- [defect] - reported [N] times since [date] by [reporters]; [what now fails if it regresses]
+
 ## Bugs Fixed
 - [feedback item] - [what changed, file:line]
 

package/src/templates/workspace-core/.agents/skills/authentication/SKILL.md

@@ -204,7 +204,7 @@ For public pages (share links, embeds, marketing pages) that need anonymous view
 ```ts
 const ret = window.location.pathname + window.location.search;
 window.location.href =
-  "/_agent-native/sign-in?return=" + encodeURIComponent(ret);
+  "/sign-in?return=" + encodeURIComponent(ret);
 ```
 
 After successful sign-in (token / email-password / Google OAuth), the framework redirects to `return`. The path is validated as same-origin via the URL parser — open-redirect / header-injection inputs fall back to `/`.
@@ -230,7 +230,9 @@ will be rejected.
 
 `AppProviders` applies `RequireSession` automatically on its private branch. It
 resolves the session on the client and redirects signed-out visitors to
-`/_agent-native/sign-in?return=…` before mounting the routed shell:
+`/sign-in?return=…` before mounting the routed shell. The legacy
+`/_agent-native/sign-in` path remains supported for older generated apps and
+bookmarks:
 
 ```tsx
 import { AppProviders } from "@agent-native/core/client/hooks";

package/corpus/templates/analytics/.agents/skills/dashboard-management/references/template-catalog-and-demo.md

@@ -1,62 +0,0 @@
-# Template Catalog And Demo Dashboards
-
-## Listing And Installing Templates
-
-- `list-dashboard-templates` lists source-controlled dashboard templates with
-  `id`, category, data sources, panel count, and installed dashboard IDs.
-- `install-dashboard-template` installs a catalog template into normal
-  SQL-backed dashboards. Required: `templateId`. Optional: `dashboardId`,
-  `name`, `overwrite`, `forceNew`, and `mergePanels` (see "Reliable Bulk
-  Edits" in the main skill for the `mergePanels` append behavior).
-
-## Canonical Agent Native Dashboard
-
-Keep the canonical Agent Native dashboard (`agent-native-templates-first-party`)
-focused: it includes one explicit feedback-sentiment-by-model chart and one
-optional inferred-message-sentiment chart, not the broader LLM cost, token,
-latency, or error suite.
-
-- Explicit feedback uses content-free `$ai_feedback` events with `sentiment`
-  (`positive` or `negative`) and model in `$ai_model` or `model`.
-- Inferred sentiment uses `$ai_sentiment` events with `method = 'llm'` and
-  `sentiment` (`positive`, `neutral`, or `negative`).
-
-Keep these panels in the canonical dashboard and do not recreate a separately
-installable observability template.
-
-## Node Exporter Templates
-
-Node Exporter ships as `node-exporter-macos` (Darwin/Homebrew `node_exporter`
-scrapes) and `node-exporter-full` (the Linux-focused Grafana 1860 revision 45
-dashboard converted into native Analytics panels, plus Prometheus
-Observability Demo app metrics — `demo_http_*`, `demo_chaos_mode`, synthetic
-CPU/disk/memory workload metrics). See the `prometheus` skill for the full
-panel/field breakdown and local Homebrew setup.
-
-Keep the first-open `App / Overview` tab light: it should show the Request
-Latency highlight plus current app state, while Traffic, Latency, and
-Workload details stay split across their own `App / *` tabs.
-
-## Demo Dashboard
-
-- `ensure-demo-dashboards` installs one private per-user demo on first app
-  open: `demo-node-exporter`. The Analytics root route calls this before
-  honoring local last-opened state; when the action creates the demo, the
-  user should land directly on the Node Exporter demo's `App / Overview` tab
-  without visiting the template catalog or data-source setup.
-- The demo dashboard is generated from the same `node-exporter-full` seed as
-  the catalog template. Its Prometheus panels keep the same PromQL
-  descriptors and use `source: "demo"` so queries route to the demo
-  Prometheus endpoint instead of the user's `PROMETHEUS_*` credential slot.
-- The demo Prometheus endpoint defaults to the public read-only
-  `https://prometheus.agent-native.foo`, so cloud and local MPX installs work
-  without user setup. Deployments can override it with
-  `ANALYTICS_DEMO_PROMETHEUS_URL` and optional
-  `ANALYTICS_DEMO_PROMETHEUS_USERNAME`, `ANALYTICS_DEMO_PROMETHEUS_PASSWORD`,
-  or `ANALYTICS_DEMO_PROMETHEUS_BEARER_TOKEN`. Do not put credential values
-  in source, docs, fixtures, tests, prompts, or dashboard seeds.
-- Demo dashboards are ordinary SQL dashboard rows, so rename, share, archive,
-  and delete flows apply. Deleted demo IDs are tombstoned in SQL settings and
-  are not recreated unless the user explicitly asks to reset demos.
-- Use `ensure-demo-dashboards --reset=true` only when the user asks to
-  restore a deleted or changed demo dashboard.