concept

Bounded Concept Design

Generate a concept specification — a structured description of a module that serves as compressed context for code generation. A concept spec replaces reading 200+ lines of implementation with a 30-line bounded description of what the module IS.

How to interpret $ARGUMENTS

Determine the mode from the argument:

• Path to directory/file (e.g. src/lib/server/auth/): Retrofit mode — read the existing code and propose a concept spec that describes what is already there. Flag any boundary violations you find (imports from other modules' internals, shared mutable state, etc.)
• Feature description (e.g. Portfolio tracking with watchlists): Greenfield mode — design a new concept spec from the description. Enforce decomposition: if the feature has multiple independent purposes, split into multiple concepts.
• drift or check (with optional path, e.g. drift src/lib/server/): Drift detection mode — compare existing CONCEPT.md/PIPELINE.md specs against current code. Produce a structured drift report showing what has diverged.
• No arguments: Discovery mode — analyze the project structure and propose which modules should have concept specs. List each candidate with a one-line purpose. Do NOT generate full specs; ask the user which ones to elaborate. After listing concept candidates, if the project has data transformation patterns or cross-concept coordination, briefly note that /wyx:pipeline and /wyx:sync are available for those patterns.

Concept Spec Format

Write the spec as a CONCEPT.md file placed next to the implementation code (e.g. src/lib/server/auth/CONCEPT.md).

Use this exact structure:

# concept: [Name] [TypeParam]

## purpose
[Single sentence: what this module does and for whom]

## state
- [field]: [TypeParam] -> [type]
- [field]: [TypeParam] -> [type]

## actions

### [action-name] [input1: Type, input2: Type] => [output: Type]
[1-3 lines: what this action does, when it succeeds, when it fails]

### [action-name] [input1: Type] => [result: Type] | [error: String]
[behavior description with error cases as separate output patterns]

## operational principle
after [action]([args])
  => [expected output]
then [action]([args])
  => [expected output]
[This is simultaneously a behavioral contract and a test seed.
Write scenarios that define correct behavior. Multiple scenarios OK.]

## interactions
[Optional. How this concept coordinates with others.]
- when [ExternalConcept/action] completes, [this concept/action] should follow
Use `ConceptName.actionName()` syntax for cross-concept references — these are validated during drift detection.

## dependencies
[Optional. External concepts this module depends on.]
- [ExternalConcept]: [what this concept needs from it]

## known coupling
[Optional. Intentional cross-concept data access that bypasses action interfaces.
Each entry: resource, access pattern, reason, and resolution status.]
- [ExternalConcept/resource]: [access pattern] — reason: [why] — status: keep|refactor|defer