howone 0.1.23 → 0.1.26

package/templates/vite/.howone/skills/howone/04-ai/06-ai-feature-playbooks.md

@@ -0,0 +1,296 @@
+# AI Feature Playbooks
+
+Use this reference when turning a user request into concrete HowOne AI capabilities, database
+entities, and SDK calls.
+
+## Playbook: Document Summary
+
+Use when user uploads or links a document and wants a summary.
+
+Capability:
+
+```json
+{
+  "name": "summarizeDocument",
+  "description": "Reads an uploaded document and produces a concise summary highlighting the key points.",
+  "inputSchema": {
+    "type": "object",
+    "properties": {
+      "document_url": {
+        "type": "string",
+        "format": "uri",
+        "description": "Supabase Storage URL of the uploaded document."
+      },
+      "summary_length": {
+        "type": "string",
+        "description": "Desired summary length, e.g. short, medium, long, or a specific sentence count."
+      }
+    },
+    "required": ["document_url"]
+  },
+  "outputSchema": {
+    "type": "object",
+    "properties": {
+      "summary": {
+        "type": "string",
+        "description": "Summary in the same language as the source document."
+      }
+    },
+    "required": ["summary"]
+  },
+  "outputEntityName": "DocumentSummary"
+}
+```
+
+Persistence:
+
+- private `DocumentSummary` if user history is needed;
+- fields: `documentUrl`, `summary`, `status`, `errorMessage`, `requestedAt`, `completedAt`.
+
+SDK:
+
+```ts
+const output = await howone.ai.summarizeDocument.run({ document_url: fileUrl })
+```
+
+## Playbook: Image Generator
+
+Use for prompt-to-image products.
+
+Capability:
+
+```json
+{
+  "name": "generateImage",
+  "description": "Generates an image based on a natural language description provided by the user.",
+  "inputSchema": {
+    "type": "object",
+    "properties": {
+      "image_description": {
+        "type": "string",
+        "description": "Detailed description of the image to generate, including subject, style, mood, and composition."
+      },
+      "style_preference": {
+        "type": "string",
+        "description": "Optional style preference such as watercolor, photorealistic, anime, or flat design."
+      }
+    },
+    "required": ["image_description"]
+  },
+  "outputSchema": {
+    "type": "object",
+    "properties": {
+      "generated_image_url": {
+        "type": "string",
+        "format": "uri",
+        "description": "Public URL of the generated image."
+      }
+    },
+    "required": ["generated_image_url"]
+  },
+  "outputEntityName": "GeneratedImage"
+}
+```
+
+Persistence:
+
+- use `Generation` for private history;
+- public share requires separate `SharedGeneration`.
+
+SDK:
+
+```ts
+await runAiActionAndPersist({
+  entity: howone.entities.Generation,
+  input: { image_description, style_preference },
+  createPending: (input) => ({
+    prompt: input.image_description,
+    style: input.style_preference ?? null,
+    status: 'pending',
+    requestedAt: new Date().toISOString(),
+  }),
+  run: (input) => howone.ai.generateImage.run(input),
+  mapCompleted: ({ output }) => ({
+    status: 'completed',
+    resultUrl: output.generated_image_url,
+    completedAt: new Date().toISOString(),
+  }),
+})
+```
+
+## Playbook: Image Editor
+
+Use when user uploads/selects an image and describes edits.
+
+Inputs:
+
+- `source_image_url`;
+- `edit_instruction`.
+
+Output:
+
+- `edited_image_url`.
+
+Rules:
+
+- app uploads source file first;
+- workflow receives URL only;
+- keep edit instruction focused;
+- persist both original and edited URLs if history matters.
+
+## Playbook: News/Research Briefing
+
+Use for latest info or source-backed research.
+
+Inputs:
+
+- `topic`;
+- optional `language`;
+- optional `depth` as loose string, not strict enum unless UI really has fixed modes.
+
+Output:
+
+- structured `briefing` object with `summary` and `sources`.
+
+Rules:
+
+- use web search/crawling capability;
+- include source URLs;
+- output descriptions must specify language;
+- if user asks for latest/current, this workflow must retrieve data internally.
+
+## Playbook: Stock Analysis
+
+Use for historical price analysis.
+
+Inputs:
+
+- `trading_symbol`;
+- `start`;
+- `end`;
+- `unit`: daily/minute when UI exposes it.
+
+Output:
+
+- `analysis`;
+- optional `price_history` only if app renders chart from workflow output.
+
+Rules:
+
+- do not ask user for CSV unless they explicitly have data;
+- historical only, no real-time streaming;
+- combine with web search only if user asks for news/context.
+
+## Playbook: Academic Literature Review
+
+Use for paper search and bibliography.
+
+Inputs:
+
+- `query`;
+- optional `language` for synthesized review;
+- optional `citation_style`.
+
+Outputs:
+
+- `papers`;
+- `review_summary`;
+- `bibtex` if citations are needed.
+
+Rules:
+
+- do not promise full PDF availability;
+- keep paper metadata fields useful and minimal;
+- use source URLs/DOIs when returned.
+
+## Playbook: Audio Transcription
+
+Use for speech-to-text.
+
+Inputs:
+
+- `source_audio_url`;
+- optional `language`;
+- optional `with_speaker_info`.
+
+Outputs:
+
+- `transcript_text`;
+- optional `utterances`.
+
+Rules:
+
+- app uploads audio first;
+- workflow receives URL;
+- if speaker diarization is not required, do not add utterances.
+
+## Playbook: Text To Speech
+
+Use for generating spoken audio from text.
+
+Inputs:
+
+- `text_to_generate`;
+- `language`;
+- optional `gender`;
+- optional `audio_hint`.
+
+Output:
+
+- `audio_url`.
+
+Rules:
+
+- single speaker per call;
+- dialogue should generate multiple clips and merge;
+- persist audio URL through entity if user needs library/history.
+
+## Playbook: Video Generator
+
+Use for short video creation.
+
+Inputs:
+
+- `video_prompt`;
+- optional `first_frame_url`;
+- optional `aspect_ratio`;
+- optional `duration`.
+
+Output:
+
+- `video_url`.
+
+Rules:
+
+- keep one clip short;
+- for longer output, compose multiple clips and concatenate;
+- first-frame image helps consistency.
+
+## RAG Playbook
+
+Use only when app needs question answering over user/project documents.
+
+Workflows:
+
+1. `indexDocuments`
+   - input: document URLs or collection reference;
+   - output: indexing result/status.
+2. `queryKnowledgeBase`
+   - input: question + knowledge base reference;
+   - output: answer + sources.
+
+Rules:
+
+- RAG is the only standard two-workflow exception.
+- Do not re-index on every question.
+- Persist document/index status in entities if app needs history or dashboard.
+
+## Feature Design Checklist
+
+- Choose one playbook or clearly combine compatible playbooks.
+- Verify capability exists in `04-service-capability-catalog.md`.
+- Use URL inputs for files/media.
+- Keep outputs minimal and product-facing.
+- Decide persistence separately.
+- Generate SDK bindings only after manifest sync.
+- Use app-owned UI for progress/errors.

