@inneranimalmedia/agentsam-sdk 2.6.11 → 2.6.12

package/docs/prd/PRD-agentsam-commerce-studio.md

@@ -0,0 +1,180 @@
+# AgentSam Commerce Studio
+## Product Requirements Document
+
+**Status:** Experimental
+**Portfolio:** AgentSam
+**Primary package/app composition:** see Package composition below
+
+## Product vision
+
+A provider-neutral commerce operating workspace for products, inventory, orders, merchandising, media, and AgentSam-assisted operational decisions.
+
+## Target users
+
+- small ecommerce teams
+- merch brands
+- store operators
+- agencies
+
+## Core jobs to be done
+
+- manage catalog and inventory
+- understand orders and customers
+- prepare products/media
+- coordinate merchandising and campaigns
+- act through approved provider adapters
+
+## Product promise
+
+> A provider-neutral commerce operating workspace for products, inventory, orders, merchandising, media, and AgentSam-assisted operational decisions.
+
+## Why this should exist as a real offer
+
+- portable commerce operations
+- AgentSam assistance across catalog/media/analytics
+- provider-neutral domain model
+- fewer disconnected admin tools
+
+The offer is only valuable if users can complete these jobs end to end. Package publication, a demo screen, or an isolated API is not sufficient evidence of product value.
+
+## What this product is not
+
+- a Completeful-only admin
+- Campaign authority
+- a generic ERP
+- silent writes to commerce systems
+
+## Package composition
+
+```text
+apps/ecommerce-cms-agentsam
+cms-runtime
+agentsam-content
+agentsam-merch
+agentsam-analytics
+agentsam-provider-completeful
+```
+
+Packages are implementation ingredients. The product boundary is the user outcome described in this PRD.
+
+## Product principles
+
+1. Prefer user-recognizable operations over infrastructure-shaped APIs.
+2. Preserve provider neutrality unless a provider-specific choice is the user's explicit goal.
+3. Distinguish observed facts, inferred judgments, proposed actions, and executed changes.
+4. Missing evidence reduces confidence instead of creating fabricated facts.
+5. Writes to external systems require clear authorization and bounded scope.
+6. The core workflow should remain usable without unnecessary custom UI.
+7. Local and hosted forms should share domain contracts where practical.
+8. Errors should preserve partial usefulness and explain recovery paths.
+
+## Initial user workflow
+
+```text
+intent
+  |
+  v
+context / evidence
+  |
+  v
+plan or draft
+  |
+  v
+inspect / evaluate
+  |
+  v
+user decision or approval
+  |
+  v
+optional action
+  |
+  v
+receipt / artifact / learning
+```
+
+The exact steps vary by product, but the workflow should remain explicit and inspectable.
+
+## Data and authority
+
+This product must document:
+
+- which records it owns;
+- which external systems remain authoritative;
+- provenance of consumed evidence;
+- freshness/staleness behavior;
+- authorization for writes;
+- how local and hosted state reconcile, where applicable.
+
+No product should silently claim authority over data owned by another domain.
+
+## Distribution
+
+- hosted/admin app
+- packaged client app
+- SDK/runtime
+- future plugin
+
+Distribution may evolve, but every form should preserve the same core product promise.
+
+## Packaging / monetization hypotheses
+
+Potential real-world packaging may include:
+
+- free core package or local capability;
+- paid hosted convenience or managed runtime;
+- paid team/collaboration features;
+- premium packaged application;
+- domain plugin/app distribution;
+- support, implementation, or commercial deployment services;
+- usage-based infrastructure only where the underlying cost scales with usage.
+
+The final commercial model should follow observed adoption and cost structure rather than force every package into a subscription.
+
+## Definition of v1
+
+- products/variants/inventory/orders contracts
+- provider adapter
+- media integration
+- analytics
+- approved write actions
+- webhook/activity receipts
+
+## Acceptance suite
+
+A v1 candidate should pass:
+
+### Direct
+A user explicitly asks for the product's primary job and reaches a useful outcome.
+
+### Indirect
+A user describes the underlying problem without using the product name; the workflow still activates appropriately.
+
+### Sparse context
+The product remains useful with minimal evidence and clearly states limitations.
+
+### Rich context
+Additional authorized evidence materially improves the result.
+
+### Failure
+A provider, source, or action fails and the product returns structured, recoverable behavior where possible.
+
+### Authorization
+A requested write exceeds current authority and is not silently executed.
+
+### Out of scope
+The product refuses or delegates work that belongs to another AgentSam domain instead of absorbing it.
+
+## Success signals
+
+Product quality should be measured by outcomes such as:
+
+- successful completion of the core workflow;
+- lower time/effort to reach the intended outcome;
+- repeat use for the same job;
+- successful recovery from missing data or provider failure;
+- low rate of unauthorized or incorrect actions;
+- evidence that users prefer the integrated offer over manually combining generic tools.
+
+## Graduation rule
+
+This product should not be called v1 until it satisfies `ADR-0005-offer-graduation-standard.md`.

