@jskit-ai/agent-docs 0.1.6 → 0.1.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -613,6 +613,57 @@ The safe mental model is:
613
613
  - use command runtimes for actions
614
614
  - keep the server as the source of truth for derived state
615
615
 
616
+ ### Choosing the right client request seam
617
+
618
+ When you need client-side HTTP work in JSKIT, do not start with raw `fetch(...)`.
619
+
620
+ Choose the highest-level runtime that matches the interaction:
621
+
622
+ ```js
623
+ // 1. Button/toggle/small mutation
624
+ const command = useCommand({ ... });
625
+
626
+ // 2. List endpoint
627
+ const list = useList({ ... });
628
+
629
+ // 3. Single-record endpoint
630
+ const view = useView({ ... });
631
+
632
+ // 4. Form save flow
633
+ const form = useAddEdit({ ... });
634
+
635
+ // 5. Truly custom endpoint
636
+ const resource = useEndpointResource({ ... });
637
+ ```
638
+
639
+ Use the CRUD wrappers when they fit:
640
+
641
+ - `useCrudList()` for routed CRUD lists
642
+ - `useCrudView()` for routed CRUD record loading
643
+ - `useCrudAddEdit()` for routed CRUD forms
644
+
645
+ Why this is the standard JSKIT shape:
646
+
647
+ - `useCommand()` resolves the correct scoped API path for the current route and surface.
648
+ - The higher-level list, view, add/edit, and command runtimes send requests through the standard HTTP runtime instead of ad hoc request code.
649
+ - The default client runtime uses `usersWebHttpClient`, which already handles credentials and CSRF token behavior.
650
+ - `useEndpointResource()` gives the shared endpoint primitive for loading, saving, and standard load/save error handling. Higher-level runtimes like `useCommand()` and `useAddEdit()` layer UI feedback and field-error behavior on top of that primitive.
651
+
652
+ If you need a custom scoped endpoint path outside the higher-level runtimes, prefer `usePaths().api(...)` rather than hand-building scoped URLs:
653
+
654
+ ```js
655
+ const paths = usePaths();
656
+ const reportsApiPath = computed(() => paths.api("/reports"));
657
+ ```
658
+
659
+ The safe mental model is:
660
+
661
+ - do not raw `fetch(...)` for normal app work
662
+ - do not invent ad hoc local AJAX helpers
663
+ - use the operation/runtime composable that matches the UI interaction
664
+ - drop to `usersWebHttpClient.request(...)` only for exceptional low-level cases
665
+ - use `usePaths().api(...)` when you need a custom scoped API path and the higher-level runtime does not already resolve it for you
666
+
616
667
  ### `_components/CrudAddEditForm.vue`
617
668
 
618
669
  This is the shared rendering shell for the add/edit form.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@jskit-ai/agent-docs",
3
- "version": "0.1.6",
3
+ "version": "0.1.7",
4
4
  "description": "Distributed JSKIT agent workflows, guides, and generated reference maps.",
5
5
  "type": "module",
