ข้ามไปยังเนื้อหา
Dee Wan 1.0 ยังอยู่ระหว่างพัฒนาและยังไม่เปิดตัว (pre-MVP) — ดู ขอบเขตผลิตภัณฑ์ 1.0

โครงสร้างคำขอและกฎการเข้าถึง

หน้าอ้างอิงก่อนเปิดตัวนี้มีให้บริการเป็นภาษาอังกฤษในขณะนี้


This page describes the query-configuration direction for standalone backends. It is a pre-release contract and design reference, not proof that the current Dee Wan build already emits every feature below.

Dee Wan will configure guarded API access from concrete Prisma query templates. The user edits the query that a page or route needs. Dee Wan derives the prisma-guard shape from that accepted query.

The user does not edit generated guard JSON. Generated policy is a build artifact.

The saved-query workspace with the nested query builder and Prisma query preview

The query editor keeps the nested Prisma structure:

  • select and include fields
  • nested relations
  • where operators
  • ordering
  • pagination
  • create, update and delete data
  • named query usage.

The saved query is a declaration of an allowed request shape. A literal entered while building a query is a sample or default. It is not automatically a forced security value.

Queries are stored per model and operation. A query also has a stable usage key.

model → operation → usage/variant → query template

Examples of usage keys:

company-dashboard
public-profile
talent-search
assignment-autocomplete

Two pages may use the same query only when that reuse is explicit. Two pages that use the same model and operation may still need different projections, filters, ordering, pagination or mutation data. They must have separate query variants.

Dee Wan does not union all queries for a model. A union would grant fields and operators from one page to another.

Each saved query has, at minimum:

  • a stable ID
  • a model and operation
  • a human name
  • a stable usage/variant key
  • the Prisma query payload
  • an accepted/enabled state
  • a schema revision or identity for stale-query detection.

Validation rejects duplicate or ambiguous usage mappings. A stale query must be reviewed before generation.

The compiler is pure and deterministic. It receives an accepted query and any explicitly declared trusted constraints, then emits the guard artifact used by the generated backend.

The first conservative rules are:

Query part Derived meaning
select/include The accepted structural projection
where Allowed field and operator structure. Ordinary sample values are erased to typed leaves
orderBy The represented ordering structure
skip Allowed only when the template includes it
take A conservative default and maximum based on the accepted positive value
data The represented writable fields and nested operations
scalar literal A sample/default, never an implicit forced security value

Unsupported or ambiguous constructs fail closed. The compiler does not widen a query to make it pass.

The generated guard remains internal. It may be available as an advanced diagnostic or build artifact for developers, but it is not the normal editing interface.

Some security rules cannot be learned from a query example:

  • current user or tenant scope
  • company ownership
  • hidden/deleted predicates
  • server-controlled fields
  • identity and role restrictions
  • hook-added conditions.

These rules are declared as trusted server constraints or hooks. They are not inferred from a value typed into the query editor. A query template may request companyId, but that does not authorize a caller to choose another company.

The generated backend applies authentication, permissions, trusted constraints and guards before returning a result. Hooks remain server code. They do not become arbitrary query policy through the editor.

One Prisma model can safely have many variants. For example, a talent profile model may need:

  • a small autocomplete projection
  • a company search projection with filters and pagination
  • a profile-summary projection
  • a dashboard projection
  • a grouped dashboard query
  • an account update shape
  • a separate boost mutation shape.

These are separate usages even when they share a model and operation. Each trusted usage becomes a fixed generated HTTP method and path whose handler captures one query identity. A caller cannot select another variant with a header, body field or query parameter. Route paths use the same grammar and collision checks as generated and owned routes.

Path parameters supply declared unique selectors. Query parameters supply declared filters, ordering and pagination. Mutation bodies supply declared data fields. Every value is checked against the derived guard shape. The saved projection is fixed, and saved literals remain examples rather than forced values.

If two usages are intentionally identical, link them to the same saved query explicitly. Do not rely on name matching or automatic structural union.

The generated backend still uses the prisma-generator-express route and hook contracts and prisma-guard at the Prisma boundary. See Extending your backend for owned hooks, operation overrides, groups and custom routes.

The query editor does not replace those extension points:

  • query variants describe allowed request shapes
  • trusted constraints protect ownership and tenant boundaries
  • hooks add server behavior around the generated operation
  • operation overrides replace or wrap an operation under the existing authentication, permission, guard and error contracts.

Do not edit generated route files or generated guard files in a connected backend. Put application code in the documented owned files. See Implementation details for the generated stack, dependencies and ownership zones, and Guard settings for the fixed guard policy.

Before a query becomes generation input, review:

  1. the model and Prisma operation
  2. the usage key and trusted route mapping
  3. the projection and relation depth
  4. allowed filters, operators, ordering and bounds
  5. writable fields and nested writes
  6. trusted constraints and hooks
  7. stale schema or removed-field errors
  8. the negative case: a query from another usage must fail.

Changing a model field, relation, selector or operation can make a saved query stale. Generation must refuse until the query is repaired or deliberately removed.

The saved-query contract is defined in the canonical SPEC.md and SPEC-ACCESS.md contracts. Production storage, the model-builder workspace, the route editor’s method and path, generation-time validation and the fixed runtime endpoints are implemented. A standalone backend serves each bound trusted route at its own method and path from src/trusted-routes.ts. The manifest those handlers read is src/query-manifest.ts. Query edits still take effect only after regeneration and redeployment. Check the generated artifact’s own README before using it in a deployment.

When the backend is ready to run without managed regeneration, follow Detach and verify.


ยังไม่เปิดตัว (pre-MVP) และยังไม่มีเวอร์ชันเสถียร
คอมมิตซอร์สโค้ด: fe23db481c422b40e317b92fc98116b4c0c26a87 (มีการแก้ไขที่ยังไม่คอมมิต)
วันที่สร้างเอกสาร (UTC): 2026-10-18T09:22:34.630Z
คอมมิตสำหรับอัปเกรด: ระบุไม่ได้: มีการแก้ไขที่ยังไม่คอมมิต. บันทึกการเปลี่ยนแปลง