@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
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
|
package/templates/app/AGENTS.md
CHANGED
|
@@ -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.
|