@agent-native/core 0.49.23 → 0.49.25

package/dist/templates/default/.agents/skills/actions/SKILL.md

@@ -104,7 +104,9 @@ Do not build an umbrella REST API to make actions "easier" to call. Actions are
 
 For provider integrations used in ad hoc analysis, querying, reporting, or
 cross-source research, do not hardcode every provider endpoint as a separate
-rigid action. Expose the shared provider API action trio instead:
+rigid action and do not encode one lookback window, filter shape, or pagination
+strategy as the only path the agent can take. Expose the shared provider API
+action trio instead:
 
 - `provider-api-catalog`: lists provider base URLs, auth style, credential keys,
   docs/spec URLs, placeholders, and examples without exposing secrets.
@@ -117,11 +119,25 @@ rigid action. Expose the shared provider API action trio instead:
 
 Use `@agent-native/core/provider-api` as the shared substrate. A template should
 only add a thin credential adapter when it has app-specific credential lookup
-rules. Keep `provider-api-request` `http: false` unless you have a separate UI
-permission model for arbitrary provider writes. Specific actions such as
-`hubspot-deals`, `search-emails`, or `sync-source` are convenience shortcuts,
-not capability limits; agents should fall back to the provider API trio when a
-question requires an endpoint or filter that the shortcut does not model.
+rules. If the app stores a built-in provider's OAuth grant under a narrower
+local provider id, use the runtime's `oauthProviderOverrides` instead of
+duplicating the provider config. If credentials are stored on shareable/resource
+rows rather than in the shared credential or OAuth-token stores, build a resolver
+that enforces those access checks before exposing raw provider requests. Keep
+`provider-api-request` `http: false` unless you have a separate UI permission
+model for arbitrary provider writes. Specific actions such as `hubspot-deals`,
+`search-emails`, or `sync-source` are convenience shortcuts, not capability
+limits; agents should fall back to the provider API trio when a question
+requires an endpoint or filter that the shortcut does not model.
+
+This is a framework tenet. The safety boundary should be provider host
+allow-listing, credential scoping, auth injection, private-network blocking,
+secret redaction, and user/org access checks, not an artificially small set of
+hand-authored read actions. If the upstream provider API supports a capability,
+the agent should normally be able to reach it through `provider-api-request`
+with the user's configured credentials. For large responses, expose staging
+(`stageAs`, `itemsPath`, pagination, and `query-staged-dataset`) or sandboxed
+code execution so the agent can reduce data without flooding context.
 
 ### The `http` Option
 

package/dist/templates/default/.agents/skills/adding-a-feature/SKILL.md

@@ -59,7 +59,13 @@ For provider-backed analysis/query/reporting integrations, do not turn every
 provider endpoint or filter into a rigid action. Prefer the shared
 `provider-api-catalog` / `provider-api-docs` / `provider-api-request` pattern
 from `@agent-native/core/provider-api`, then add narrow convenience actions only
-for workflows that truly deserve a first-class shortcut.
+for workflows that truly deserve a first-class shortcut. Treat this as a
+capability requirement, not a nice-to-have: convenience actions must not become
+the ceiling of what the agent can ask the provider to do. Pair broad provider
+access with staging or sandboxed code execution when responses may be too large
+for chat context. If provider credentials live on resource/share rows, add the
+scoped resolver first so broad access preserves the same ownership boundary as
+the app UI.
 
 If the feature needs credentials, design the credential path in the same change.
 Never hardcode API keys, tokens, webhook URLs, signing secrets, private

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

@@ -104,7 +104,9 @@ Do not build an umbrella REST API to make actions "easier" to call. Actions are
 
 For provider integrations used in ad hoc analysis, querying, reporting, or
 cross-source research, do not hardcode every provider endpoint as a separate
-rigid action. Expose the shared provider API action trio instead:
+rigid action and do not encode one lookback window, filter shape, or pagination
+strategy as the only path the agent can take. Expose the shared provider API
+action trio instead:
 
 - `provider-api-catalog`: lists provider base URLs, auth style, credential keys,
   docs/spec URLs, placeholders, and examples without exposing secrets.
@@ -117,11 +119,25 @@ rigid action. Expose the shared provider API action trio instead:
 
 Use `@agent-native/core/provider-api` as the shared substrate. A template should
 only add a thin credential adapter when it has app-specific credential lookup