package/templates/vite/.howone/skills/{howone-sdk → howone}/SKILL.md

@@ -18,9 +18,9 @@ that app code must follow.
 | Track | Folder | Use For |
 |---|---|---|
 | `01-architect/` | App generation + manifest flow | End-to-end HowOne app generation flow: when to design backend, when to sync manifests, when to update SDK bindings, and how to choose auth/data posture. |
-| `02-database/` | Backend schema + data access design | Entity schema contract, schema operations, access modes, owner/public data posture, indexes, versions, and guardrails. |
+| `02-database/` | Backend schema + data access design | Entity schema contract, schema operations, access modes, owner/public data posture, indexes, query DSL, AI output persistence, versions, and guardrails. |
 | `03-sdk/` | Frontend SDK usage | `src/lib/sdk.ts`, auth, React provider, entity calls, public data, uploads, raw HTTP, AI action calls. |
-| `04-ai/` | AI capability + workflow design | HowOne AI capability contracts, external workflow create/update submission, workflow schema rules, persistence boundaries, and SDK handoff. |
+| `04-ai/` | AI capability + workflow design | HowOne AI capability contracts, service capability selection, workflow create/update/status, schema rules, playbooks, persistence boundaries, and SDK handoff. |
 
 ## Routing
 
@@ -32,14 +32,17 @@ Read references by task shape. Prefer exact references over generic examples.
 - Any feature touching AI generation, AI workflow behavior, or AI outputs: read the AI references
   first, then the SDK handoff/action-call references.
 - AI capability, AI workflow generation/editing, or full-stack AI feature planning: read
