agent-ecosystem/src/features/CLAUDE.md
2026-05-14 15:11:40 +03:00

78 lines
3.3 KiB
Markdown

# Feature-Local Guidance
This file is a navigation layer for feature slices under `src/features/`.
Before changing a feature slice, read:
- [Project instructions](../../CLAUDE.md)
- [Feature Architecture Standard](../../docs/FEATURE_ARCHITECTURE_STANDARD.md)
- [Feature root guide](./README.md)
Use local references:
- `src/features/recent-projects` - full cross-process reference
- `src/features/member-work-sync` - full feature with a root public barrel
- `src/features/member-log-stream` - full feature with `main/application/`
- `src/features/agent-graph` - thin `core/domain` plus `renderer` reference
Default location for new feature work:
- `src/features/<feature-name>/`
Before adding a medium or large feature:
- decide whether the feature is full, thin, or process-limited
- start with the layer set the feature actually owns; do not add placeholder
folders just to match the full template
- create explicit public entrypoints for every layer production callers need
- put shared DTOs, channel names, and API fragments in `contracts/`
- keep business policy in `core/domain` and use-case orchestration in
`core/application`
- keep Electron, IPC, HTTP, file system, process, and provider specifics outside
`core/`
- wire runtime dependencies from `main/composition/` when the feature owns main
process behavior
- expose preload bridges through `preload/index.ts` and renderer surfaces
through `renderer/index.ts`
- add focused tests for the layers that carry behavior
When modifying an existing feature:
- preserve the feature's current shape unless the change introduces a real new
boundary
- route app shell and cross-feature imports through public entrypoints
- move duplicated rules toward `core/domain` before adding another adapter copy
- keep transport validation and normalization close to the boundary that receives
the data
- update the feature README or local notes when the public surface or intended
shape changes
- keep local README examples concrete and file-based; link back to the standard
for architecture rules instead of restating them
Public entrypoint expectations:
- `contracts/index.ts` exports only browser-safe contracts, constants, and
normalizers intended for cross-process use
- `main/index.ts` exports composition and registration surfaces for main-process
callers
- `preload/index.ts` exports bridge creation only
- `renderer/index.ts` exports reusable renderer components, hooks, or utilities
that are intentionally consumed outside the feature
- root `index.ts` is optional; use it only when the feature deliberately owns a
stable public barrel
Testing expectations:
- test pure domain rules directly and keep those tests independent of runtime
services
- test application use cases with ports or fakes, not Electron or real provider
processes
- test adapter mapping, boundary normalization, and renderer utilities where they
can regress user-visible behavior
- prefer `test/features/<feature>/...` for cross-layer coverage; feature-local
`__tests__` are fine when the surrounding feature already uses that pattern
- for docs-only changes, verify links and examples instead of running broad test
suites
Do not duplicate architecture rules here. Keep architecture rules centralized in
[../../docs/FEATURE_ARCHITECTURE_STANDARD.md](../../docs/FEATURE_ARCHITECTURE_STANDARD.md).