jumbo-cli 1.0.1 → 2.0.1

package/assets/skills/define-jumbo-goals/SKILL.md

@@ -0,0 +1,193 @@
+---
+name: define-jumbo-goals
+description: Use when defining new Jumbo goals from user requests. Guides discovery, decomposition, and goal authoring to produce goals with explicit implementation instructions that minimize token usage during autonomous execution.
+---
+
+# Define Jumbo Goals
+
+**Prompt:** Analyze a user request, discover the architectural context required, decompose the work into right-sized goals, and author each goal with precise objectives, verifiable criteria, and explicit scope — so that refinement and implementation proceed with minimal exploration overhead.
+
+## Why Definition Quality Matters
+
+A goal's definition determines everything downstream. During refinement, the agent registers relations based on the objective and criteria. During implementation, `jumbo goal start` assembles context from those relations into an implementation prompt. Vague objectives produce vague relations. Vague relations produce bloated or incomplete context. The implementing agent then wastes tokens exploring what should have been stated upfront, or worse, builds the wrong thing.
+
+**The goal definition is the spec.** Treat it with the rigor of a technical specification, not a backlog item.
+
+## Protocol
+
+### 1. Understand the Request
+
+Extract the user's intent through conversation. Identify:
+
+- **What** needs to change (feature, fix, refactor, infrastructure)
+- **Why** it needs to change (user problem, tech debt, prerequisite for other work)
+- **Constraints** the user cares about (performance, compatibility, patterns to follow)
+
+If the request is ambiguous, ask clarifying questions before proceeding. Do not guess intent.
+
+### 2. Discover Architectural Context
+
+Before writing any goal, survey the project to understand what exists:
+
+```bash
+jumbo architecture view
+jumbo components search --query "<relevant domain terms>"
+jumbo components search --type <likely-type>
+jumbo invariants list
+jumbo guidelines list
+jumbo decisions list
+jumbo dependencies list
+```
+
+This discovery serves two purposes:
+- **Inform decomposition**: Understanding the system's boundaries, patterns, and constraints reveals the natural seams along which to split work.
+- **Inform criteria**: Existing invariants, decisions, and patterns dictate what "correct" looks like.
+
+Also explore the codebase directly to understand current implementation:
+
+```bash
+# Find relevant source files
+# Read key files to understand existing patterns
+# Identify integration points and boundaries
+```
+
+### 3. Decompose into Right-Sized Goals
+
+A goal is **right-sized** when:
+
+- It produces a **shippable increment** — the codebase is better after this goal alone, even if later goals are never started.
+- It can be **implemented in a single session** — an agent can start and complete it without context compaction.
+- It has a **clear boundary** — scope-in and scope-out can be stated without hedging.
+- It touches **one architectural concern** — avoid goals that mix, e.g., domain modeling with UI work with infrastructure changes.
+
+**Decomposition heuristics:**
+
+| Signal | Action |
+|--------|--------|
+| Work spans multiple bounded contexts or layers | Split by context/layer |
+| Work requires a new abstraction before feature code | Split: abstraction goal first, feature goal second |
+| Work has independent sub-deliverables | Split into parallel goals (no prerequisite chain) |
+| Work has sequential dependencies | Split into chained goals (use `--previous-goal` / `--next-goal`) |
+| Work is a single focused change | Keep as one goal |
+
+**Sequencing tools:**
+
+- `--prerequisite-goals <ids>`: Hard dependency — goal cannot start until prerequisites are complete.
+- `--previous-goal <id>` / `--next-goal <id>`: Suggested ordering — chains goals for sequential flow.
+
+### 4. Author Each Goal
+
+For each goal, compose the three pillars: **objective**, **criteria**, and **scope**.
+
+#### Objective
+
+The objective is a single sentence that answers: "What is being built or changed, and why?"
+
+| Quality | Example |
+|---------|---------|
+| BAD | "Implement telemetry" |
+| BAD | "Add PostHog integration for tracking" |
+| GOOD | "Add anonymous usage telemetry to the CLI using PostHog so we can understand which commands are used and where failures occur" |
+
+Rules:
+- State the **what** and the **why** in one sentence.
+- Name specific technologies, patterns, or components when known.
+- Do not describe how — that belongs in criteria.
+
+#### Success Criteria
+
+Each criterion is a **verifiable statement** that the reviewing agent can confirm by reading code or running tests. Criteria are the implementation instructions in disguise.
+
+| Quality | Example |
+|---------|---------|
+| BAD | "Telemetry works" |
+| BAD | "Good test coverage" |
+| GOOD | "Application layer defines a TelemetryPort interface with `trackEvent(name, properties)` and `identify(anonymousId)` methods" |
+| GOOD | "Infrastructure adapter implements TelemetryPort using PostHog Node SDK with fire-and-forget sends that never block the CLI event loop" |
+| GOOD | "First-run consent prompt stores preference in `~/.config/jumbo/telemetry.json` with schema `{ enabled: boolean, promptedAt: string }`" |
+
+Rules:
+- Each criterion describes a **single verifiable outcome**.
+- Name specific types, methods, file locations, schemas, or behaviors.
+- Make criteria **architecture-aware** — reference the project's patterns (ports/adapters, event sourcing, CQRS) when the implementation must conform.
+- Order criteria from foundational to dependent — the implementing agent reads them top to bottom.
+- Include a testing criterion — specify what tests exist and what they verify.
+- If a refactoring skill applies, add `skill:<skill-name>` as a criterion.
+
+**Criteria count guidance:**
+- Trivial goal (rename, config change): 2-3 criteria
+- Standard goal (new feature, refactor): 5-8 criteria
+- Complex goal (cross-cutting concern): 8-12 criteria
+
+#### Scope
+
+Scope tells the implementing agent where to work and where not to touch.
+
+```bash
+--scope-in "src/application/telemetry/" "src/infrastructure/posthog/" "src/cli/commands/config.ts"
+--scope-out "src/domain/" "src/infrastructure/persistence/"
+```
+
+Rules:
+- Use **file paths or directory prefixes**, not abstract descriptions.
+- `scope-in` lists files/directories that WILL be created or modified.
+- `scope-out` lists files/directories that MUST NOT be modified (protects unrelated code).
+- When creating new files, include the intended path in scope-in even though it does not exist yet.
+- Scope-out is especially valuable for goals that touch shared infrastructure — it prevents the agent from "fixing" unrelated code.
+
+### 5. Register the Goal
+
+Run `jumbo goal add --help` to confirm current flags and syntax before registering. Pass the objective, criteria, scope, and sequencing flags composed in the previous steps.
+
+For multi-goal decompositions, register goals in dependency order so that sequencing flags can reference already-created IDs.
+
+#### Goal Chaining with Previous/Next Goals
+
+The `--previous-goal` and `--next-goal` flags create a **chain** — an ordered sequence of goals that an agent works through end-to-end. Chaining is distinct from prerequisites:
+
+- **Prerequisites** (`--prerequisite-goals`) are hard gates — a goal cannot start until its prerequisites are complete.
+- **Chains** (`--previous-goal` / `--next-goal`) are navigational — when the agent finishes one goal, the chain tells it what to pick up next without the user intervening.
+
+Chaining is the primary mechanism for **long-running autonomous sessions without context rot.** Each goal in the chain carries its own focused context assembled at start time. When the agent completes goal A and transitions to goal B, `jumbo goal start` assembles fresh, relevant context for B — discarding the accumulated noise from A's implementation. The agent effectively gets a clean context window scoped precisely to the next unit of work, without losing the benefits of sequential execution.
+
+**When to chain:**
+- Work decomposes into ordered steps where each builds on the prior (e.g., "define port abstraction" → "implement adapter" → "wire into CLI").
+- The user wants to hand off a multi-goal workstream and return when it is all done.
+- The combined work would exceed comfortable context limits if attempted as a single goal.
+
+**When NOT to chain:**
+- Goals are independent and can be worked in any order — leave them unchained so the agent (or user) can prioritize freely.
+- Goals have hard dependencies where failure of one invalidates the next — use `--prerequisite-goals` instead, which enforces completion before start.
+
+### 6. Verify Before Handing Off
+
+After all goals are registered, verify:
+
+- [ ] Every goal has a clear, specific objective with what + why
+- [ ] Every goal has criteria that an agent can verify by reading code
+- [ ] Every goal has scope-in that matches the files it will touch
+- [ ] Scope-out protects areas adjacent to scope-in that should not change
+- [ ] Goal sequencing reflects actual dependencies (not just aesthetic ordering)
+- [ ] No single goal is so large it risks context compaction during implementation
+- [ ] No goal duplicates work from another goal
+- [ ] The full set of goals covers the user's original request completely
+
+## Anti-Patterns
+
+| Anti-Pattern | Problem | Fix |
+|--------------|---------|-----|
+| "Implement feature X" as sole criterion | Agent has no spec, explores and guesses | Break into 5-8 specific verifiable outcomes |
+| Scope-in says "src/" | Everything is in scope, nothing is protected | List specific directories and files |
+| No scope-out | Agent may refactor neighboring code | Explicitly exclude adjacent areas |
+| Goal mixes domain + infrastructure + tests | Too broad, risks compaction | Split by architectural layer |
+| Criteria reference "should" or "ideally" | Ambiguous — pass or fail? | Rewrite as binary verifiable statements |
+| 15+ criteria on one goal | Goal is too large | Decompose into multiple goals |
+| No testing criterion | Agent skips tests | Always include what tests must exist |
+
+## Rules
+
+1. **Never register a goal without discovery.** Always explore the architecture, components, and constraints before writing objectives and criteria. Definition without context produces goals that fight the architecture.
+2. **Never write criteria the reviewing agent cannot verify.** If a criterion requires subjective judgment ("clean code", "good performance"), replace it with a measurable statement ("no function exceeds 30 lines", "response time under 200ms for 1000 records").
+3. **Never skip scope.** Every goal must have scope-in. Most goals should have scope-out. Unbounded scope invites unbounded implementation.
+4. **Always decompose before defining.** Resist the urge to create one large goal. Think in shippable increments.
+5. **Always verify goal coverage.** The union of all goals must fully address the user's request. Gaps between goals are gaps in delivery.

