aether-colony 5.0.0 → 5.2.1

package/.aether/skills/colony/build-discipline/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: build-discipline
+description: Use when implementing code, writing tests, or executing build tasks as a builder worker
+type: colony
+domains: [building, testing, quality, implementation]
+agent_roles: [builder]
+priority: normal
+version: "1.0"
+---
+
+# Build Discipline
+
+## Purpose
+
+Builder workers must follow a disciplined implementation process. This skill ensures consistent quality, avoids repeating known failures, and keeps work aligned with the phase plan.
+
+## Pre-Build Checklist
+
+Before writing any code, complete these checks in order:
+
+### 1. Check the Midden
+
+Query recent failures using `midden-recent-failures`. Read what went wrong in previous builds. The midden exists to prevent you from repeating the same mistakes.
+
+- If the midden contains failures related to your current task, adjust your approach before starting.
+- If a failure has been acknowledged, note the resolution and follow it.
+- Never ignore midden entries -- they represent real colony learning.
+
+### 2. Check Active Pheromone Signals
+
+Read all injected REDIRECT signals. These are hard constraints -- you must not violate them under any circumstances. Examples:
+- "No inline styles" means you must use CSS classes or utility frameworks.
+- "Avoid raw SQL" means you must use an ORM or query builder.
+
+Read all FOCUS signals. These indicate where to direct extra attention:
+- A FOCUS on "security" means add input validation, check for injection, review auth flows.
+- A FOCUS on "testing" means write more comprehensive test cases than usual.
+
+Read all FEEDBACK signals. These are preferences to incorporate naturally:
+- "Prefer functional components" means choose functions over classes when both work.
+
+### 3. Review the Phase Plan
+
+Read the current phase description and task list. Understand exactly what you are supposed to build. Do not add features not in the plan. Do not refactor code outside your task scope. Stay focused.
+
+## Implementation Process
+
+### Write Tests First
+
+Follow TDD discipline where the task permits:
+1. Write a failing test that describes the expected behavior.
+2. Run the test -- confirm it fails for the right reason.
+3. Write the minimal code to make the test pass.
+4. Refactor while keeping tests green.
+
+If TDD is not practical for the task (e.g., configuration changes, documentation), note why in your output.
+
+### Log Failures Before Changing Approach
+
+If your implementation fails (test failure, build error, runtime crash):
+1. Log the failure to the midden using `midden-write` before trying an alternative.
+2. Include: what you tried, what error occurred, and what you will try next.
+3. This ensures the colony learns from every failed attempt, not just the final success.
+
+### Stay On Task
+
+- Reference the phase plan task list in your output.
+- Mark tasks as complete as you finish them.
+- If you discover work that needs doing but is outside your task scope, flag it -- do not do it.
+- If a task is blocked, report the blocker clearly instead of working around it silently.
+
+## Output Standards
+
+End your work summary with:
+- Tasks completed (by name from the plan).
+- Tests written and their pass/fail status.
+- Any REDIRECT signals you complied with and how.
+- Any blockers or flags raised.

package/.aether/skills/colony/colony-interaction/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: colony-interaction
+description: Use when executing commands that involve major decisions, plan commits, build starts, verifications, or phase advances
+type: colony
+domains: [interaction, ux, workflow]
+agent_roles: [builder, watcher, route_setter, architect]
+priority: normal
+version: "1.0"
+---
+
+# Colony Interaction
+
+## Purpose
+
+The colony workflow must not run autonomously past major decision points. Users want to feel in control of direction. This skill teaches you when and how to pause for user input.
+
+## Mandatory Touchpoints
+
+Stop and present a multiple-choice question at each of these moments:
+
+1. **Before committing a plan** -- After generating phases, show the plan summary and ask: "Approve this plan?", "Adjust scope?", "Regenerate with different focus?"
+2. **Before starting a build wave** -- Before spawning workers, confirm: "Start building phase N?", "Review tasks first?", "Skip to a different phase?"
+3. **After verification** -- When continue finishes verifying, present results and ask: "Advance to next phase?", "Re-run this phase?", "Pause and review?"
+4. **Before advancing phases** -- Before moving the phase pointer forward, confirm the user is satisfied with the current state.
+
+## How to Ask
+
+Use AskUserQuestion with 2-4 options. Follow these rules strictly:
+
+- **Plain English only** -- No jargon, no technical IDs, no internal state names.
+- **Short options** -- Each option should be 3-8 words. The user wants to click, not read paragraphs.
+- **Explain consequences** -- Each option must briefly state what happens if selected. Example: "Start building (spawns 3 workers)" not just "Start building".
+- **Default is obvious** -- The most common/expected action should be the first option.
+- **Never auto-proceed** -- If you cannot present options (e.g., non-interactive mode), log that you would have paused and continue with the default action. Note this in output.
+
+## Question Format Template
+
+```
+[Decision Point Name]
+What would you like to do?
+
+1. [Most likely action] -- [what happens]
+2. [Alternative action] -- [what happens]
+3. [Conservative action] -- [what happens]
+```
+
+## Anti-Patterns to Avoid
+
+- Running an entire build-verify-advance cycle without any user confirmation.
+- Asking yes/no questions when richer options exist (prefer 3 options over 2).
+- Asking technical questions the user cannot answer ("Which serialization format?").
+- Presenting options that require code knowledge to evaluate.
+
+## Integration with Autopilot
+
+When running under `/ant:run` (autopilot mode), interaction touchpoints are relaxed -- autopilot handles the build-verify-advance loop. But smart-pause conditions still apply: test failures, security issues, quality gate failures, and replan suggestions all trigger a pause that requires user input.

