feat: vendor FIRST 0.3 and thin station overlays

.agents/skills/f/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: f
-description: FIRST factory dispatcher. Lists /f-* station and role skills. Use when the user types /f or /f-product, /f-designer, /f-analyst.
+description: FIRST factory dispatcher. Lists /f-* station and role skills. Use when the user types /f or /f-product, /f-journeys, /f-analyst.
 disable-model-invocation: true
 ---
 
@@ -13,15 +13,13 @@ If `$ARGUMENTS` (or the rest of the message after `/f`) is a known token, Read `
 ## Aliases → folder
 
 - `product` → `f-product`
-- `design`, `designer` → `f-designer`
+- `journeys`, `design`, `designer` → `f-journeys`
 - `data`, `analyst` → `f-analyst`
 - `documentation`, `docs`, `ia` → `f-info-architect`
 - `ai`, `ai-expert` → `f-ai-expert`
-- `journeys` → `f-journeys`
 - `architecture` → `f-architecture`
 - `api` → `f-api`
-- `workflow` → `f-workflow`
-- `pipelines` → `f-pipelines`
+- `workflow`, `pipelines` → `f-workflow`
 - `quality` → `f-quality`
 - `security` → `f-security`
 - `operations` → `f-operations`
@@ -33,17 +31,15 @@ Unknown token: say so, print this index, stop.
 | Slash | Station or role |
 |---|---|
 | `/f-product` | Product |
-| `/f-journeys` | Journeys |
-| `/f-designer` | Design |
+| `/f-journeys` | Journeys (`/f-designer` is an alias) |
 | `/f-architecture` | Architecture |
 | `/f-analyst` | Data |
 | `/f-api` | API |
 | `/f-info-architect` | Documentation |
-| `/f-workflow` | Workflow |
-| `/f-pipelines` | Pipelines |
+| `/f-workflow` | Workflow (`/f-pipelines` is an alias) |
 | `/f-quality` | Quality |
 | `/f-security` | Security |
 | `/f-operations` | Operations |
-| `/f-ai-expert` | Agents, evals, assistant (not a 13th station) |
+| `/f-ai-expert` | Agents, evals, assistant (not an eleventh station) |
 
 Always load `./references/analyst.md` before the child spec.

.agents/skills/f/f-ai-expert/SKILL.md

@@ -4,7 +4,7 @@ description: Inspect agents, evals, and assistant surfaces as a data analyst. Us
 disable-model-invocation: true
 ---
 
-Role only. Not a thirteenth station.
+Role only. Not an eleventh station.
 
 1. Read [../references/analyst.md](../references/analyst.md).
 2. Read `_first/FIRST.md` and instance paths for quality, workflow, and architecture if those stations are In.

.agents/skills/f/f-analyst/references/spec.md

@@ -10,7 +10,7 @@ I treat data as durable product state with meaning, ownership, and a lifecycle
 
 ## Outcome
 
-Core domain concepts have shared names and definitions. Each important dataset has an owner and authoritative source. Identity, constraints, retention, deletion, lineage, and schema evolution are explicit at the level the product needs. Migrations preserve or deliberately transform meaning. Copies do not silently become competing sources of truth.
+Core domain concepts have shared names and definitions. Each important dataset has an owner and authoritative source. Identity, constraints, retention, deletion, lineage, and schema evolution are explicit at the level the product needs. Session and long-term conversational memory are backing-service state with an owner, retention, and deletion — not process memory and not eval datasets. Migrations preserve or deliberately transform meaning. Copies do not silently become competing sources of truth.
 
 ## Artifacts
 
@@ -73,7 +73,9 @@ Propose the smallest useful data decision. Implement constraints and migrations
 
 **Data vs Product:** Product owns event taxonomy and the outcomes to measure. Data owns the meaning, authority, and lifecycle of the resulting records.
 
-**Data vs Architecture:** Architecture places stores and data flows. Data defines what the state means and which source is authoritative.
+**Data vs Architecture:** Architecture places stores and requires a stateless process. Data defines what the state means and which source is authoritative, including conversational memory in a backing store.
+
+**Data vs Journeys:** Journeys owns resume and turn-taking in the job. Data owns the memory store.
 
 **Data vs API:** Data owns the canonical domain model. API owns the external representation and compatibility contract.
 

.agents/skills/f/f-api/references/spec.md

@@ -6,7 +6,7 @@ Define the capability and its boundary before consumers couple to an accidental
 
 ## Statement
 
-I treat the capability and its boundary as a design decision, not an implementation leftover. Before a second consumer depends on a shape, I want to know what goes in, what comes out, what fails, which Security-owned authorization requirement applies, and how denial appears. That contract might be HTTP, a typed module, an event, a CLI, or an agent tool. The format matters less than making the boundary explicit on purpose.
+I treat the capability and its boundary as a design decision, not an implementation leftover. Before a second consumer depends on a shape, I want to know what goes in, what comes out, what fails, which Security-owned authorization requirement applies, and how denial appears. That contract might be HTTP, a typed module, an event, a CLI, or an agent tool. Export the capability as a self-contained boundary — a bound port or equivalent — rather than as a leak of the process that happens to implement it. The format matters less than making the boundary explicit on purpose.
 
 ## Outcome
 

.agents/skills/f/f-architecture/references/spec.md

@@ -10,7 +10,7 @@ I treat architecture as the small set of decisions that are expensive to reverse
 
 ## Outcome
 
-The system has an inspectable structural model at the level its scale requires. Components have named responsibilities and owners. Dependency direction, external systems, data stores, and deployment units are visible. Consequential choices have rationale and known tradeoffs. Implementation conforms, or the model is updated deliberately.
+The system has an inspectable structural model at the level its scale requires. Components have named responsibilities and owners. Dependency direction, external systems, data stores, and deployment units are visible. Application processes are stateless; durable state lives in attached backing services that can be swapped without rewriting the app. Consequential choices have rationale and known tradeoffs. Implementation conforms, or the model is updated deliberately.
 
 ## Artifacts
 
@@ -74,8 +74,10 @@ Propose the smallest useful structural change or artifact. Record rationale and
 
 **Architecture vs API:** Architecture decides which components communicate. API defines the contract across a boundary.
 
-**Architecture vs Pipelines:** Architecture describes deployment units and topology. Pipelines build, validate, and deliver them.
+**Architecture vs Workflow:** Architecture describes deployment units and topology. Workflow builds, validates, and delivers them.
 
 **Architecture vs Operations:** Architecture names the running parts. Operations observes and recovers them.
 
+**Architecture vs Documentation:** If context-engineering is a structural boundary, it is application structure, not a notebook string. Documentation versions the prompt files.
+
 **Navigation:** [Human essay](../articles/ARCHITECTURE.md) · [Factory map](../ABOUT.md)

.agents/skills/f/f-info-architect/references/spec.md

@@ -10,7 +10,7 @@ I document decisions and context, not obvious code. If someone will need to redi
 
 ## Outcome
 
-Consequential decisions, conventions, setup steps, and domain context live in discoverable project files. Documentation matches current behavior or explicitly notes drift. When behavior or assumptions change, the files change in the same work.
+Consequential decisions, conventions, setup steps, domain context, prompt templates, and behavioral specs live in discoverable project files. Documentation matches current behavior or explicitly notes drift. When behavior or assumptions change, the files change in the same work.
 
 ## Artifacts
 
@@ -19,6 +19,7 @@ Consequential decisions, conventions, setup steps, and domain context live in di
 - Architecture documentation and ADRs
 - Project conventions and operational notes
 - Domain documentation and setup guides
+- Prompt templates, behavioral specs, and context-engineering notes as versioned project files
 - Changelog entries for behavior changes worth remembering
 - `llms.txt` for selective public-site orientation when the product publishes substantial web documentation
 
@@ -70,6 +71,6 @@ Document decisions and conventions — not obvious code. Preserve intentional ex
 
 **Documentation vs everything:** Other stations produce decisions. Documentation decides which context must stay durable.
 
-**Documentation vs Workflow:** Workflow determines when context is created and handed off. Documentation preserves it.
+**Documentation vs Workflow:** Workflow determines when context is created and handed off, and runs CI. Documentation preserves it, including prompt files. Quality already owns eval datasets. Architecture already owns application structure if context-engineering is a structural boundary.
 
 **Navigation:** [Human essay](../articles/DOCUMENTATION.md) · [Factory map](../ABOUT.md)

.agents/skills/f/f-journeys/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: f-journeys
-description: Apply Journeys First with a journeys lens who inspects this repo as a data analyst. Use when the user types /f-journeys or /f journeys.
+description: Apply Journeys First with a journeys lens who inspects this repo as a data analyst. Use when the user types /f-journeys, /f journeys, /f-designer, or /f design.
 disable-model-invocation: true
 ---
 
 Apply Journeys First with a journeys lens.
 
 1. Read [../references/analyst.md](../references/analyst.md).
-2. Read `_first/FIRST.md`. Take the In path for `journeys:`. If that station is Out, stop and say so.
+2. Read `_first/FIRST.md`. Take the In path for `journeys:`. If that station is Out, stop and say so. Tokens `design` and `designer` resolve here; they are not a station.
 3. Read the instance file at that path.
 4. Read [references/spec.md](references/spec.md).
 5. Compare the spec and overlay to the implementation. Label Fact, inference, assumption, unresolved.