package/assets/skills/refine-jumbo-goals/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: refine-jumbo-goals
+description: Use when Jumbo goals need refinement before implementation. Curates relations to project entities so the implementing agent receives optimal architectural context.
+---
+
+# Refine Jumbo Goals
+
+**Prompt:** Refine one or more Jumbo goals by registering comprehensive relations to project entities so that an autonomous agent has optimal context for correct implementation.
+
+## Why Refinement Matters
+
+When `jumbo goal start` is run, the goal's registered relations determine what context is assembled and provided to the implementing agent. Missing relations mean missing constraints, patterns, or domain knowledge. Irrelevant relations waste tokens and dilute focus. Thorough refinement is the single highest-leverage activity for autonomous goal execution quality.
+
+## Protocol
+
+### 1. Initiate Refinement
+
+```bash
+jumbo goal refine --id <goal-id>
+```
+
+Review the goal's objective, criteria, and scope.
+
+### 2. Explore All Project Entities
+
+You MUST explore ALL entity categories to build a complete picture of available entities:
+
+```bash
+jumbo invariants list
+jumbo guidelines list
+jumbo decisions list
+jumbo dependencies list
+jumbo architecture view
+```
+
+For **components**, use targeted searches instead of dumping the full list. Extract keywords from the goal's objective and criteria, then search:
+
+```bash
+# Search by name (substring or wildcard)
+jumbo components search --name "Auth*"
+jumbo components search --name "*Gateway"
+
+# Search by type
+jumbo components search --type service
+jumbo components search --type lib
+
+# Free-text search across description and responsibility
+jumbo components search --query "event handling"
+
+# Compact output for quick discovery (id, name, type only)
+jumbo components search --output compact --type service
+
+# Combine filters (AND logic)
+jumbo components search --name "*Controller" --type service
+```
+
+Run multiple targeted searches derived from the goal's domain. Only fall back to `jumbo components list` if searches are insufficient to identify all relevant components.
+
+Do not skip any entity category. Every category is a potential source of implementation context.
+
+### 3. Evaluate Every Entity Against the Goal
+
+For each entity returned, ask: **"Will the implementing agent need to know about this to execute correctly?"**
+
+Only register relations that are directly relevant. Do not register entities that are tangentially related or that add context without actionable value.
+
+Evaluate systematically by category:
+
+- **Invariants**: Which non-negotiable constraints does this implementation touch, cross, or risk violating?
+- **Guidelines**: Which coding standards, testing requirements, or process practices apply?
+- **Decisions**: Which architectural decisions inform, motivate, or constrain this change?
+- **Components**: Which system components will be created, modified, deleted, or depended upon?
+- **Dependencies**: Which external libraries are involved in the implementation?
+
+### 4. Register Relations
+
+For every relevant entity, register a relation:
+
+```bash
+jumbo relation add \
+  --from-type goal \
+  --from-id <goal-id> \
+  --to-type <entity-type> \
+  --to-id <entity-id> \
+  --relation-type <type> \
+  --description "<why this relation matters for implementation>"
+```
+
+**Relation types:**
+
+| Type | Use When |
+|------|----------|
+| `involves` | Implementation will modify or directly interact with this entity |
+| `uses` | Implementation depends on or references this entity |
+| `must-respect` | Implementation must adhere to this constraint or decision |
+| `follows` | Implementation must follow this practice or standard |
+| `implements` | Implementation applies or realizes this architectural decision |
+
+**Description quality is critical.** The description is what the implementing agent reads. It must explain the specific relevance to this goal, not just restate the entity's title.
+
+- BAD: "Related to this invariant"
+- BAD: "Must follow this guideline"
+- GOOD: "Removal must not leave orphaned registrations or broken import paths across layer boundaries"
+- GOOD: "Ensure the read-side query path remains intact after removing the old handler"
+
+### 5. Update Goal Metadata
+
+During entity exploration, you may discover:
+- Additional files that belong in scope
+- Files that should be created or modified
+- Risk of scope creep
+- Success criteria that need updating
+- Applicable refactoring skills to reference in criteria (prefix with `skill:`)
+- Registered goals that should be added as prerequisites or follow-ups
+
+Update the goal accordingly:
+
+```bash
+jumbo goal update --id <goal-id> \
+  --criteria "Updated criteria" \
+  --scope-in "additional/file/path.ts" \
+  --scope-out "namespace/" "a/file/to-not-touch.ts" \
+  --previous-goal <previous-goal-id> \
+  --next-goal <next-goal-id> \
+  --prerequisite-goals <goalIds...>
+```
+
+### 6. Verify Completeness
+
+Before approving, verify ALL of the following:
+
+- [ ] Every entity category was explored (no categories skipped)
+- [ ] Relevant invariants are linked (most goals require 2+ invariant relations)
+- [ ] Testing-related guidelines are linked (almost every goal has testing implications)
+- [ ] Architectural decisions that inform or constrain the approach are linked
+- [ ] All components being modified, created, deleted, or depended upon are linked
+- [ ] Every relation description explains the specific relevance, not just the entity name
+- [ ] Goal criteria and scope reflect any discoveries made during refinement
+- [ ] The goal has at least 5 relations total (fewer suggests incomplete analysis)
+
+### 7. Approve Refinement
+
+Only after completing all verification checks:
+
+```bash
+jumbo goal refine --id <goal-id> --approve
+```
+
+## Rules
+
+1. **Never approve with fewer than 5 relations** unless the goal is trivially scoped. If you cannot find 5 relevant entities, re-examine your analysis.
+2. **Never skip an entity category.** Explore all entity types every time. For components, prefer targeted `jumbo components search` queries over `jumbo components list`. Entity registrations change between sessions.
+3. **Never write vague descriptions.** Every relation description must be actionable guidance for the implementing agent.
+4. **Always link testing guidelines.** Implementation without testing context produces untested code.
+5. **Always link components that prove safety.** When deleting or replacing code, link the replacement component so the agent can verify the change is safe.
+6. **Treat skill references as first-class criteria.** If a refactoring skill applies, add `skill:<skill-name>` to the goal's criteria so the implementing agent loads it.