6
6
  "files": [
package/patterns/INDEX.md CHANGED
@@ -20,6 +20,8 @@ How to use it:
20
20
  - `crud-links.md`
21
21
  - live actions, checkbox, toggle, patch button, inline action, `useCommand()`
22
22
  - `live-actions.md`
23
+ - ajax, fetch, API call, request, endpoint, HTTP client, `useList()`, `useView()`, `useAddEdit()`, `useEndpointResource()`, `usersWebHttpClient`
24
+ - `client-requests.md`
23
25
  - filter, filters, search facets, chips, date range, enum filter, lookup filter, `useCrudListFilters`, `createCrudListFilters`
24
26
  - `filters.md`
25
27
 
@@ -30,4 +32,5 @@ How to use it:
30
32
  - [child-cruds.md](./child-cruds.md)
31
33
  - [crud-links.md](./crud-links.md)
32
34
  - [live-actions.md](./live-actions.md)
35
+ - [client-requests.md](./client-requests.md)
33
36
  - [filters.md](./filters.md)
@@ -0,0 +1,56 @@
1
+ # Client Request Patterns
2
+
3
+ Use when:
4
+
5
+ - deciding which JSKIT client function to use for HTTP work
6
+ - custom endpoint reads or writes
7
+ - AJAX questions
8
+ - replacing raw `fetch(...)` calls
9
+ - choosing between `useCommand()`, `useList()`, `useView()`, `useAddEdit()`, and `useEndpointResource()`
10
+
11
+ Rules:
12
+
13
+ - Prefer the highest-level JSKIT runtime that matches the UI interaction.
14
+ - Do not hand-roll local AJAX helpers when an existing JSKIT runtime already fits.
15
+ - Do not use raw `fetch(...)` for normal app work.
16
+ - Use `usePaths().api(...)` for custom scoped API paths instead of concatenating route params into URLs by hand.
17
+ - Drop to `usersWebHttpClient.request(...)` only for exceptional low-level cases.
18
+
19
+ Choose the function like this:
20
+
21
+ ```js
22
+ // 1. Button/toggle/small mutation
23
+ const command = useCommand({ ... });
24
+
25
+ // 2. List endpoint
26
+ const list = useList({ ... });
27
+
28
+ // 3. Single-record endpoint
29
+ const view = useView({ ... });
30
+
31
+ // 4. Form save flow
32
+ const form = useAddEdit({ ... });
33
+
34
+ // 5. Truly custom endpoint
35
+ const resource = useEndpointResource({ ... });
36
+ ```
37
+
38
+ Use the CRUD wrappers when they fit:
39
+
40
+ - `useCrudList()` for routed CRUD lists
41
+ - `useCrudView()` for routed CRUD record loading
42
+ - `useCrudAddEdit()` for routed CRUD forms
43
+
44
+ Why this is the standard JSKIT shape:
45
+
46
+ - `useCommand()` resolves the scoped API path for the current route and surface.
47
+ - The higher-level list, view, add/edit, and command runtimes send requests through the shared HTTP runtime.
48
+ - `usersWebHttpClient` already handles credentials and CSRF behavior.
49
+ - `useEndpointResource()` is the shared endpoint primitive for loading, saving, and standard load/save error handling. Higher-level runtimes add UI feedback and field-error handling on top.
50
+
51
+ Avoid:
52
+
53
+ - raw `fetch(...)` for standard page or component work
54
+ - page-local HTTP helpers that duplicate JSKIT runtime seams
55
+ - manually concatenating scoped route params into API URLs
56
+ - using a lower-level seam when a higher-level routed CRUD or command runtime already fits
@@ -22,6 +22,36 @@ Use these references on demand:
22
22
  - `node_modules/@jskit-ai/agent-docs/templates/WORKBOARD.md`
23
23
  - `node_modules/@jskit-ai/agent-docs/skills/jskit-review/SKILL.md` for review passes when your Codex environment supports packaged skills
24
24
 
25
+ ## Mandatory Start Gate
26
+
27
+ Before any non-trivial change:
28
+
29
+ 1. Read this file and the workflow files above in the current turn. Do not rely on memory alone.
30
+ 2. If the task involves JSKIT UI, routing, surfaces, CRUDs, filters, placements, live actions, or similar implementation details, scan `node_modules/@jskit-ai/agent-docs/patterns/INDEX.md` and read the relevant pattern files before editing.
31
+ 3. For substantial or multi-chunk work, create or update `.jskit/WORKBOARD.md` before editing.
32
+ 4. Before editing, print a compact read receipt with:
33
+ - `Read receipt: ...`
34
+ - `Active chunk: ...`
35
+ - `Generator decision: ...`
36
+ - `Relevant patterns: ...`
37
+ - `Active rules from docs: ...`
38
+ 5. When files need to be created, prefer `jskit generate ...` over creating them from scratch, even if the generated output will need follow-up adaptation. If not using a generator, say why.
39
+ 6. Do not edit code until the read receipt is printed and the workboard step is complete when it applies.
40
+
41
+ ## Mandatory Done Gate
42
+
43
+ Before calling a chunk done, report:
44
+
45
+ - `Deslop review: ...`
46
+ - `JSKIT review: ...`
47
+ - `Material/Vuetify review: ...`
48
+ - `Verification: ...`
49
+ - `Files changed: ...`
50
+ - `Commands run: ...`
51
+ - `Remaining unverified: ...`
52
+
53
+ If a feature spans more than one chunk, repeat those passes on the whole changeset after the final chunk.
54
+
25
55
  Core rules:
26
56
 
27
57
  - Inspect the workspace before assuming a JSKIT app exists.
@@ -31,7 +61,6 @@ Core rules:
31
61
  - `Why this sticks: ...`
32
62
  - `Not doing: ...`
33
63
  - Keep that checkpoint compact. Do not expand it into a long preamble unless the developer asks for detail.
34
- - When a request involves JSKIT UI, routing, surfaces, CRUDs, filters, placements, live actions, or similar implementation details, scan `node_modules/@jskit-ai/agent-docs/patterns/INDEX.md` for matching keywords and read only the relevant pattern files.
35
64
  - Reuse existing JSKIT helpers and runtime seams before adding new local helpers.
36
65
  - A freshly scaffolded JSKIT app can still be in Stage 1. If the app was just created and platform decisions are not settled yet, continue with the initialize workflow before adding runtime packages.
37
66
  - Do not treat a missing `config.tenancyMode` line or an untouched minimal scaffold as a final tenancy decision.
@@ -43,7 +72,6 @@ Core rules:
43
72
  - For CRUD chunks, ask the developer which operations are allowed, which fields belong in the list view if one exists, and the intended look of the view and edit/new forms before generating code.
44
73
  - Every user-facing screen must pass a Material Design and Vuetify quality review before the chunk is considered done.
45
74
  - Do not implement app features before the blueprint has the database, surfaces, ownership model, and route/screen plan written down.
46
- - For substantial or multi-chunk work, create or update `.jskit/WORKBOARD.md` as the per-request execution tracker.
47
75
  - Break planned work into reviewable chunks before implementing. One CRUD is usually one chunk, but auth/platform setup, shell work, and cross-cutting integrations can be their own chunks.
48
76
  - Do not move to the next chunk until the current chunk has passed implementation, deslop review, JSKIT best-practices review, Material Design/Vuetify review, and verification.
49
77
  - If a feature spans more than one chunk, run a final whole-changeset deslop pass, JSKIT pass, Material Design/Vuetify pass, and verification pass after the last chunk.