package/.aether/skills/colony/colony-lifecycle/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: colony-lifecycle
+description: Use when producing command output, handling state transitions, or routing users to the next action in the colony workflow
+type: colony
+domains: [lifecycle, routing, workflow, state]
+agent_roles: [builder, watcher, route_setter, architect]
+priority: normal
+version: "1.0"
+---
+
+# Colony Lifecycle
+
+## Purpose
+
+Every command must leave the user with a clear next action. No dead ends. The colony has a defined state machine, and every output must orient the user within it.
+
+## State Machine
+
+The colony progresses through these states in order:
+
+```
+IDLE -> READY -> PLANNING -> EXECUTING -> SEALED -> ENTOMBED -> IDLE
+```
+
+| State | Meaning | Entered By | Next Action |
+|-------|---------|------------|-------------|
+| IDLE | No active colony | Default / after entomb | `/ant:init` |
+| READY | Colony initialized, no plan | `/ant:init` | `/ant:plan` |
+| PLANNING | Plan being generated | `/ant:plan` | `/ant:build 1` |
+| EXECUTING | Phases being built | `/ant:build` | `/ant:continue` |
+| SEALED | Colony marked complete | `/ant:seal` | `/ant:entomb` |
+| ENTOMBED | Colony archived | `/ant:entomb` | `/ant:init` (new goal) |
+
+## Next Up Block
+
+Every command output must end with a "Next Up" block. This block tells the user exactly what to do next based on the current state.
+
+### Format
+
+```
+━━ N E X T   U P ━━
+Run /ant:continue to verify work and advance to the next phase.
+```
+
+### Rules
+
+- Always include the exact command to run, with any arguments.
+- If multiple valid next actions exist, list the primary one first, then alternatives.
+- Match the Next Up to the current state -- never suggest a command that is invalid for the current state.
+- After seal, suggest entomb. After entomb, suggest init with a new goal.
+- Never output a command result without a Next Up block.
+
+### State-Specific Next Up Examples
+
+| Current State | Primary Next Up | Alternatives |
+|---------------|-----------------|--------------|
+| READY | `/ant:plan` | `/ant:colonize` (if existing code) |
+| PLANNING | `/ant:build 1` | `/ant:focus` / `/ant:redirect` (to set signals first) |
+| EXECUTING (just built) | `/ant:continue` | `/ant:status` (to review) |
+| EXECUTING (just verified) | `/ant:build N+1` | `/ant:seal` (if last phase) |
+| SEALED | `/ant:entomb` | -- |
+| ENTOMBED | `/ant:init "new goal"` | -- |
+
+## Command Chaining Awareness
+
+Commands feed into each other. When producing output, be aware of what the previous command was and what the next one expects:
+
+- `init` creates state that `plan` reads.
+- `plan` creates phases that `build` executes.
+- `build` creates artifacts that `continue` verifies.
+- `continue` advances state that the next `build` reads.
+
+If a command detects that prerequisite state is missing (e.g., `build` called with no plan), display a clear error explaining what to run first, not a cryptic failure message.
+
+## Dead End Prevention
+
+Before finalizing any command output, check: "Does this output end with a Next Up block?" If not, add one. There are zero valid cases where a command should leave the user without guidance on what to do next.