package/assets/skills/reject-jumbo-goal/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: reject-jumbo-goal
+description: Use when a Jumbo goal fails QA review and needs to be returned for rework. Records review issues and routes the goal back to the implementing agent with actionable feedback.
+---
+
+# Reject Jumbo Goal
+
+**Prompt:** Reject a Jumbo goal that failed QA review, recording the specific issues found so the implementing agent can address them and restart.
+
+## Why Rejection Quality Matters
+
+When a goal is rejected, the implementing agent receives the review issues as its primary guidance for rework. Vague or incomplete rejection feedback causes wasted rework cycles — the agent guesses at what's wrong, fixes the wrong things, and resubmits with the same issues. Precise, actionable rejection feedback is the fastest path to a passing review.
+
+## Protocol
+
+### 1. Document Review Issues
+
+Before rejecting, ensure you have a clear, specific list of every issue found during QA review. Each issue must be:
+
+- **Specific**: Reference exact files, functions, or behaviors that are wrong.
+- **Actionable**: Describe what needs to change, not just what's wrong.
+- **Traceable**: Link back to the success criterion, invariant, or guideline that was violated.
+
+### 2. Reject the Goal
+
+```bash
+jumbo goal reject --id <goal-id> --issues "<detailed review issues>"
+```
+
+The rejection output confirms:
+- The goal ID and objective
+- The goal's status (returned to a reworkable state)
+- The review issues recorded for the implementing agent
+
+### 3. Communicate Next Steps
+
+After rejection, the implementing agent should:
+
+1. Address every review issue documented in the rejection.
+2. Restart the goal to reload context:
+   ```bash
+   jumbo goal start --id <goal-id>
+   ```
+3. Re-implement the fixes within the original scope and constraints.
+4. Resubmit for review:
+   ```bash
+   jumbo goal submit --id <goal-id>
+   ```
+
+If a next goal is queued, its ID will be displayed for reference, but the rejected goal takes priority.
+
+## Rules
+
+1. **Never reject without specific issues.** Every rejection must include actionable feedback the implementing agent can act on.
+2. **Never combine rejection with rework.** The rejecting agent reviews; the implementing agent fixes. Do not attempt both roles.
+3. **Always reference violated criteria.** Tie each issue back to a success criterion, invariant, or guideline so the implementing agent understands the standard.
+4. **Keep issues structured.** Use numbered or bulleted lists. One issue per point. No walls of text.
+5. **Never reject for out-of-scope concerns.** Only reject for issues within the goal's defined scope and criteria.