package/docs/prd/PRD-agentsam-content-studio.md

@@ -0,0 +1,179 @@
+# AgentSam Content Studio
+## Product Requirements Document
+
+**Status:** Alpha
+**Portfolio:** AgentSam
+**Primary package/app composition:** see Package composition below
+
+## Product vision
+
+A portable content and media workspace for organizing, preparing, reusing, inspecting, and delivering digital content with provenance and provider-neutral asset lifecycle management.
+
+## Target users
+
+- commerce teams
+- marketing teams
+- site editors
+- creators
+- agencies
+
+## Core jobs to be done
+
+- find and organize media
+- inspect usage and metadata
+- prepare derivatives
+- reuse content across surfaces
+- understand provenance and versions
+- deliver assets without locking the content model to one provider
+
+## Product promise
+
+> A portable content and media workspace for organizing, preparing, reusing, inspecting, and delivering digital content with provenance and provider-neutral asset lifecycle management.
+
+## Why this should exist as a real offer
+
+- reusable media library
+- less duplicate asset work
+- portable provider model
+- clear usage/version provenance
+
+The offer is only valuable if users can complete these jobs end to end. Package publication, a demo screen, or an isolated API is not sufficient evidence of product value.
+
+## What this product is not
+
+- a giant CMS
+- Brand authority
+- a Cloudflare-only image manager
+
+## Package composition
+
+```text
+agentsam-content
+agentsam-content-studio
+agentsam-assets-core
+agentsam-cloudflare-images
+```
+
+Packages are implementation ingredients. The product boundary is the user outcome described in this PRD.
+
+## Product principles
+
+1. Prefer user-recognizable operations over infrastructure-shaped APIs.
+2. Preserve provider neutrality unless a provider-specific choice is the user's explicit goal.
+3. Distinguish observed facts, inferred judgments, proposed actions, and executed changes.
+4. Missing evidence reduces confidence instead of creating fabricated facts.
+5. Writes to external systems require clear authorization and bounded scope.
+6. The core workflow should remain usable without unnecessary custom UI.
+7. Local and hosted forms should share domain contracts where practical.
+8. Errors should preserve partial usefulness and explain recovery paths.
+
+## Initial user workflow
+
+```text
+intent
+  |
+  v
+context / evidence
+  |
+  v
+plan or draft
+  |
+  v
+inspect / evaluate
+  |
+  v
+user decision or approval
+  |
+  v
+optional action
+  |
+  v
+receipt / artifact / learning
+```
+
+The exact steps vary by product, but the workflow should remain explicit and inspectable.
+
+## Data and authority
+
+This product must document:
+
+- which records it owns;
+- which external systems remain authoritative;
+- provenance of consumed evidence;
+- freshness/staleness behavior;
+- authorization for writes;
+- how local and hosted state reconcile, where applicable.
+
+No product should silently claim authority over data owned by another domain.
+
+## Distribution
+
+- React package
+- Local Studio surface
+- commerce/admin integration
+- future plugin
+
+Distribution may evolve, but every form should preserve the same core product promise.
+
+## Packaging / monetization hypotheses
+
+Potential real-world packaging may include:
+
+- free core package or local capability;
+- paid hosted convenience or managed runtime;
+- paid team/collaboration features;
+- premium packaged application;
+- domain plugin/app distribution;
+- support, implementation, or commercial deployment services;
+- usage-based infrastructure only where the underlying cost scales with usage.
+
+The final commercial model should follow observed adoption and cost structure rather than force every package into a subscription.
+
+## Definition of v1
+
+- library + inspector
+- collections
+- usage/provenance
+- prepare-for-delivery flow
+- provider-neutral runtime
+- asset status/version model
+
+## Acceptance suite
+
+A v1 candidate should pass:
+
+### Direct
+A user explicitly asks for the product's primary job and reaches a useful outcome.
+
+### Indirect
+A user describes the underlying problem without using the product name; the workflow still activates appropriately.
+
+### Sparse context
+The product remains useful with minimal evidence and clearly states limitations.
+
+### Rich context
+Additional authorized evidence materially improves the result.
+
+### Failure
+A provider, source, or action fails and the product returns structured, recoverable behavior where possible.
+
+### Authorization
+A requested write exceeds current authority and is not silently executed.
+
+### Out of scope
+The product refuses or delegates work that belongs to another AgentSam domain instead of absorbing it.
+
+## Success signals
+
+Product quality should be measured by outcomes such as:
+
+- successful completion of the core workflow;
+- lower time/effort to reach the intended outcome;
+- repeat use for the same job;
+- successful recovery from missing data or provider failure;
+- low rate of unauthorized or incorrect actions;
+- evidence that users prefer the integrated offer over manually combining generic tools.
+
+## Graduation rule
+
+This product should not be called v1 until it satisfies `ADR-0005-offer-graduation-standard.md`.

