yjcli 0.2.2__tar.gz → 0.2.4__tar.gz

{yjcli-0.2.2 → yjcli-0.2.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: yjcli
-Version: 0.2.2
+Version: 0.2.4
 Summary: Scaffold platforms, services, and AI agent wiring (Cursor/Claude/Codex) for YJ architecture repos.
 Project-URL: Homepage, https://github.com/yseiren87/yjcli
 Project-URL: Repository, https://github.com/yseiren87/yjcli

{yjcli-0.2.2 → yjcli-0.2.4}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "yjcli"
-version = "0.2.2"
+version = "0.2.4"
 description = "Scaffold platforms, services, and AI agent wiring (Cursor/Claude/Codex) for YJ architecture repos."
 readme = "README.md"
 requires-python = ">=3.12"

{yjcli-0.2.2 → yjcli-0.2.4}/src/yjcli/data/skills/yj-arch-core/SKILL.md

@@ -134,7 +134,8 @@ Missing domain does **not** mean collapse into entry. Still use flow + infra.
 Placement when unsure:
 
 1. Owned concept / shared policy across features? → domain  
-2. One feature’s IO / mapping / orchestration? → flow (`services/{feature}`)  
+2. One feature’s IO / mapping / orchestration? → the platform-defined flow
+   boundary (commonly `services/{feature}`)
 3. Clients, config, logging, technical helpers? → infra (`modules`)  
 4. Bootstrap / register only? → entry (`apps` or platform entry files)  
 5. Otherwise do not invent a new home — extend an existing flow
@@ -142,6 +143,10 @@ Placement when unsure:
 UI clients default to **no `domain`**: model = API types; feature rules live in flow.  
 Exception only for heavy client-owned offline DB/engine concepts.
 
+UI platform skills may map flow and view to separate technical roots. Those
+roots must use the same feature boundary so one feature's flow and view remain
+easy to locate without mixing their roles.
+
 ## Import direction
 
 Allowed: `entry -> flow -> domain -> infra`, `entry -> infra`, `flow -> infra`, `view -> flow`, `domain -> infra`.

{yjcli-0.2.2 → yjcli-0.2.4}/src/yjcli/data/skills/yj-frontend/SKILL.md

@@ -24,8 +24,10 @@ frontend/
   {app_name}/
     src/
       main.tsx, App.tsx          # entry
-      stores/, api/              # flow
-      pages/, components/        # view
+      stores/{feature}.ts        # flow state/orchestration
+      api/{feature}/             # flow API access/mapping
+      pages/{feature}/           # container view
+      components/{feature}/      # presentational view
       lib/, hooks/               # infra
 ```
 
@@ -35,11 +37,15 @@ One `{app_name}` = one web app. No micro-frontends unless the user requests it.
 
 ```text
 entry = src/main.tsx, src/App.tsx (routes)
-flow  = stores + api per feature
-view  = pages + feature components (+ generated ui primitives)
+flow  = stores/{feature}.ts + api/{feature}
+view  = pages/{feature} + components/{feature} (+ generated ui primitives)
 infra = lib/*, hooks/*
 ```
 
+Flow and view use the same `{feature}` boundary under separate role roots. Do
+not place a feature store or API module beside `pages/` or `components/` as if
+it were a view.
+
 **No `src/domains/` by default.** Model = API types; feature rules live in store/container (flow).  
 Exception: heavy **client-owned** offline DB/engine concepts only (then optional domain slots per core).
 
@@ -49,7 +55,9 @@ Missing domain ≠ dump DTOs/utils into `main.tsx` / `App.tsx`. Keep feature wor
 
 - Follow `yj-arch-core` env names; listen apps need `HOST`/`PORT`. No plain `.env`.
 - `npm start` / local mode must mean local-dev — do not silently point bare start at development/production deploy envs.
-- Store calls `api`; pages/components do not call network directly.
+- Store calls the same feature's `api`; pages/components do not call network directly.
+- Keep one store file per feature directly under `stores/`; do not add a
+  redundant `{feature}/` directory for a single store file.
 - Container route wires store + router; presentational page takes props only.
 - Routes declared at entry — do not scatter route tables; entry stays registration-thin.
 - Generated UI primitives: do not hand-edit or duplicate.

{yjcli-0.2.2 → yjcli-0.2.4}/src/yjcli/data/skills/yj-mobile-app/SKILL.md

@@ -21,10 +21,11 @@ mobile-app/
   {app_name}/
     lib/
       main.dart, router.dart       # entry
-      providers/{feature}_*.dart   # flow
-      api/{feature}_api.dart       # flow
-      screens/...                  # view
-      widgets/...                  # view
+      providers/{feature}.dart     # flow state/orchestration
+      repositories/{feature}.dart  # optional flow data-source composition/mapping
+      api/{feature}.dart           # infra remote client
+      screens/{feature}/           # container view
+      widgets/{feature}/           # presentational view
       lib/ or core/                # infra
 ```
 
@@ -34,11 +35,19 @@ One `{app_name}` = one mobile service.
 
 ```text
 entry = main + router
-flow  = providers + api
-view  = screens (container) + presentational views/widgets
-infra = shared clients/formatters/utils
+flow  = providers/{feature}.dart + repositories/{feature}.dart
+view  = screens/{feature} + widgets/{feature}
+infra = api/{feature}.dart clients + shared clients/formatters/utils
 ```
 
+Flow and view use the same `{feature}` boundary under separate role roots. A
+feature repository belongs to flow, not beside `screens/` or `widgets/` as a
+view-level module.
+
+Use a repository only when it composes data sources, cache, mapping, or feature
+IO. A thin remote transport client belongs at `api/{feature}.dart` as infra; do
+not add a repository that merely forwards every API call.
+
 **No `lib/domain/` by default.** Feature rules live in providers (flow).  
 Exception: heavy **client-owned** offline DB/engine concepts only.
 
@@ -46,7 +55,11 @@ Missing domain ≠ put feature logic in `main.dart` / router registration.
 
 ## Rules
 
-- Provider/store calls api; widgets do not call network directly.
+- Provider calls its feature repository when composition is needed; otherwise
+  it may call the feature `api` directly. Widgets do not call repositories or
+  network clients directly.
+- Keep one file per feature directly under `providers/`, `repositories/`, and
+  `api/`; do not add a redundant `{feature}/` directory for a single file.
 - Container screen watches providers and passes plain props to presentational widgets.
 - Routes declared at entry (thin); feature work stays in providers/api.
 - Prefer symlink/consume `backend/proto/dist/dart` for MSA contracts when present. Do not copy `.proto` into the app.
@@ -56,7 +69,7 @@ Missing domain ≠ put feature logic in `main.dart` / router registration.
 ```text
 entry -> view
 view (container) -> flow
-flow -> api -> infra
+flow -> infra (including api)
 view (presentational) -> constructor params only
 ```