package/assets/skills/review-jumbo-goal/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: review-jumbo-goal
+description: Use when a Jumbo goal needs QA review after implementation. Runs the review protocol, verifies every objective, criterion, and related entity constraint, and approves the goal for codification or rejects it with feedback.
+---
+
+# Review Jumbo Goal
+
+**Prompt:** Review a completed Jumbo goal implementation against its objective, success criteria, scope, and all related architectural context. Approve the goal if no issue are found, otherwise document the issues and reject the goal.
+
+## Why Review Matters
+
+`jumbo goal review` assembles the goal's full context — objective, criteria, scope, architecture, components, decisions, invariants, and guidelines — into a QA verification prompt. A thorough review catches deviations before they compound. A lazy review lets defects ship.
+
+## Protocol
+
+### 1. Initiate Review
+
+```bash
+jumbo goal review --id <goal-id>
+```
+
+Read the entire output carefully. It contains the verification criteria assembled from the goal's relations.
+
+### 2. Verify Objective and Success Criteria
+
+For each success criterion listed in the output:
+
+1. Locate the implementation artifacts that satisfy it
+2. Read the relevant code
+3. Confirm the criterion is **fully** met — not partially, not approximately
+
+If ANY criterion is not met: add the issues to a list for feedback.
+
+### 3. Verify Scope Compliance
+
+If the review output includes scope sections:
+
+- **In Scope**: Confirm all work was done within the listed files/areas. No under-delivery.
+- **Out of Scope**: Confirm no work leaked into excluded areas. No over-delivery.
+
+If scope is violated: add the issues to the feedback list.
+
+### 4. Verify Architecture Alignment
+
+If the review output includes architecture:
+
+- **Organization style**: Do new namespaces and file names match the solution's architectural organization?
+- **Design patterns**: Were prescribed patterns applied where applicable?
+- **Principles**: Do all new artifacts reflect the listed principles?
+
+If architecture is misaligned: add the issues to the feedback list.
+
+### 5. Verify Related Entities
+
+For each category in the review output:
+
+- **Components**: Were all listed components properly considered? Are interactions correct?
+- **Dependencies**: Are dependency contracts respected?
+- **Decisions**: Is the implementation consistent with listed architectural decisions?
+- **Invariants**: Does the implementation adhere to every listed invariant? This is non-negotiable.
+- **Guidelines**: Does the implementation follow listed guidelines?
+
+If ANY entity constraint is violated: add the issues to the feedback list.
+
+### 6. Run Tests
+
+```bash
+npm test
+```
+
+All tests must pass. If tests fail: add the issues to the feedback list.
+
+### 7. Qualify or Re-Review
+
+**If ALL checks pass** (criteria, scope, architecture, entities, tests):
+
+```bash
+jumbo goal approve --id <goal-id>
+```
+
+**If ANY check failed**:
+
+```bash
+jumbo goal reject --id <goal-id> --audit-findings <list of issues>
+```
+
+
+## Rules
+
+1. **Never approve with unresolved failures.** Every criterion, invariant, and test must pass before approving.
+2. **Never skip entity categories.** Review output includes entities for a reason — each was registered during refinement as essential context.
+3. **Always run tests.** Implementation without passing tests is incomplete.
+4. **Document issues clearly.** When rejecting a goal, provide detailed feedback for each failure.
+5. **Read the code, don't assume.** Verify each criterion by reading actual implementation, not by recalling what you wrote.