package/.aether/skills/colony/colony-visuals/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: colony-visuals
+description: Use when producing any user-facing output including banners, progress indicators, section headers, or command results
+type: colony
+domains: [visuals, ux, formatting]
+agent_roles: [builder, watcher, chronicler, scout]
+priority: normal
+version: "1.0"
+---
+
+# Colony Visuals
+
+## Purpose
+
+All colony output must look consistent. Users should never see mismatched banner styles, missing progress bars, or unformatted raw output. This skill standardizes every visual element.
+
+## Banner Format
+
+Use spaced-letter format for all section banners. The standard pattern is:
+
+```
+━━ S E C T I O N   T I T L E ━━
+```
+
+Rules:
+- Every letter is separated by a single space.
+- Words are separated by three spaces.
+- Bordered by `━━` on both sides with a single space between the border and text.
+- Use `print-standard-banner` utility when available. If unavailable, format manually following this pattern exactly.
+- Never use alternative banner styles (e.g., `===`, `###`, `***`, `---` banners).
+
+## Progress Bars
+
+Always use the `generate-progress-bar` utility for progress indicators. Never construct progress bars manually with characters like `[=====>    ]`.
+
+Format: `[Phase 3/7] ████████░░░░ 57%`
+
+Show progress bars:
+- At the start of each phase build.
+- After each worker completes during a build wave.
+- In status dashboard output.
+
+## Output Block Structure
+
+Every command output follows this three-part structure:
+
+1. **Header banner** -- Spaced-letter banner identifying the command or section.
+2. **Content** -- The actual information, tables, results, or status.
+3. **Next Up footer** -- What the user should do next (see colony-lifecycle skill).
+
+Wrap content sections in `━━━` dividers (3+ characters) for visual separation.
+
+## Emoji Usage
+
+- **One emoji per section header** -- Place it before the section title text.
+- **Never use emoji in body text** -- Keep body text clean and professional.
+- **Consistent emoji mapping** -- Use the same emoji for the same concept across all commands. Examples: build, test, verify, complete, warning, error.
+
+## Tables
+
+When presenting structured data, use aligned markdown tables:
+
+```
+| Column 1 | Column 2 | Status |
+|----------|----------|--------|
+| value    | value    | done   |
+```
+
+Ensure columns are padded for alignment. Never use unaligned or ragged tables.
+
+## Color and Emphasis
+
+- **Bold** for labels and headings.
+- *Italic* for supplementary notes.
+- Use color sparingly and consistently -- green for success, red for errors, yellow for warnings.
+
+## Emoji Reference Map
+
+This is the canonical reference for emoji usage across all Aether commands. All commands must use these emojis consistently for the concepts listed below.
+
+| Emoji | Concept | Used In |
+|-------|---------|---------|
+| 🔨 | Builder ant | build.md, workers.md |
+| 👁️ | Watcher ant | build.md, continue.md |
+| 🎲 | Chaos ant | build.md |
+| 🔍 | Scout ant | build.md |
+| 🏺 | Archaeologist / Seal | archaeology.md, seal.md |
+| 🔮 | Oracle ant | oracle.md, build.md |
+| 🏛️ | Architect ant | build.md |
+| 🔌 | Ambassador ant | build.md |
+| 📊 | Measurer ant / Status | measurer, status.md |
+| 🧪 | Probe / Tests | continue.md |
+| 🔄 | Weaver / Refresh | continue.md |
+| 📦 | Gatekeeper / Package | continue.md |
+| 👥 | Auditor | continue.md |
+| 🚩 | Flag / Blocker | flags.md |
+| 💭 | Dream | dream.md |
+| 🥚 | Queen / Init | lay-eggs.md |
+| 📋 | Plan / List | plan.md |
+| ✅ | Pass / Success | verification |
+| ❌ | Fail / Error | verification |
+| ⚠️ | Warning | gates |
+| ⛔ | Hard block | gates |
+| 💾 | Save / Persist | pause.md |
+| 🎯 | Focus signal | pheromones |
+| 🚫 | Redirect signal | pheromones |
+| 💬 | Feedback signal | pheromones |
+| 📜 | Sage ant | seal.md |
+| 📝 | Chronicler ant | seal.md |
+| 🖼️ | Visual checkpoint | build-complete.md |
+
+> **Canonical reference:** When adding emoji to any user-facing command output, use this table as the definitive guide. Do not introduce new emoji for concepts already covered here. If a new concept requires an emoji, add it to this table first.