-rules. Keep `provider-api-request` `http: false` unless you have a separate UI
-permission model for arbitrary provider writes. Specific actions such as
-`hubspot-deals`, `search-emails`, or `sync-source` are convenience shortcuts,
-not capability limits; agents should fall back to the provider API trio when a
-question requires an endpoint or filter that the shortcut does not model.
+rules. If the app stores a built-in provider's OAuth grant under a narrower
+local provider id, use the runtime's `oauthProviderOverrides` instead of
+duplicating the provider config. If credentials are stored on shareable/resource
+rows rather than in the shared credential or OAuth-token stores, build a resolver
+that enforces those access checks before exposing raw provider requests. Keep
+`provider-api-request` `http: false` unless you have a separate UI permission
+model for arbitrary provider writes. Specific actions such as `hubspot-deals`,
+`search-emails`, or `sync-source` are convenience shortcuts, not capability
+limits; agents should fall back to the provider API trio when a question
+requires an endpoint or filter that the shortcut does not model.
+
+This is a framework tenet. The safety boundary should be provider host
+allow-listing, credential scoping, auth injection, private-network blocking,
+secret redaction, and user/org access checks, not an artificially small set of
+hand-authored read actions. If the upstream provider API supports a capability,
+the agent should normally be able to reach it through `provider-api-request`
+with the user's configured credentials. For large responses, expose staging
+(`stageAs`, `itemsPath`, pagination, and `query-staged-dataset`) or sandboxed
+code execution so the agent can reduce data without flooding context.
 
 ### The `http` Option
 

package/dist/templates/workspace-core/.agents/skills/adding-a-feature/SKILL.md

@@ -59,7 +59,13 @@ For provider-backed analysis/query/reporting integrations, do not turn every
 provider endpoint or filter into a rigid action. Prefer the shared
 `provider-api-catalog` / `provider-api-docs` / `provider-api-request` pattern
 from `@agent-native/core/provider-api`, then add narrow convenience actions only