package/assets/skills/start-jumbo-goal/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: start-jumbo-goal
+description: Use when starting a Jumbo goal. Loads goal context, scope, and architectural constraints, then guides the agent through disciplined execution within defined boundaries.
+---
+
+# Start Jumbo Goal
+
+**Prompt:** Start a Jumbo goal by loading its full context — objective, criteria, scope, architecture, components, decisions, invariants, and guidelines — then execute within the defined boundaries.
+
+## Why Structured Implementation Matters
+
+When `jumbo goal start` is run, it assembles the goal's registered relations into structured implementation instructions. The objective defines what to build. The criteria define how success is measured. The scope defines boundaries. The architectural context (components, decisions, invariants, guidelines) defines constraints. Deviating from these instructions produces work that fails QA review.
+
+## Protocol
+
+### 1. Start the Goal
+
+```bash
+jumbo goal start --id <goal-id>
+```
+
+This loads the full goal context. Read and internalize every section of the output before writing any code.
+
+### 2. Understand the Implementation Instructions
+
+The goal start output contains structured sections. Each section carries binding instructions:
+
+#### Objective
+The single purpose of this goal. All work must serve this objective.
+
+#### Success Criteria
+The specific, measurable conditions that determine whether the objective is met. Implementation is not complete until every criterion is satisfied.
+
+#### Current Progress (if resuming)
+If the goal was previously started, review what has already been accomplished and continue from there. Do not redo completed work.
+
+#### Scope
+- **In Scope**: Files and areas you MUST work within.
+- **Out of Scope**: Files and areas you MUST NOT touch.
+
+#### Solution Architecture
+- **Organization Style**: Namespaces (directory structures) and file names you introduce MUST maintain this style.
+- **Design Patterns**: You MUST leverage these patterns where applicable. If the goal requires a pattern not listed, register it with `jumbo architecture update`.
+- **Principles**: Artifacts you create MUST directly reflect these principles.
+
+#### Relevant Components
+Components that will be modified, created, or depended upon. Consider these while implementing.
+
+#### Relevant Dependencies
+External libraries involved in the implementation. Consider version constraints and contracts.
+
+#### Relevant Decisions
+Previous architectural decisions that inform or constrain this change. The solution must remain consistent with these decisions.
+
+#### Invariants
+Non-negotiable constraints. You MUST adhere to ALL invariants while implementing.
+
+#### Guidelines
+Coding standards, testing requirements, and process practices. You SHOULD follow these while implementing.
+
+### 3. Execute Within Scope
+
+- Work only within the defined scope boundaries.
+- Follow all architectural constraints, invariants, and guidelines.
+- Track progress by documenting completed sub-tasks:
+
+```bash
+jumbo goal update-progress --id <goal-id> --task-description "<description>"
+```
+
+### 4. Submit for Review
+
+When all success criteria are met and implementation is complete:
+
+```bash
+jumbo goal submit --id <goal-id>
+```
+
+## Rules
+
+1. **Never deviate from the objective.** All code changes must serve the stated objective.
+2. **Never violate scope boundaries.** In-scope files are your workspace. Out-of-scope files are off limits.
+3. **Never violate invariants.** Invariants are non-negotiable constraints — no exceptions.
+4. **Always track progress.** Use `jumbo goal update-progress` to document completed sub-tasks so future agents can resume if needed.
+5. **Always submit when done.** Do not close or codify the goal yourself. Submit it for QA review.
+6. **Do not enter plan mode for refined goals.** The goal context IS the plan. Execute immediately.

