pith-ui 0.1.4 → 0.2.0-app.2

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.
Files changed (41) hide show
  1. package/AI.md +21 -7
  2. package/API.md +263 -262
  3. package/APP-API.md +2023 -0
  4. package/APP.md +141 -0
  5. package/README.md +35 -4
  6. package/dist/app/files.d.ts +68 -0
  7. package/dist/app/files.d.ts.map +1 -0
  8. package/dist/app/files.js +177 -0
  9. package/dist/app/files.js.map +1 -0
  10. package/dist/app/index.d.ts +57 -0
  11. package/dist/app/index.d.ts.map +1 -0
  12. package/dist/app/index.js +300 -0
  13. package/dist/app/index.js.map +1 -0
  14. package/dist/app/internal.d.ts +31 -0
  15. package/dist/app/internal.d.ts.map +1 -0
  16. package/dist/app/internal.js +2 -0
  17. package/dist/app/internal.js.map +1 -0
  18. package/dist/app/resources.d.ts +89 -0
  19. package/dist/app/resources.d.ts.map +1 -0
  20. package/dist/app/resources.js +190 -0
  21. package/dist/app/resources.js.map +1 -0
  22. package/dist/app/session.d.ts +14 -0
  23. package/dist/app/session.d.ts.map +1 -0
  24. package/dist/app/session.js +12 -0
  25. package/dist/app/session.js.map +1 -0
  26. package/dist/app/settings.d.ts +109 -0
  27. package/dist/app/settings.d.ts.map +1 -0
  28. package/dist/app/settings.js +283 -0
  29. package/dist/app/settings.js.map +1 -0
  30. package/dist/app/workspace.d.ts +232 -0
  31. package/dist/app/workspace.d.ts.map +1 -0
  32. package/dist/app/workspace.js +413 -0
  33. package/dist/app/workspace.js.map +1 -0
  34. package/dist/forms/actions.d.ts +1 -0
  35. package/dist/forms/actions.d.ts.map +1 -1
  36. package/dist/forms/actions.js +3 -2
  37. package/dist/forms/actions.js.map +1 -1
  38. package/dist/styles.css +4 -1
  39. package/dist/tasks/runtime.js +2 -2
  40. package/dist/tasks/runtime.js.map +1 -1
  41. package/package.json +42 -8
package/AI.md CHANGED
@@ -1,8 +1,22 @@
1
1
  # Pith UI: instructions for consumers
2
2
 
3
- Pith UI supplies native TypeScript product blocks and base components. Import from `pith-ui`; import CSS once from `pith-ui/styles.css`. Consult the bundled [API reference](./API.md) for exact factory signatures, state, options, callbacks and handles; the installed `.d.ts` files remain authoritative. Do not guess parameter names, import private package paths or generate parallel JavaScript implementations.
3
+ ## Choose the consumption contract first
4
4
 
