@kazee-ds/init 0.1.2 → 0.1.3
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.
- package/README.md +1 -1
- package/package.json +1 -1
- package/src/content.mjs +1 -1
- package/templates/AGENTS.md +63 -63
package/README.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# @kazee-ds/init
|
|
2
2
|
|
|
3
|
-
Preview-first setup for an existing standalone React or Vue application.
|
|
3
|
+
Preview-first setup for an existing standalone React or Vue application. Public release 0.1.2 pins core packages at 0.4.0. Verify the available npm versions before installing. Earlier CLI releases targeted private GitLab.
|
|
4
4
|
|
|
5
5
|
From the design-system checkout, run:
|
|
6
6
|
|
package/package.json
CHANGED
package/src/content.mjs
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
import { readFileSync } from 'node:fs';
|
|
2
2
|
|
|
3
|
-
export const RELEASE = Object.freeze({ framework: '0.
|
|
3
|
+
export const RELEASE = Object.freeze({ framework: '0.5.0', styles: '0.5.0', lint: '0.4.0' });
|
|
4
4
|
export const REGISTRY = 'https://registry.npmjs.org/';
|
|
5
5
|
const INIT_VERSION = JSON.parse(
|
|
6
6
|
readFileSync(new URL('../package.json', import.meta.url), 'utf8'),
|
package/templates/AGENTS.md
CHANGED
|
@@ -1,63 +1,63 @@
|
|
|
1
|
-
# Kazee Design System consumer rules
|
|
2
|
-
|
|
3
|
-
Apply these rules to UI work in this application alongside its existing project instructions. Keep the application's established framework, package manager, routing, localization, data flow, and API contracts.
|
|
4
|
-
|
|
5
|
-
## Check the installed contract first
|
|
6
|
-
|
|
7
|
-
- Read this application's `package.json` and lockfile before changing UI. Use its installed package version as the API contract.
|
|
8
|
-
- Use the installed version's public catalog. Published 0.2.0 exposes eight components per framework; the prepared 0.3.0 catalog has 32. Do not assume a component exists in an older version.
|
|
9
|
-
- When Kazee MCP is connected, read `get_catalog_versions`, then `list_components`, `get_component_docs`, and `get_component_examples` using this framework and exact installed version. Otherwise inspect the installed package's public types when uncertain. A prop accepted by React Aria, Reka UI, or another UI library is not automatically supported by Kazee components.
|
|
10
|
-
- Start file discovery in application source, manifests, and the installed Kazee package's public entry points/types. Do not recursively list all of `node_modules` or investigate React Aria/Reka UI internals for routine component usage.
|
|
11
|
-
- Investigate dependency internals only when a concrete type, build, or runtime failure remains unexplained by the public contract. Identify that failure and the relevant file before expanding the search. When the requested behavior, build, and typecheck pass, report the result and any unrun checks instead of continuing speculative API research.
|
|
12
|
-
- Browse states in the public [Storybook](https://kazee-design-system-023417.gitlab.io). The catalog may differ from the installed version; check types before copying an example.
|
|
13
|
-
- Follow the [installation guide](https://gitlab.com/kazee.indonesia/kazee-design-system/-/blob/main/docs/installation.md) for package setup. Reading the guide requires GitLab project access; installing packages requires registry credentials. Storybook is public. Never print, commit, or embed registry tokens in frontend code.
|
|
14
|
-
|
|
15
|
-
## Kazee MCP
|
|
16
|
-
|
|
17
|
-
MCP is a read-only reference, not an installer or validator. It needs no token at runtime. Never provide token values to a tool. Candidate catalogs do not establish registry publication. Unknown versions must not be silently replaced with newer APIs. Run the application's actual checks after using examples and report missing or unrun validation.
|
|
18
|
-
|
|
19
|
-
## Reuse the foundation
|
|
20
|
-
|
|
21
|
-
- Use Kazee `Button` and `Select` for matching new UI in areas adopting this design system. Preserve existing application abstractions that already wrap them correctly.
|
|
22
|
-
- Import from `@kazee-ds/react` or `@kazee-ds/vue` public entry points. Do not copy package source into the application or import private build files.
|
|
23
|
-
- Do not bypass these components by importing React Aria or Reka UI directly to recreate their behavior. Keep unrelated existing integrations outside the task unchanged.
|
|
24
|
-
- Import `@kazee-ds/styles/index.css` once at the application's global CSS entry. It includes the tokens; do not add a duplicate token stylesheet.
|
|
25
|
-
- Use the public props for supported component styling. Do not rely on `className` or `style` on Kazee wrappers, or override their internal classes to create undocumented variants. Style application layout on surrounding elements.
|
|
26
|
-
- Common Button variants include `primary`, `secondary`, and `danger`; sizes are `sm`, `md`, and `lg`. Read the exact versioned contract for additional variants, icon-only and pending support. Defaults are `primary` and `md`; use `danger` for destructive actions.
|
|
27
|
-
|
|
28
|
-
## React API
|
|
29
|
-
|
|
30
|
-
- Import `Button` and `Select` from `@kazee-ds/react`.
|
|
31
|
-
- Button activation: `onPress`; disabled state: `isDisabled`. Do not substitute `onClick` or `disabled`.
|
|
32
|
-
- Select requires `label` and `options`. Options have a string `id`, a string `label`, and optional `isDisabled`.
|
|
33
|
-
- Controlled Select: `value` (string or `null`) and `onChange` (receives the selected string ID). Uncontrolled Select: `defaultValue`. Do not mix controlled and uncontrolled state.
|
|
34
|
-
- Use only documented public props. Do not invent `isLoading`, `loading`, `asChild`, `href`, or additional variants.
|
|
35
|
-
|
|
36
|
-
## Vue API
|
|
37
|
-
|
|
38
|
-
- Import `Button` and `Select` from `@kazee-ds/vue`.
|
|
39
|
-
- Button activation: `@press`; disabled state: `disabled`. Do not substitute React prop names.
|
|
40
|
-
- Select requires `label` and `options`. Options have a string `id`, a string `label`, and optional `isDisabled` (including in Vue).
|
|
41
|
-
- Controlled Select: `v-model` with a string or `undefined`. Uncontrolled Select: `defaultValue`. Do not mix controlled and uncontrolled state.
|
|
42
|
-
- Use only documented public props. Do not invent `loading`, `asChild`, `href`, or additional variants.
|
|
43
|
-
|
|
44
|
-
## Tokens, themes, and accessibility
|
|
45
|
-
|
|
46
|
-
- Use existing semantic color variables for new UI adopting the system, such as `--ds-color-surface-default`, `--ds-color-text-default`, and `--ds-color-border-subtle`. Check the installed token CSS before referencing a variable. Do not invent token names or use primitive color variables as semantic colors.
|
|
47
|
-
- Reuse available spacing and radius tokens, such as `--ds-space-4` and `--ds-radius-md`, where they fit. Follow the application's existing conventions for values the foundation does not yet define.
|
|
48
|
-
- Preserve the application's existing theme mechanism. If integrating Kazee light/dark modes, coordinate `data-theme="light"` or `data-theme="dark"` at the document root so portal content receives the same theme. Do not create a second theme toggle or interpolate unchecked tenant input into CSS.
|
|
49
|
-
- Keep Select's visible label and meaningful Button text. React icon-only buttons need an accessible name via the supported `aria-label` prop; verify the installed contract for other cases.
|
|
50
|
-
- Set Button `type="submit"` explicitly when it submits a form; the default is `button`.
|
|
51
|
-
- Preserve keyboard access, focus indication, disabled states, and the application's translations. For pending requests, use existing application feedback and guard request handlers; do not add unsupported loading props to Kazee components.
|
|
52
|
-
|
|
53
|
-
## When a component or capability is missing
|
|
54
|
-
|
|
55
|
-
- State the gap. Use an existing suitable application component or an accessible native element for the requested screen, and use available tokens where appropriate.
|
|
56
|
-
- Keep a necessary fallback local to the application. Do not introduce another component library or redesign unrelated screens as part of routine adoption.
|
|
57
|
-
- A shared Kazee component needs a separate contribution in the design-system repository with a shared React/Vue contract and its quality gates. Do not present an application fallback as a published Kazee component.
|
|
58
|
-
|
|
59
|
-
## Verify the change
|
|
60
|
-
|
|
61
|
-
- Run the application's relevant build, typecheck, lint, and existing tests using its own scripts. Do not assume design-system monorepo commands exist here.
|
|
62
|
-
- For changed interactions, check Button activation and disabled behavior, Select selection, and keyboard focus. Check existing light/dark modes and responsive layout where affected.
|
|
63
|
-
- Report what was actually verified and any checks that could not run. These instructions guide agent behavior; they do not install lint rules or enforce CI by themselves.
|
|
1
|
+
# Kazee Design System consumer rules
|
|
2
|
+
|
|
3
|
+
Apply these rules to UI work in this application alongside its existing project instructions. Keep the application's established framework, package manager, routing, localization, data flow, and API contracts.
|
|
4
|
+
|
|
5
|
+
## Check the installed contract first
|
|
6
|
+
|
|
7
|
+
- Read this application's `package.json` and lockfile before changing UI. Use its installed package version as the API contract.
|
|
8
|
+
- Use the installed version's public catalog. Published 0.2.0 exposes eight components per framework; the prepared 0.3.0 catalog has 32. Do not assume a component exists in an older version.
|
|
9
|
+
- When Kazee MCP is connected, read `get_catalog_versions`, then `list_components`, `get_component_docs`, and `get_component_examples` using this framework and exact installed version. Otherwise inspect the installed package's public types when uncertain. A prop accepted by React Aria, Reka UI, or another UI library is not automatically supported by Kazee components.
|
|
10
|
+
- Start file discovery in application source, manifests, and the installed Kazee package's public entry points/types. Do not recursively list all of `node_modules` or investigate React Aria/Reka UI internals for routine component usage.
|
|
11
|
+
- Investigate dependency internals only when a concrete type, build, or runtime failure remains unexplained by the public contract. Identify that failure and the relevant file before expanding the search. When the requested behavior, build, and typecheck pass, report the result and any unrun checks instead of continuing speculative API research.
|
|
12
|
+
- Browse states in the public [Storybook](https://kazee-design-system-023417.gitlab.io). The catalog may differ from the installed version; check types before copying an example.
|
|
13
|
+
- Follow the [installation guide](https://gitlab.com/kazee.indonesia/kazee-design-system/-/blob/main/docs/installation.md) for package setup. Reading the guide requires GitLab project access; installing packages requires registry credentials. Storybook is public. Never print, commit, or embed registry tokens in frontend code.
|
|
14
|
+
|
|
15
|
+
## Kazee MCP
|
|
16
|
+
|
|
17
|
+
MCP is a read-only reference, not an installer or validator. It needs no token at runtime. Never provide token values to a tool. Candidate catalogs do not establish registry publication. Unknown versions must not be silently replaced with newer APIs. Run the application's actual checks after using examples and report missing or unrun validation.
|
|
18
|
+
|
|
19
|
+
## Reuse the foundation
|
|
20
|
+
|
|
21
|
+
- Use Kazee `Button` and `Select` for matching new UI in areas adopting this design system. Preserve existing application abstractions that already wrap them correctly.
|
|
22
|
+
- Import from `@kazee-ds/react` or `@kazee-ds/vue` public entry points. Do not copy package source into the application or import private build files.
|
|
23
|
+
- Do not bypass these components by importing React Aria or Reka UI directly to recreate their behavior. Keep unrelated existing integrations outside the task unchanged.
|
|
24
|
+
- Import `@kazee-ds/styles/index.css` once at the application's global CSS entry. It includes the tokens; do not add a duplicate token stylesheet.
|
|
25
|
+
- Use the public props for supported component styling. Do not rely on `className` or `style` on Kazee wrappers, or override their internal classes to create undocumented variants. Style application layout on surrounding elements.
|
|
26
|
+
- Common Button variants include `primary`, `secondary`, and `danger`; sizes are `sm`, `md`, and `lg`. Read the exact versioned contract for additional variants, icon-only and pending support. Defaults are `primary` and `md`; use `danger` for destructive actions.
|
|
27
|
+
|
|
28
|
+
## React API
|
|
29
|
+
|
|
30
|
+
- Import `Button` and `Select` from `@kazee-ds/react`.
|
|
31
|
+
- Button activation: `onPress`; disabled state: `isDisabled`. Do not substitute `onClick` or `disabled`.
|
|
32
|
+
- Select requires `label` and `options`. Options have a string `id`, a string `label`, and optional `isDisabled`.
|
|
33
|
+
- Controlled Select: `value` (string or `null`) and `onChange` (receives the selected string ID). Uncontrolled Select: `defaultValue`. Do not mix controlled and uncontrolled state.
|
|
34
|
+
- Use only documented public props. Do not invent `isLoading`, `loading`, `asChild`, `href`, or additional variants.
|
|
35
|
+
|
|
36
|
+
## Vue API
|
|
37
|
+
|
|
38
|
+
- Import `Button` and `Select` from `@kazee-ds/vue`.
|
|
39
|
+
- Button activation: `@press`; disabled state: `disabled`. Do not substitute React prop names.
|
|
40
|
+
- Select requires `label` and `options`. Options have a string `id`, a string `label`, and optional `isDisabled` (including in Vue).
|
|
41
|
+
- Controlled Select: `v-model` with a string or `undefined`. Uncontrolled Select: `defaultValue`. Do not mix controlled and uncontrolled state.
|
|
42
|
+
- Use only documented public props. Do not invent `loading`, `asChild`, `href`, or additional variants.
|
|
43
|
+
|
|
44
|
+
## Tokens, themes, and accessibility
|
|
45
|
+
|
|
46
|
+
- Use existing semantic color variables for new UI adopting the system, such as `--ds-color-surface-default`, `--ds-color-text-default`, and `--ds-color-border-subtle`. Check the installed token CSS before referencing a variable. Do not invent token names or use primitive color variables as semantic colors.
|
|
47
|
+
- Reuse available spacing and radius tokens, such as `--ds-space-4` and `--ds-radius-md`, where they fit. Follow the application's existing conventions for values the foundation does not yet define.
|
|
48
|
+
- Preserve the application's existing theme mechanism. If integrating Kazee light/dark modes, coordinate `data-theme="light"` or `data-theme="dark"` at the document root so portal content receives the same theme. Do not create a second theme toggle or interpolate unchecked tenant input into CSS.
|
|
49
|
+
- Keep Select's visible label and meaningful Button text. React icon-only buttons need an accessible name via the supported `aria-label` prop; verify the installed contract for other cases.
|
|
50
|
+
- Set Button `type="submit"` explicitly when it submits a form; the default is `button`.
|
|
51
|
+
- Preserve keyboard access, focus indication, disabled states, and the application's translations. For pending requests, use existing application feedback and guard request handlers; do not add unsupported loading props to Kazee components.
|
|
52
|
+
|
|
53
|
+
## When a component or capability is missing
|
|
54
|
+
|
|
55
|
+
- State the gap. Use an existing suitable application component or an accessible native element for the requested screen, and use available tokens where appropriate.
|
|
56
|
+
- Keep a necessary fallback local to the application. Do not introduce another component library or redesign unrelated screens as part of routine adoption.
|
|
57
|
+
- A shared Kazee component needs a separate contribution in the design-system repository with a shared React/Vue contract and its quality gates. Do not present an application fallback as a published Kazee component.
|
|
58
|
+
|
|
59
|
+
## Verify the change
|
|
60
|
+
|
|
61
|
+
- Run the application's relevant build, typecheck, lint, and existing tests using its own scripts. Do not assume design-system monorepo commands exist here.
|
|
62
|
+
- For changed interactions, check Button activation and disabled behavior, Select selection, and keyboard focus. Check existing light/dark modes and responsive layout where affected.
|
|
63
|
+
- Report what was actually verified and any checks that could not run. These instructions guide agent behavior; they do not install lint rules or enforce CI by themselves.
|