package/docs/prd/PRD-agentsam-copro.md

@@ -0,0 +1,39 @@
+# CoPro Studio
+## Product Requirements Document
+
+Status: Experimental
+Portfolio: AgentSam
+
+## Product vision
+
+CoPro is a creator-facing visual production environment for turning media and creative intent into editable timelines, reusable templates, previews, rendered outputs, and finished exports. It should feel like polished mobile-first creative software, not a developer tool.
+
+## Mobile experience
+
+Mobile is first-class. A phone user must be able to import a clip, drag it, trim it, split it, undo, add another clip, preview, and export without opening a terminal.
+
+Required composition:
+
+top bar with title, undo, redo, export
+preview canvas
+transport and current time
+horizontal timeline and playhead
+selected clip with trim handles
+contextual editing tools
+persistent creator tool tray
+
+## Editing requirements
+
+V1 includes select, drag/move, left/right trim, split at playhead, duplicate, delete, multi-track timeline, seeking, zoom, undo/redo, text overlays, volume, speed, transitions, captions, and basic effects.
+
+## Media requirements
+
+Users work with a Media library, not provider consoles. Sources may be device/local, uploads, object storage, streaming providers, drives, or generated assets.
+
+## Render/export requirements
+
+Users choose understandable output settings. The runtime decides how to satisfy the RenderPlan. No normal export path may instruct a creator to boot a terminal or manually choose an execution lane.
+
+## Definition of v1
+
+Stable project serialization/migrations, deterministic command engine, real mobile timeline editing, responsive desktop editor, media library/local adapter, streaming adapter, Remotion adapter, render jobs/cancellation, structured templates, offline persistence, basic text/audio/captions/effects, and full create/import/edit/preview/save/reopen/render/export proof.

package/docs/prd/PRD-agentsam-database-studio.md