5
- ## Choose the largest appropriate block
5
+ Pith Desk and approved application integrations must read the bundled [application contract](./APP.md). Import UI values and types only from `pith-ui/app`, plus `pith-ui/styles.css`. Obtain and validate one mount, call `createApplication`, and use the plain `workspace`, `settings`, `resources` and `files` scenes. Their named state methods and session callbacks own the UI. Use the installed `dist/app/index.d.ts` from the exact registry dependency in the consumer lockfile; do not guess methods from a newer source checkout.
6
+
7
+ Applications supply finite brand data (`name`, optional `qualifier`, optional static `mark: {src, alt}`), appearance and pure host capabilities. They retain request protocols, identity, versioned drafts, permissions, persistence, credentials, login transactions, file acquisition, native actions, costs, update polling and completion/read acknowledgments. The library owns structure, presentation, focus, local pending/errors, menus/disclosures, navigation expansion, reading and image zoom. The [complete compiled reference](./examples/application/main.ts) demonstrates these boundaries with simulated data; the showroom item is [`application-reference`](https://minifish-org.github.io/pith-ui/?item=application-reference).
8
+
9
+ Do not add UI DOM outside the sole checked mount or inspect generated nodes, selectors, datasets, forms, fields, parts, controls, HTML, classes or styles. Do not import root factories, private paths, markup helpers or a copied component as a workaround. If a scene lacks a real capability, first add a permanent regression and a narrow semantic library port, reusing its existing component. Keep application business logic in its controller. Node slots, render callbacks, arbitrary CSS/density/size options and a UI description DSL are not part of `pith-ui/app`.
10
+
11
+ Keep stable business keys. Update feedback without replacing a live draft; explicitly reset/edit or open a new session for a new target. Combine external availability with local pending, retain failed input, and preserve successful-write/failed-refresh semantics without replaying writes. A closed or replaced session cannot update a later opening; controller generations, cancellation and target checks still remain necessary. Follow the exact typed result of each callback: some return `ActionResult`, while void callbacks are business intents that need authoritative availability updates.
12
+
13
+ Install only the approved published registry version or prerelease with an exact version and lockfile. Pith Desk must not use local tarballs, `file:`/`link:`, aliases, symlinks or source-path mappings. Build/test/package proof, npm publication, deployed showroom, native acceptance and human review are separate evidence; do not infer one from another.
14
+
15
+ ## General component consumers
16
+
17
+ The remaining instructions describe the unrestricted `pith-ui` root entry for independent component compositions. They do not grant Pith Desk an escape from the application contract. Pith UI supplies native TypeScript product blocks and base components; these consumers import from `pith-ui` and import CSS once from `pith-ui/styles.css`. Consult the bundled [general API reference](./API.md) for exact factory signatures, state, options, callbacks and handles; the installed declarations remain authoritative. Do not guess parameter names, import private package paths or generate parallel JavaScript implementations.
18
+
19
+ ### Choose the largest appropriate block
6
20
 
7
21
  1. Locate the intended task in the catalog below and inspect its interactive case.
8
22
  2. Prefer the complete product block. Compose base components only when no product block fits.
@@ -38,7 +52,7 @@ Full catalog: https://github.com/minifish-org/pith-ui/blob/main/docs/catalog.md
38
52
 
39
53
  Showroom: https://minifish-org.github.io/pith-ui/?item=text-edit-dialog&theme=light&state=normal&width=800
40
54
 
41
- ## State and lifecycle
55
+ ### State and lifecycle
42
56
 
43
57
  Most views expose `{ element, update(state), destroy() }`; dialogs add open/close and editors expose read/getValue/reset as declared. Pass complete state values of the concrete component type. Do not assume a method exists on every block.
44
58
 
@@ -51,7 +65,7 @@ Most views expose `{ element, update(state), destroy() }`; dialogs add open/clos
51
65
  - Call `destroy()` before releasing an instance. Destroy child block handles supplied through ordinary Node slots yourself; the parent cannot infer their ownership. A `DialogContent` handle passed to `createFeatureDialogFrame` is an explicit ownership transfer and is destroyed when replaced or closed.
52
66
  - Use distinct generated prefixes or supported ID options for coexisting instances. Leave legacy unprefixed IDs to the existing application adapter.
53
67
 
54
- ## Theme and layout
68
+ ### Theme and layout
55
69
 
56
70
  Call `setAppearance(root, 'light' | 'dark' | 'system')` on an ancestor containing the view. Include `document.body` when a dialog is mounted there. This establishes the `.pui` boundary and `--pui-*` tokens.
57
71
 
@@ -67,7 +81,7 @@ Native multi-row lists use 16 CSS px text. Row spacing follows platform capabili
67
81
 
68
82
  Do not add app-wide resets, new fonts, arbitrary animation timings, internal-class overrides or a UI framework to style these blocks. If a product brand needs a theme, centralize overrides in one reviewed token scope and inspect both themes and relevant states.
69
83
 
70
- ## Security and host boundaries
84
+ ### Security and host boundaries
71
85
 
72
86
  - Set ordinary text through typed factory inputs or `textContent`. Node slots accept trusted nodes constructed by the caller, not untrusted HTML.
73
87
  - `renderMarkdown` sanitizes content; embedded media, executable markup, forms and arbitrary CSS are excluded. Local file links require the host's explicit resolver and authenticated download validation.
@@ -75,9 +89,9 @@ Do not add app-wide resets, new fonts, arbitrary animation timings, internal-cla
75
89
  - The host acquires image data, validates supported MIME types and owns object URLs. Revoke URLs when their host scope ends; closing the zoom view does not establish file ownership.
76
90
  - Code-copy callbacks on conversations, paged previews and file previews receive `(text, button)`. The host owns clipboard access and error handling; reuse `createCopyFeedback` with that actual button for pending and result feedback. An owned callback consumes the code-copy event; without one, existing host delegation remains available. Do not install a second copy handler or change per-message eligibility rules.
77
91
  - Never log credentials, save them in the showroom, or place them in URLs. Empty credential fields and explicit removal actions must preserve the application's existing distinction.
78
- - Older safe markup helpers remain for application adapters. Prefer factories and Node composition. Never invent a generic raw-HTML extension point or bypass sanitization.
92
+ - Older safe markup helpers remain for general component compatibility adapters. They are not allowed in Pith Desk's application boundary. Prefer factories and Node composition for unrestricted compositions; never invent a generic raw-HTML extension point or bypass sanitization.
79
93
 
80
- ## Validate a change
94
+ ### Validate a change
81
95
 
82
96
  Type-check the public example, run the related component tests, experience normal/error/loading/disabled/long-content states, and check keyboard, focus, repeated actions and destruction. Preserve existing application behavior tests; changing a selector mechanically is different from weakening its assertion.
83
97