-  `04-ai/01-ai-capability-architecture.md` and `04-ai/02-workflow-contract-rules.md`.
+  `04-ai/01-ai-capability-architecture.md`, `04-ai/04-service-capability-catalog.md`, and
+  `04-ai/02-workflow-contract-rules.md`.
 - Backend database/schema creation or change: read `02-database/01-schema-design.md` and
   `02-database/02-schema-operations.md`.
-- AI output persistence: read the `04-ai/` files first, then `02-database/01-schema-design.md`.
+- AI output persistence, generation history, retry/resume, or saved AI results: read the `04-ai/`
+  files first, then `02-database/05-ai-persistence-patterns.md` and
+  `02-database/01-schema-design.md`.
 - After schema sync, when app code must call the entity: read
   `01-architect/02-manifest-codegen.md` and `03-sdk/02-entity-operations.md`.
-- Custom login page, Email OTP, Phone OTP, Google, GitHub, token persistence, repeated login,
-  or missing token: read `03-sdk/03-auth.md` and `03-sdk/04-react-integration.md`.
+- Custom login page (your UI, HowOne APIs): `auth: 'custom'` in `createClient` (see `03-sdk/03-auth.md`),
+  `HowOneProvider auth="none"` and keep the default bottom-right HowOne logo unless explicitly hidden. Default without `auth` = hosted HowOne login.
 - `src/lib/sdk.ts`, `createClient`, env vars, or generated bindings: read
   `03-sdk/01-client-setup.md` and `01-architect/02-manifest-codegen.md`.
 - Public landing pages or share URLs: read `02-database/03-data-access-patterns.md`,
@@ -48,6 +51,8 @@ Read references by task shape. Prefer exact references over generic examples.
 - Raw HTTP escape hatch: read `03-sdk/06-raw-http.md`.
 - App-side AI action calls after `.howone/ai/manifest.json` exists: read
   `03-sdk/07-ai-action-calls.md`.
+- External workflow create/update/status: read `04-ai/05-workflow-operations.md`.
+- Common AI feature templates: read `04-ai/06-ai-feature-playbooks.md`.
 
 ## Reference Selection Protocol
 
@@ -60,11 +65,16 @@ Before writing code, classify the touched surfaces:
 | Existing synced manifest to TypeScript bindings | `01-architect/02-manifest-codegen.md` |
 | UI reads/writes entities | `03-sdk/01-client-setup.md`, `03-sdk/02-entity-operations.md` |
 | Public read/share flow | `02-database/03-data-access-patterns.md`, `03-sdk/02-entity-operations.md` |
+| Query filters/sort/pagination/response mapping | `02-database/04-query-dsl-and-responses.md` |
+| AI output persistence / generation history | `02-database/05-ai-persistence-patterns.md`, `04-ai/01-ai-capability-architecture.md` |
 | Auth/session/login behavior | `03-sdk/03-auth.md`, `03-sdk/04-react-integration.md` |
-| AI capability or workflow design | `04-ai/01-ai-capability-architecture.md`, `04-ai/02-workflow-contract-rules.md` |
+| AI capability or workflow design | `04-ai/01-ai-capability-architecture.md`, `04-ai/04-service-capability-catalog.md`, `04-ai/02-workflow-contract-rules.md` |
+| External workflow create/update/status | `04-ai/05-workflow-operations.md` |
+| Common AI feature examples | `04-ai/06-ai-feature-playbooks.md` |
 | AI manifest handoff to app code | `04-ai/03-ai-sdk-handoff.md`, `03-sdk/07-ai-action-calls.md` |
 | File upload | `03-sdk/05-file-upload.md` |
 | Raw HTTP escape hatch | `03-sdk/06-raw-http.md` |
+| SDK extensibility / adapter boundaries | `03-sdk/08-extension-boundaries.md` |
 
 If a task spans multiple surfaces, read one reference from each surface before editing. Do not
 invent API parameters, response shapes, owner fields, workflow IDs, or output paths from memory.
@@ -93,8 +103,8 @@ For app features that touch AI:
 6. Read `.howone/ai/manifest.json`.
 7. Generate or update app SDK bindings from the manifest.
 8. Implement frontend calls using `howone.ai.*`.
-9. If outputs are saved, derive entity fields from the AI `outputSchema`, then follow the database
-   workflow.
+9. If outputs are saved, map only durable product fields from the AI result into an entity schema,
+   then follow the database workflow.
 
 For frontend-only SDK work:
 
