howone 0.1.7 → 0.1.8

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "howone",
3
- "version": "0.1.7",
3
+ "version": "0.1.8",
4
4
  "private": false,
5
5
  "description": "HowOne command line tools for creating app templates.",
6
6
  "type": "module",
@@ -1,11 +1,46 @@
1
- Use the project SDK from `src/lib/sdk.ts` for backend access.
1
+ # AGENTS.md
2
2
 
3
- For entity CRUD, prefer typed project bindings:
3
+ This file defines project-specific instructions for coding agents.
4
4
 
5
- ```ts
6
- import howone from "@/lib/sdk"
5
+ Read this file once when entering the project.
6
+ Follow it during implementation.
7
+ Do not repeatedly reread it unless it changes or the current task requires checking project rules again.
7
8
 
8
- await howone.entities.Todo.create({ text, completed: false })
9
- ```
9
+ ## Library Trust Policy
10
10
 
11
- Do not call `howone.entity("Todo")` directly in application code when a typed `howone.entities.Todo` binding exists. Add or update the binding in `src/lib/sdk.ts` first.
11
+ For common public libraries already known to modern coding models, prefer model knowledge and package metadata over reading local source files.
12
+
13
+ This project may include generated or vendored library-style files, such as shadcn/ui components under `src/components/ui/*`.
14
+
15
+ Do not inspect these files during ordinary feature work just to confirm standard APIs.
16
+
17
+ Examples of trusted public libraries:
18
+
19
+ - React
20
+ - Vite
21
+ - TypeScript
22
+ - Tailwind CSS
23
+ - shadcn/ui
24
+ - lucide-react
25
+ - Radix UI
26
+ - clsx
27
+ - class-variance-authority
28
+
29
+ When implementing ordinary usage of these libraries:
30
+
31
+ 1. Use standard public APIs first.
32
+ 2. Read `package.json`, `components.json`, `tsconfig.json`, or alias config only when needed.
33
+ 3. Implement the feature.
34
+ 4. Run build/typecheck.
35
+ 5. Inspect the smallest relevant local file only if validation fails or the API is genuinely unclear.
36
+
37
+ Only read local component or library-style source files when:
38
+
39
+ - build/typecheck fails
40
+ - imports cannot be resolved from `package.json`, `tsconfig.json`, or `components.json`
41
+ - the component API is unclear
42
+ - the task requires modifying the component implementation
43
+ - the project has custom wrappers, custom variants, or unusual exports
44
+ - the user explicitly asks to follow local component conventions
45
+
46
+ Prefer failure-driven inspection over speculative context loading.