package/assets/vscode-logo.svg

@@ -0,0 +1,41 @@
+<svg width="100" height="100" viewBox="0 0 100 100" fill="none" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0" mask-type="alpha" maskUnits="userSpaceOnUse" x="0" y="0" width="100" height="100">
+<path fill-rule="evenodd" clip-rule="evenodd" d="M70.9119 99.3171C72.4869 99.9307 74.2828 99.8914 75.8725 99.1264L96.4608 89.2197C98.6242 88.1787 100 85.9892 100 83.5872V16.4133C100 14.0113 98.6243 11.8218 96.4609 10.7808L75.8725 0.873756C73.7862 -0.130129 71.3446 0.11576 69.5135 1.44695C69.252 1.63711 69.0028 1.84943 68.769 2.08341L29.3551 38.0415L12.1872 25.0096C10.589 23.7965 8.35363 23.8959 6.86933 25.2461L1.36303 30.2549C-0.452552 31.9064 -0.454633 34.7627 1.35853 36.417L16.2471 50.0001L1.35853 63.5832C-0.454633 65.2374 -0.452552 68.0938 1.36303 69.7453L6.86933 74.7541C8.35363 76.1043 10.589 76.2037 12.1872 74.9905L29.3551 61.9587L68.769 97.9167C69.3925 98.5406 70.1246 99.0104 70.9119 99.3171ZM75.0152 27.2989L45.1091 50.0001L75.0152 72.7012V27.2989Z" fill="white"/>
+</mask>
+<g mask="url(#mask0)">
+<path d="M96.4614 10.7962L75.8569 0.875542C73.4719 -0.272773 70.6217 0.211611 68.75 2.08333L1.29858 63.5832C-0.515693 65.2373 -0.513607 68.0937 1.30308 69.7452L6.81272 74.754C8.29793 76.1042 10.5347 76.2036 12.1338 74.9905L93.3609 13.3699C96.086 11.3026 100 13.2462 100 16.6667V16.4275C100 14.0265 98.6246 11.8378 96.4614 10.7962Z" fill="#0065A9"/>
+<g filter="url(#filter0_d)">
+<path d="M96.4614 89.2038L75.8569 99.1245C73.4719 100.273 70.6217 99.7884 68.75 97.9167L1.29858 36.4169C-0.515693 34.7627 -0.513607 31.9063 1.30308 30.2548L6.81272 25.246C8.29793 23.8958 10.5347 23.7964 12.1338 25.0095L93.3609 86.6301C96.086 88.6974 100 86.7538 100 83.3334V83.5726C100 85.9735 98.6246 88.1622 96.4614 89.2038Z" fill="#007ACC"/>
+</g>
+<g filter="url(#filter1_d)">
+<path d="M75.8578 99.1263C73.4721 100.274 70.6219 99.7885 68.75 97.9166C71.0564 100.223 75 98.5895 75 95.3278V4.67213C75 1.41039 71.0564 -0.223106 68.75 2.08329C70.6219 0.211402 73.4721 -0.273666 75.8578 0.873633L96.4587 10.7807C98.6234 11.8217 100 14.0112 100 16.4132V83.5871C100 85.9891 98.6234 88.1786 96.4586 89.2196L75.8578 99.1263Z" fill="#1F9CF0"/>
+</g>
+<g style="mix-blend-mode:overlay" opacity="0.25">
+<path fill-rule="evenodd" clip-rule="evenodd" d="M70.8511 99.3171C72.4261 99.9306 74.2221 99.8913 75.8117 99.1264L96.4 89.2197C98.5634 88.1787 99.9392 85.9892 99.9392 83.5871V16.4133C99.9392 14.0112 98.5635 11.8217 96.4001 10.7807L75.8117 0.873695C73.7255 -0.13019 71.2838 0.115699 69.4527 1.44688C69.1912 1.63705 68.942 1.84937 68.7082 2.08335L29.2943 38.0414L12.1264 25.0096C10.5283 23.7964 8.29285 23.8959 6.80855 25.246L1.30225 30.2548C-0.513334 31.9064 -0.515415 34.7627 1.29775 36.4169L16.1863 50L1.29775 63.5832C-0.515415 65.2374 -0.513334 68.0937 1.30225 69.7452L6.80855 74.754C8.29285 76.1042 10.5283 76.2036 12.1264 74.9905L29.2943 61.9586L68.7082 97.9167C69.3317 98.5405 70.0638 99.0104 70.8511 99.3171ZM74.9544 27.2989L45.0483 50L74.9544 72.7012V27.2989Z" fill="url(#paint0_linear)"/>
+</g>
+</g>
+<defs>
+<filter id="filter0_d" x="-8.39411" y="15.8291" width="116.727" height="92.2456" filterUnits="userSpaceOnUse" color-interpolation-filters="sRGB">
+<feFlood flood-opacity="0" result="BackgroundImageFix"/>
+<feColorMatrix in="SourceAlpha" type="matrix" values="0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 127 0"/>
+<feOffset/>
+<feGaussianBlur stdDeviation="4.16667"/>
+<feColorMatrix type="matrix" values="0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.25 0"/>
+<feBlend mode="overlay" in2="BackgroundImageFix" result="effect1_dropShadow"/>
+<feBlend mode="normal" in="SourceGraphic" in2="effect1_dropShadow" result="shape"/>
+</filter>
+<filter id="filter1_d" x="60.4167" y="-8.07558" width="47.9167" height="116.151" filterUnits="userSpaceOnUse" color-interpolation-filters="sRGB">
+<feFlood flood-opacity="0" result="BackgroundImageFix"/>
+<feColorMatrix in="SourceAlpha" type="matrix" values="0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 127 0"/>
+<feOffset/>
+<feGaussianBlur stdDeviation="4.16667"/>
+<feColorMatrix type="matrix" values="0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.25 0"/>
+<feBlend mode="overlay" in2="BackgroundImageFix" result="effect1_dropShadow"/>
+<feBlend mode="normal" in="SourceGraphic" in2="effect1_dropShadow" result="shape"/>
+</filter>
+<linearGradient id="paint0_linear" x1="49.9392" y1="0.257812" x2="49.9392" y2="99.7423" gradientUnits="userSpaceOnUse">
+<stop stop-color="white"/>
+<stop offset="1" stop-color="white" stop-opacity="0"/>
+</linearGradient>
+</defs>
+</svg>

package/assets/warp-logo.svg

@@ -0,0 +1 @@
+<svg role="img" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><title>Warp</title><path d="M12.035 2.723h9.253A2.712 2.712 0 0 1 24 5.435v10.529a2.712 2.712 0 0 1-2.712 2.713H8.047Zm-1.681 2.6L6.766 19.677h5.598l-.399 1.6H2.712A2.712 2.712 0 0 1 0 18.565V8.036a2.712 2.712 0 0 1 2.712-2.712Z"/></svg>

package/dist/application/ISolutionContextReader.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"ISolutionContextReader.d.ts","sourceRoot":"","sources":["../../src/application/ISolutionContextReader.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,mBAAmB,EAAE,MAAM,0BAA0B,CAAC;AAE/D;;;;;;GAMG;AACH,MAAM,WAAW,sBAAsB;IACrC;;;;OAIG;IACH,kBAAkB,IAAI,OAAO,CAAC,mBAAmB,CAAC,CAAC;CACpD"}

package/dist/application/ISolutionContextReader.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"ISolutionContextReader.js","sourceRoot":"","sources":["../../src/application/ISolutionContextReader.ts"],"names":[],"mappings":""}