-for workflows that truly deserve a first-class shortcut.
+for workflows that truly deserve a first-class shortcut. Treat this as a
+capability requirement, not a nice-to-have: convenience actions must not become
+the ceiling of what the agent can ask the provider to do. Pair broad provider
+access with staging or sandboxed code execution when responses may be too large
+for chat context. If provider credentials live on resource/share rows, add the
+scoped resolver first so broad access preserves the same ownership boundary as
+the app UI.
 
 If the feature needs credentials, design the credential path in the same change.
 Never hardcode API keys, tokens, webhook URLs, signing secrets, private

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.49.23",
+  "version": "0.49.25",
   "type": "module",
   "engines": {
     "node": ">=22"

package/src/templates/default/.agents/skills/actions/SKILL.md

@@ -104,7 +104,9 @@ Do not build an umbrella REST API to make actions "easier" to call. Actions are
 
 For provider integrations used in ad hoc analysis, querying, reporting, or
 cross-source research, do not hardcode every provider endpoint as a separate
-rigid action. Expose the shared provider API action trio instead:
+rigid action and do not encode one lookback window, filter shape, or pagination
+strategy as the only path the agent can take. Expose the shared provider API
+action trio instead:
 
 - `provider-api-catalog`: lists provider base URLs, auth style, credential keys,
   docs/spec URLs, placeholders, and examples without exposing secrets.
@@ -117,11 +119,25 @@ rigid action. Expose the shared provider API action trio instead:
 
 Use `@agent-native/core/provider-api` as the shared substrate. A template should
 only add a thin credential adapter when it has app-specific credential lookup
-rules. Keep `provider-api-request` `http: false` unless you have a separate UI
-permission model for arbitrary provider writes. Specific actions such as
-`hubspot-deals`, `search-emails`, or `sync-source` are convenience shortcuts,
-not capability limits; agents should fall back to the provider API trio when a
-question requires an endpoint or filter that the shortcut does not model.
+rules. If the app stores a built-in provider's OAuth grant under a narrower
+local provider id, use the runtime's `oauthProviderOverrides` instead of
+duplicating the provider config. If credentials are stored on shareable/resource
+rows rather than in the shared credential or OAuth-token stores, build a resolver
+that enforces those access checks before exposing raw provider requests. Keep
+`provider-api-request` `http: false` unless you have a separate UI permission
+model for arbitrary provider writes. Specific actions such as `hubspot-deals`,
+`search-emails`, or `sync-source` are convenience shortcuts, not capability
+limits; agents should fall back to the provider API trio when a question
+requires an endpoint or filter that the shortcut does not model.
+
+This is a framework tenet. The safety boundary should be provider host
+allow-listing, credential scoping, auth injection, private-network blocking,
+secret redaction, and user/org access checks, not an artificially small set of
+hand-authored read actions. If the upstream provider API supports a capability,
+the agent should normally be able to reach it through `provider-api-request`
+with the user's configured credentials. For large responses, expose staging
+(`stageAs`, `itemsPath`, pagination, and `query-staged-dataset`) or sandboxed
+code execution so the agent can reduce data without flooding context.
 
 ### The `http` Option
 

package/src/templates/default/.agents/skills/adding-a-feature/SKILL.md

@@ -59,7 +59,13 @@ For provider-backed analysis/query/reporting integrations, do not turn every
 provider endpoint or filter into a rigid action. Prefer the shared
 `provider-api-catalog` / `provider-api-docs` / `provider-api-request` pattern
 from `@agent-native/core/provider-api`, then add narrow convenience actions only
-for workflows that truly deserve a first-class shortcut.
+for workflows that truly deserve a first-class shortcut. Treat this as a
+capability requirement, not a nice-to-have: convenience actions must not become
+the ceiling of what the agent can ask the provider to do. Pair broad provider
+access with staging or sandboxed code execution when responses may be too large
+for chat context. If provider credentials live on resource/share rows, add the
+scoped resolver first so broad access preserves the same ownership boundary as
+the app UI.
 
 If the feature needs credentials, design the credential path in the same change.
 Never hardcode API keys, tokens, webhook URLs, signing secrets, private

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

@@ -104,7 +104,9 @@ Do not build an umbrella REST API to make actions "easier" to call. Actions are
 
 For provider integrations used in ad hoc analysis, querying, reporting, or
 cross-source research, do not hardcode every provider endpoint as a separate
-rigid action. Expose the shared provider API action trio instead:
+rigid action and do not encode one lookback window, filter shape, or pagination
+strategy as the only path the agent can take. Expose the shared provider API
+action trio instead:
 
 - `provider-api-catalog`: lists provider base URLs, auth style, credential keys,
   docs/spec URLs, placeholders, and examples without exposing secrets.
@@ -117,11 +119,25 @@ rigid action. Expose the shared provider API action trio instead:
 
 Use `@agent-native/core/provider-api` as the shared substrate. A template should
 only add a thin credential adapter when it has app-specific credential lookup
-rules. Keep `provider-api-request` `http: false` unless you have a separate UI
-permission model for arbitrary provider writes. Specific actions such as
-`hubspot-deals`, `search-emails`, or `sync-source` are convenience shortcuts,
-not capability limits; agents should fall back to the provider API trio when a
-question requires an endpoint or filter that the shortcut does not model.
+rules. If the app stores a built-in provider's OAuth grant under a narrower
+local provider id, use the runtime's `oauthProviderOverrides` instead of
+duplicating the provider config. If credentials are stored on shareable/resource
+rows rather than in the shared credential or OAuth-token stores, build a resolver
+that enforces those access checks before exposing raw provider requests. Keep
+`provider-api-request` `http: false` unless you have a separate UI permission
+model for arbitrary provider writes. Specific actions such as `hubspot-deals`,
+`search-emails`, or `sync-source` are convenience shortcuts, not capability
+limits; agents should fall back to the provider API trio when a question
+requires an endpoint or filter that the shortcut does not model.
+
+This is a framework tenet. The safety boundary should be provider host
+allow-listing, credential scoping, auth injection, private-network blocking,
+secret redaction, and user/org access checks, not an artificially small set of
+hand-authored read actions. If the upstream provider API supports a capability,
+the agent should normally be able to reach it through `provider-api-request`
+with the user's configured credentials. For large responses, expose staging
+(`stageAs`, `itemsPath`, pagination, and `query-staged-dataset`) or sandboxed
+code execution so the agent can reduce data without flooding context.
 
 ### The `http` Option
 

package/src/templates/workspace-core/.agents/skills/adding-a-feature/SKILL.md

@@ -59,7 +59,13 @@ For provider-backed analysis/query/reporting integrations, do not turn every
 provider endpoint or filter into a rigid action. Prefer the shared
 `provider-api-catalog` / `provider-api-docs` / `provider-api-request` pattern
 from `@agent-native/core/provider-api`, then add narrow convenience actions only
-for workflows that truly deserve a first-class shortcut.
+for workflows that truly deserve a first-class shortcut. Treat this as a
+capability requirement, not a nice-to-have: convenience actions must not become
+the ceiling of what the agent can ask the provider to do. Pair broad provider
+access with staging or sandboxed code execution when responses may be too large
+for chat context. If provider credentials live on resource/share rows, add the
+scoped resolver first so broad access preserves the same ownership boundary as
+the app UI.
 
 If the feature needs credentials, design the credential path in the same change.
 Never hardcode API keys, tokens, webhook URLs, signing secrets, private