package/.aether/skills/colony/context-management/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: context-management
+description: Use when performing state-changing operations, recovering sessions, creating handoffs, or managing context freshness
+type: colony
+domains: [context, session, recovery, state]
+agent_roles: [builder, watcher, scout, architect]
+priority: normal
+version: "1.0"
+---
+
+# Context Management
+
+## Purpose
+
+Colony context must stay fresh and recoverable. When sessions break, context is the bridge that lets the next session pick up without losing progress. This skill teaches you how to maintain that bridge.
+
+## After State-Changing Operations
+
+Any operation that modifies colony state must update context. State-changing operations include:
+
+- Phase advances (current_phase changes)
+- Task completion (task status changes)
+- Instinct creation or promotion
+- Pheromone signal creation, reinforcement, or expiration
+- Blocker flags raised or resolved
+- Plan regeneration
+
+After each of these, call `context-update` to write the current state summary to CONTEXT.md. This ensures the context file always reflects reality.
+
+## File Freshness Verification
+
+Before reading state files (COLONY_STATE.json, pheromones.json, session.json), verify freshness using `session-verify-fresh`:
+
+- If the file is stale (older than the current session), treat data with caution.
+- For protected commands (init, seal, entomb), never auto-clear stale files -- prompt the user.
+- For other commands, auto-clear stale session files and log that you did so.
+
+Freshness matters because state files from a previous session may contain outdated phase pointers, resolved blockers, or expired signals that would mislead the current session.
+
+## HANDOFF.md Requirements
+
+When creating a handoff (via `/ant:pause-colony` or session end), HANDOFF.md must include all five sections:
+
+1. **Goal** -- The active colony goal, exactly as stated in COLONY_STATE.json.
+2. **Phase** -- Current phase number and name, plus completion percentage.
+3. **Signals** -- All active pheromone signals with their types and strengths.
+4. **Blockers** -- Any active blocker flags, including who raised them and why.
+5. **Next Step** -- The exact command to run next and what it will do.
+
+Missing any of these sections makes recovery harder. If a section has no content (e.g., no blockers), include it with "None" rather than omitting it.
+
+## Session Recovery Fallback Chain
+
+When resuming, follow this fallback chain:
+
+1. **HANDOFF.md** (preferred) -- Richest context, includes signals and blockers.
+2. **CONTEXT.md + COLONY_STATE.json** (fallback) -- Reconstruct from state files if no handoff exists.
+3. **COLONY_STATE.json alone** (last resort) -- Minimal recovery, may miss recent changes.
+
+Always tell the user which recovery source you used: "Restored from HANDOFF.md" or "No handoff found, recovered from state files."
+
+## Context at Natural Break Points
+
+At natural breaks (phase completion, verification pass, seal), prompt the user to consider clearing context if the conversation has been long:
+
+```
+This session has been running for a while. Consider running /ant:pause-colony
+to save state, then start fresh with /ant:resume-colony.
+```
+
+This helps prevent context window degradation in long sessions.
+
+## CONTEXT.md Content
+
+CONTEXT.md should contain a concise summary (not a full dump) of:
+- Active goal and current phase
+- Recent completions (last 2-3 tasks)
+- Active signals (type and content only, not full JSON)
+- Known blockers
+- Recommended next action