@@ -0,0 +1,175 @@
+# AgentSam Database Studio
+## Product Requirements Document
+
+**Status:** Alpha
+**Portfolio:** AgentSam
+**Primary package/app composition:** see Package composition below
+
+## Product vision
+
+A safe, portable database workspace for inspecting, querying, understanding, and editing supported databases with AgentSam assistance and explicit write boundaries.
+
+## Target users
+
+- developers
+- technical operators
+- small teams managing app data
+
+## Core jobs to be done
+
+- inspect schema and records
+- run safe queries
+- understand relationships
+- edit data with review
+- work across local SQLite and hosted database providers
+
+## Product promise
+
+> A safe, portable database workspace for inspecting, querying, understanding, and editing supported databases with AgentSam assistance and explicit write boundaries.
+
+## Why this should exist as a real offer
+
+- faster data understanding
+- portable database UX
+- safer assisted edits
+- less provider-specific tooling
+
+The offer is only valuable if users can complete these jobs end to end. Package publication, a demo screen, or an isolated API is not sufficient evidence of product value.
+
+## What this product is not
+
+- an unrestricted production SQL shell
+- a provider-branded clone
+- a replacement for database authority/security
+
+## Package composition
+
+```text
+agentsam-database-editor
+agentsam-workbench
+agentsam-errors
+agentsam-scoring
+```
+
+Packages are implementation ingredients. The product boundary is the user outcome described in this PRD.
+
+## Product principles
+
+1. Prefer user-recognizable operations over infrastructure-shaped APIs.
+2. Preserve provider neutrality unless a provider-specific choice is the user's explicit goal.
+3. Distinguish observed facts, inferred judgments, proposed actions, and executed changes.
+4. Missing evidence reduces confidence instead of creating fabricated facts.
+5. Writes to external systems require clear authorization and bounded scope.
+6. The core workflow should remain usable without unnecessary custom UI.
+7. Local and hosted forms should share domain contracts where practical.
+8. Errors should preserve partial usefulness and explain recovery paths.
+
+## Initial user workflow
+
+```text
+intent
+  |
+  v
+context / evidence
+  |
+  v
+plan or draft
+  |
+  v
+inspect / evaluate
+  |
+  v
+user decision or approval
+  |
+  v
+optional action
+  |
+  v
+receipt / artifact / learning
+```
+
+The exact steps vary by product, but the workflow should remain explicit and inspectable.
+
+## Data and authority
+
+This product must document:
+
+- which records it owns;
+- which external systems remain authoritative;
+- provenance of consumed evidence;
+- freshness/staleness behavior;
+- authorization for writes;
+- how local and hosted state reconcile, where applicable.
+
+No product should silently claim authority over data owned by another domain.
+
+## Distribution
+
+- Local Studio packaged app
+- SDK package
+- standalone/admin embed
+
+Distribution may evolve, but every form should preserve the same core product promise.
+
+## Packaging / monetization hypotheses
+
+Potential real-world packaging may include:
+
+- free core package or local capability;
+- paid hosted convenience or managed runtime;
+- paid team/collaboration features;
+- premium packaged application;
+- domain plugin/app distribution;
+- support, implementation, or commercial deployment services;
+- usage-based infrastructure only where the underlying cost scales with usage.
+
+The final commercial model should follow observed adoption and cost structure rather than force every package into a subscription.
+
+## Definition of v1
+
+- SQLite/D1/Postgres/Supabase adapters
+- schema browser
+- query/results
+- edit approval
+- receipts/errors
+- portable host contract
+
+## Acceptance suite
+
+A v1 candidate should pass:
+
+### Direct
+A user explicitly asks for the product's primary job and reaches a useful outcome.
+
+### Indirect
+A user describes the underlying problem without using the product name; the workflow still activates appropriately.
+
+### Sparse context
+The product remains useful with minimal evidence and clearly states limitations.
+
+### Rich context
+Additional authorized evidence materially improves the result.
+
+### Failure
+A provider, source, or action fails and the product returns structured, recoverable behavior where possible.
+
+### Authorization
+A requested write exceeds current authority and is not silently executed.
+
+### Out of scope
+The product refuses or delegates work that belongs to another AgentSam domain instead of absorbing it.
+
+## Success signals
+
+Product quality should be measured by outcomes such as:
+
+- successful completion of the core workflow;
+- lower time/effort to reach the intended outcome;
+- repeat use for the same job;
+- successful recovery from missing data or provider failure;
+- low rate of unauthorized or incorrect actions;
+- evidence that users prefer the integrated offer over manually combining generic tools.
+
+## Graduation rule
+
+This product should not be called v1 until it satisfies `ADR-0005-offer-graduation-standard.md`.