@@ -107,7 +117,8 @@ For frontend-only SDK work:
 
 - Generate SDK bindings from synced manifests, not from memory.
 - Keep `.howone/` as manifest storage only; do not write generated source files there.
-- Configure `projectId` and `env` only in `createClient`.
+- Configure `projectId` and `env` only in `createClient`. Auth APIs follow the same `env` (dev → `api.howone.dev`, not `api.howone.ai`).
+- Import `src/lib/sdk.ts` before any `@howone/sdk` auth call so environment is pinned.
 - Use `import.meta.env.VITE_HOWONE_PROJECT_ID` and `import.meta.env.VITE_HOWONE_ENV`; do not
   hardcode project IDs or add fallback env values.
 - For private user-owned data, authenticated APIs derive owner from JWT. Do not pass
@@ -115,8 +126,14 @@ For frontend-only SDK work:
 - For `access.authenticated.read = "own"`, prefer `howone.entities.Entity.query.mine(...)`.
 - Public pages use `howone.public.entities.*` only when manifest access explicitly allows public
   reads or writes.
-- For custom in-app login, use `HowOneProvider auth="none"`, call
-  `howone.auth.setToken(token)` on success, and verify startup session with `await howone.me()`.
+- Default `createClient({ projectId, env })` uses **HowOne hosted login**. For a custom `/login` UI
+  that still calls HowOne OTP/OAuth APIs, add `auth: 'custom'` and `HowOneProvider auth="none"`.
+- `HowOneProvider` may render the bottom-right HowOne `FloatingButton` logo by default. Do not remove
+  it unless the user explicitly asks for `brand="hidden"` or `showBrandButton={false}`.
+- Do not add SDK-owned toast APIs, redirect overlays, or app-specific UI. Expose data, state, events,
+  and callbacks; implement visible feedback in the generated frontend app.
+- SDK extensibility rule: default behavior must work without configuration, and custom behavior must
+  enter through typed adapters/callbacks instead of hardcoded app UI or provider-specific branches.
 - AI workflows are implementation, not persistence. Never put CRUD, auth, upload handling, or app
   state management into the workflow capability contract.
 - For external workflow edits, pass `workflowConfigID` from a confirmed workflow status result; do

package/templates/vite/.howone/skills/howone/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "HowOne App Architecture"
+  short_description: "Design HowOne database schemas, AI workflows, SDK bindings, auth, and app integration."
+  default_prompt: "Use this skill to choose the right HowOne architecture track, then implement database schema, AI capability/workflow, SDK bindings, auth, or frontend SDK calls from synced manifests."

package/templates/vite/package.json