package/.aether/skills/colony/error-presentation/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: error-presentation
+description: Use when an operation fails, an error occurs, or a warning needs to be communicated to the user
+type: colony
+domains: [errors, ux, formatting, diagnostics]
+agent_roles: [builder, watcher, scout]
+priority: normal
+version: "1.0"
+---
+
+# Error Presentation
+
+## Purpose
+
+Errors deserve the same visual care as successes. When something goes wrong, the user should see a clear, formatted explanation -- not a raw stack trace or cryptic error code. This skill ensures error output matches the quality of success output.
+
+## Error Output Format
+
+Every error must follow this four-part structure:
+
+### 1. Error Banner
+
+Use the standard spaced-letter banner format:
+
+```
+━━ E R R O R ━━
+```
+
+For warnings (non-fatal issues):
+
+```
+━━ W A R N I N G ━━
+```
+
+### 2. Plain-English Description
+
+Explain what went wrong in one or two sentences that a non-technical person could understand.
+
+Good: "The build failed because a test file could not be found."
+Bad: "ENOENT: no such file or directory, open '/path/to/test.spec.js'"
+
+Never show raw error messages, stack traces, file paths, or error codes to the user. If technical details are needed for debugging, include them in a collapsed or secondary section, not the main message.
+
+### 3. What Is Being Done
+
+Tell the user what the system is doing about the error:
+
+- "Retrying with an alternative approach..."
+- "Logging this failure for colony learning."
+- "Rolling back to the last known good state."
+
+If nothing can be done automatically, say so clearly: "This requires manual intervention."
+
+### 4. User Action
+
+End with specific, actionable steps the user can take:
+
+```
+What you can do:
+- Run /ant:status to see the current state
+- Run /ant:build 3 to retry this phase
+- Run /ant:flag "blocked on X" to mark a blocker
+```
+
+Always provide at least one actionable command. Never end an error with just "Something went wrong."
+
+## Error Grouping
+
+When multiple related errors occur (e.g., 5 tests fail in the same module), group them:
+
+```
+━━ E R R O R ━━
+3 tests failed in the authentication module:
+- Login with expired token
+- Password reset flow
+- Session refresh
+
+Common cause: The auth service mock is not configured.
+```
+
+Never dump errors one by one when they share a root cause. Grouping helps the user see the pattern.
+
+## Error Severity Levels
+
+| Level | Banner | When |
+|-------|--------|------|
+| Error | `━━ E R R O R ━━` | Operation failed, cannot proceed |
+| Warning | `━━ W A R N I N G ━━` | Something is off but work continues |
+| Notice | `━━ N O T I C E ━━` | Informational, no action needed |
+
+Use the right level. Do not call everything an error -- warnings and notices exist for a reason.
+
+## Anti-Patterns
+
+- Showing raw JSON error responses to the user.
+- Displaying file paths without explaining what the file is.
+- Using technical jargon: "mutex deadlock", "race condition", "null pointer".
+- Ending error output without a Next Up or action block.
+- Formatting errors as plain text when successes get rich formatting.

package/.aether/skills/colony/pheromone-protocol/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: pheromone-protocol
+description: Use when pheromone signals are present in your assembled context and you need to interpret and comply with them
+type: colony
+domains: [pheromones, protocol, signals, compliance]
+agent_roles: [builder, watcher, scout, chaos, oracle, architect, colonizer, route_setter, archaeologist, chronicler, keeper, tracker, probe, weaver, auditor, gatekeeper, includer, measurer, sage, ambassador]
+priority: normal
+version: "1.0"
+---
+
+# Pheromone Protocol
+
+## Purpose
+
+Pheromone signals are the colony's steering mechanism. Every agent must know how to read, interpret, and comply with them. This skill standardizes signal handling across all 22 agent roles.
+
+## Signal Types and Required Response
+
+### REDIRECT -- Hard Constraint
+
+REDIRECT signals are non-negotiable. You MUST comply.
+
+- If a REDIRECT says "avoid pattern X", you must not use pattern X in any code you write, any recommendation you make, or any approach you take.
+- REDIRECTs marked `[error-pattern]` come from repeated colony failures (midden threshold). These are lessons learned the hard way -- treat them with extra seriousness.
+- If complying with a REDIRECT conflicts with your task, report the conflict as a blocker rather than violating the REDIRECT.
+- In your output, explicitly acknowledge each REDIRECT and state how you complied.
+
+### FOCUS -- Prioritize This Area
+
+FOCUS signals direct your attention. You SHOULD prioritize.
+
+- When choosing between approaches, prefer the one aligned with active FOCUS signals.
+- FOCUS areas receive extra effort: more thorough analysis, additional test coverage, deeper investigation.
+- If your task touches a FOCUS area, give it proportionally more attention than non-focused areas.
+- You may deprioritize (but not ignore) non-focused areas to spend more time on focused ones.
+
+### FEEDBACK -- Preference Adjustment
+
+FEEDBACK signals are calibration from past experience. You may incorporate flexibly.
+
+- Use FEEDBACK to adjust patterns: coding style, naming conventions, architectural preferences.
+- You may deviate from FEEDBACK with good reason, but note the deviation in your output.
+- FEEDBACK accumulates -- multiple FEEDBACK signals pointing the same direction carry more weight than a single one.
+
+## Role-Specific Adaptations
+
+Different roles adapt signal handling to their function:
+
+| Role | REDIRECT Adaptation | FOCUS Adaptation |
+|------|-------------------|-----------------|
+| Builder | Avoid flagged patterns in code | Write extra tests for focused areas |
+| Watcher | Flag violations in review | Deeper checks on focused areas |
+| Scout | Exclude flagged approaches from research | Prioritize focused topics |
+| Chaos | Test flagged patterns for regression | Focus chaos testing on focused areas |
+| Route Setter | Exclude flagged approaches from plans | Weight focused areas in phase design |
+| Architect | Reject designs using flagged patterns | Center architecture around focused areas |
+
+All other roles follow the general protocol above.
+
+## Compliance Reporting
+
+In your output summary, include a signal compliance section:
+
+```
+Signal Compliance:
+- REDIRECT "no inline styles": Complied -- used Tailwind utility classes throughout
+- FOCUS "security": Applied -- added input validation to all endpoints
+- FEEDBACK "prefer composition": Followed -- used composition pattern for new components
+```
+
+If no signals were present in your context, note: "No active pheromone signals."
+
+## Signal Absence
+
+If your context contains no pheromone signals section, this means either:
+- No signals are currently active (normal for new colonies).
+- The signals section was trimmed for token budget (normal under compact mode).
+
+In either case, proceed with your task using default judgment. Do not treat signal absence as an error.

package/.aether/skills/colony/pheromone-visibility/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: pheromone-visibility
+description: Use when performing any pheromone operation including creating, reinforcing, expiring, or auto-emitting signals during builds and continues
+type: colony
+domains: [pheromones, visibility, ux]
+agent_roles: [builder, watcher, scout]
+priority: normal
+version: "1.0"
+---
+
+# Pheromone Visibility
+
+## Purpose
+
+Pheromone operations must never happen silently. Users need to see exactly what signals are being created, reinforced, expired, or auto-emitted. Every signal change is an opportunity to build user trust in the colony system.
+
+## Mandatory Visibility Rules
+
+Every pheromone operation must produce a user-visible output line. No exceptions.
+
+### Signal Creation
+
+When a new signal is created, display:
+
+```
+FOCUS emitted: "area description" [initial strength%]
+REDIRECT emitted: "constraint description" [initial strength%]
+FEEDBACK emitted: "observation" [initial strength%]
+```
+
+### Signal Reinforcement
+
+When an existing signal is reinforced (duplicate content detected), display:
+
+```
+FOCUS reinforced: "area description" [new strength%] (x3 reinforcements)
+```
+
+### Signal Expiration
+
+When a signal expires due to decay or phase change, display:
+
+```
+FOCUS expired: "area description" (was active for 3 phases)
+```
+
+### Auto-Emission
+
+During builds and continues, the system auto-emits signals based on decisions and learnings. Each auto-emission must be visible:
+
+```
+Auto-emitted FEEDBACK: "prefer composition over inheritance" [70%]
+```
+
+## Signal Changes Summary
+
+At the end of every `/ant:continue` execution, display a "Signal Changes" summary table:
+
+```
+━━ S I G N A L   C H A N G E S ━━
+
+| Signal  | Action     | Content              | Strength |
+|---------|------------|----------------------|----------|
+| FOCUS   | created    | "security"           | 85%      |
+| REDIRECT| reinforced | "no inline styles"   | 95%      |
+| FEEDBACK| expired    | "prefer dark theme"  | 0%       |
+
+Active signals: 5 | Created: 1 | Reinforced: 1 | Expired: 1
+```
+
+If no signal changes occurred, still display the section with "No signal changes this cycle."
+
+## Integration Points
+
+- **During build** (build-wave): Show each auto-emitted signal as it happens, inline with worker output.
+- **During continue** (continue-verify, continue-advance): Collect all changes and present the summary table at the end.
+- **During seal**: Show which signals are being promoted to eternal memory or hive.
+
+## Why This Matters
+
+Without visibility, pheromone evolution feels like magic -- the user cannot learn what signals do, cannot predict behavior, and cannot trust the system to act on their guidance. Making every operation visible turns the pheromone system from an opaque mechanism into a transparent feedback loop.