@@ -14,7 +14,7 @@
   "dependencies": {
     "@base-ui/react": "^1.4.1",
     "@fontsource-variable/inter": "^5.2.8",
-    "@howone/sdk": "2.0.0-beta.17",
+    "@howone/sdk": "2.0.0-beta.19",
     "@tailwindcss/vite": "^4.2.1",
     "class-variance-authority": "^0.7.1",
     "clsx": "^2.1.1",

package/templates/vite/.howone/skills/howone-sdk/01-architect/01-app-generation.md

@@ -1,126 +0,0 @@
-# App Generation Architect
-
-Use this file to decide the HowOne app implementation path before reading low-level SDK or
-database references.
-
-## Responsibility Split
-
-HowOne generated apps have three layers:
-
-1. **Backend contract**: dynamic entities, access rules, indexes, schema versions, and synced
-   manifests.
-2. **AI contract + workflow implementation**: AI capability contracts are versioned by HowOne;
-   external workflow create/update is submitted from synced AI manifests.
-3. **SDK binding**: `src/lib/sdk.ts` converts manifests into typed entity and AI clients.
-4. **Frontend experience**: React/UI code calls the SDK and owns app-specific interaction design.
-
-Do not skip the binding layer. The UI should call `src/lib/sdk.ts`, not raw entity names guessed
-from the user prompt.
-
-Core source-of-truth rule from the HowOne docs:
-
-```text
-agent proposal != source of truth
-validated backend manifest = source of truth
-generated files = compiler/binding output
-```
-
-The agent proposes structured changes and writes app code. The runtime/schema tools validate,
-apply, version, and sync manifest facts.
-
-## Choose Data Posture First
-
-Before designing schema or UI calls, classify the data:
-
-| Posture | Backend Access | Frontend Read |
-|---|---|---|
-| Private user data | `authenticated: own`, `public: none` | `howone.entities.Entity.query.mine(...)` |
-| Authenticated shared app data | `authenticated: all`, `public: none` | `howone.entities.Entity.query(...)` |
-| Public list data | `authenticated: all`, `public: list` | `howone.public.entities.Entity.query(...)` |
-| Public scoped share data | usually `authenticated: own`, `public: scoped` | `howone.public.entities.Entity.queryScoped(...)` |
-
-If the user says "my todos", "my notes", "per user", "login required", or "data isolation",
-default to private user data.
-
-## Backend Feature Workflow
-
-When a request adds persistence or changes data shape:
-
-1. Read `02-database/01-schema-design.md` and `02-database/02-schema-operations.md`.
-2. Inspect the current schema/manifest.
-3. Design one complete schema patch for the feature.
-4. Preview the schema patch.
-5. Apply the exact previewed operations if risk is acceptable.
-6. Sync schema artifacts using the returned `next.versionId`.
-7. Read `.howone/database/manifest.json`.
-8. Read `01-architect/02-manifest-codegen.md`.
-9. Update `src/lib/sdk.ts`.
-10. Read the needed SDK file, usually `03-sdk/02-entity-operations.md` and sometimes `03-sdk/03-auth.md`.
-11. Update the UI.
-12. Validate.
-
-Do not preview a patch and then execute different single operations. Related schema changes for
-one feature should be grouped into one preview/apply cycle.
-
-## AI Feature Workflow
-
-When a request adds an AI capability or changes an AI workflow:
-
-1. Read `04-ai/01-ai-capability-architecture.md` and
-   `04-ai/02-workflow-contract-rules.md`.
-2. Inspect current AI capability state.
-3. Design one complete AI capability patch for the feature.
-4. Preview the AI patch.
-5. Apply the exact previewed operations.
-6. Sync AI artifacts.
-7. Read `.howone/ai/manifest.json`.
-8. Submit external workflow create/update with `external-ai-capability`.
-9. Preserve returned request IDs for the status/background-task layer.
-10. Read `04-ai/03-ai-sdk-handoff.md`, `01-architect/02-manifest-codegen.md`, and
-    `03-sdk/07-ai-action-calls.md`.
-11. Update `src/lib/sdk.ts` from the synced manifest.
-12. Update the UI.
-13. Validate.
-
-If generated output must be saved, design the AI capability first. Then derive persistence entities
-from the synced AI `outputSchema`, plus only necessary request metadata.
-
-## Auth Decision
-
-Use hosted auth when the app just needs login:
-
-```tsx
-<HowOneProvider auth="required">
-  <App />
-</HowOneProvider>
-```
-
-Use custom in-app auth when the user asks for a designed login page or multiple login methods:
-
-```tsx
-<HowOneProvider auth="none" brand="hidden">
-  <App />
-</HowOneProvider>
-```
-
-Custom login must call `howone.auth.setToken(token)` after Email OTP, Phone OTP, Google, or
-GitHub succeeds, then verify the session with `await howone.me({ refresh: true })`.
-
-## Generated Binding Rules
-
-- Read manifests after sync, not before.
-- Preserve existing bindings unless the manifest changed.
-- Export explicit `Record`, `Create`, and `Update` types.
-- Do not include system fields in create/update payloads.
-- Do not infer public access from `visibility` alone; inspect `access.public`.
-
-## Common Failure Modes
-
-- Repeated login after refresh: app used `auth.isAuthenticated()` as first-load truth or stored
-  token outside SDK. Read `03-sdk/03-auth.md`.
-- Data is not isolated: app used `query()` instead of `query.mine()` for `authenticated.read =
-  "own"`, or wrote owner fields manually.
-- Public page 401/403: app used authenticated namespace for public content or schema does not
-  allow public access.
-- Generated types drift from backend: app edited `src/lib/sdk.ts` from memory instead of synced
-  manifest.

package/templates/vite/.howone/skills/howone-sdk/02-database/01-schema-design.md

@@ -1,147 +0,0 @@
-# Database Architecture Design
-
-Use this reference when designing or changing HowOne backend entity schemas. It summarizes
-the contract in `docs/dynamic-entity-architecture.zh.md` for app-building agents.
-
-This reference is for **backend entity design**. For schema tool flow, read
-`02-database/02-schema-operations.md`. For frontend read/write calls, read
-`02-database/03-data-access-patterns.md` and `03-sdk/02-entity-operations.md` after schema
-artifacts have been synced.
-
-## Core Model
-
-An entity is a versioned database contract, not a loose JSON form. Design all relevant parts:
-
-```ts
-type EntityContract = {
-  name: string
-  type: 'object'
-  description?: string
-  visibility: 'private' | 'public'
-  properties: Record<string, EntityField>
-  required?: string[]
-  access: {
-    authenticated?: AuthenticatedAccess
-    public?: PublicAccess
-  }
-  indexes?: EntityIndex[]
-  relations?: Record<string, EntityRelation>
-  presentation?: EntityPresentation
-  lifecycle?: EntityLifecycle
-  performance?: EntityPerformance
-}
-```
-
-Every schema change should preserve this mental split:
-
-- `properties` and `required` define payload validation.
-- `access` defines who can read/write and how ownership is derived.
-- `indexes` and `performance` define expected query paths.
-- `relations` defines valid `include` names.
-- `presentation` helps admin UI and SDK generation.
-- schema versions track the contract applied when future records are written.
-
-## Access Contract
-
-Every entity should explicitly define both authenticated and public access. Choose the data posture
-in `02-database/03-data-access-patterns.md`, then encode it in the `access` block here.
-
-## Field Design Rules
-
-- Entity and field names must match `^[a-zA-Z_][a-zA-Z0-9_]*$`.
-- Do not define system fields as business fields: `id`, `_id`, `created_date`, `updated_date`,
-  `created_by_id`, `schema_version_id`, `schema_version_number`, `is_sample`.
-- Required fields must be supplied on create unless the field has `default`, `defaultValue`, or
-  `autoGenerate`.
-- Use explicit enum fields for UI status values instead of free-form strings when choices are known.
-- Use ISO strings for date/datetime fields at the SDK boundary.
-- Complex JSON Schema validation may need frontend validation too; do not assume every nested
-  constraint is fully enforced by backend runtime.
-
-## Index and Performance Rules
-
-Add indexes for the query paths the UI will actually use:
-
-```json
-{
-  "indexes": [
-    {
-      "name": "owner_status_updated",
-      "fields": ["status", "updatedDate"],
-      "scope": "owner",
-      "order": { "updatedDate": "desc" }
-    }
-  ],
-  "performance": {
-    "defaultLimit": 20,
-    "maxLimit": 100,
-    "allowedSorts": ["createdDate", "updatedDate"]
-  }
-}
-```
-
-Guidelines:
-
-- Private user lists usually need owner-scoped indexes.
-- Public list pages need `access.public.allowedFilters` and `access.public.allowedSorts`.
-- `performance.allowedSorts` informs SDK/admin generation; public sort enforcement comes from
-  `access.public.allowedSorts`.
-
-## Todo Example
-
-For a personal Todo app:
-
-```json
-{
-  "name": "Todo",
-  "type": "object",
-  "description": "User-owned todo item",
-  "visibility": "private",
-  "properties": {
-    "text": { "type": "string" },
-    "completed": { "type": "boolean", "default": false }
-  },
-  "required": ["text"],
-  "access": {
-    "authenticated": {
-      "read": "own",
-      "create": "own",
-      "update": "own",
-      "delete": "own"
-    },
-    "public": {
-      "read": "none",
-      "create": "none",
-      "update": "none",
-      "delete": "none"
-    }
-  },
-  "indexes": [
-    {
-      "name": "owner_updated",
-      "fields": ["updatedDate"],
-      "scope": "owner",
-      "order": { "updatedDate": "desc" }
-    }
-  ],
-  "performance": {
-    "defaultLimit": 50,
-    "maxLimit": 100,
-    "allowedSorts": ["createdDate", "updatedDate"]
-  },
-  "presentation": {
-    "titleField": "text",
-    "defaultSort": { "field": "updatedDate", "order": "desc" },
-    "listFields": ["text", "completed", "updatedDate"]
-  }
-}
-```
-
-Corresponding frontend read:
-
-```ts
-const result = await howone.entities.Todo.query.mine({
-  page: { number: 1, size: 50 },
-  orderBy: { updatedDate: 'desc' },
-})
-```