commit pi sessions
This commit is contained in:
liph
@@ -0,0 +1,52 @@
|
||||
# Task for ollama-orchestrator
|
||||
|
||||
"list every file in the current
|
||||
directory and tell me which one is most likely to contain a bug"
|
||||
|
||||
## Acceptance Contract
|
||||
Acceptance level: attested
|
||||
Completion is not accepted from prose alone. End with a structured acceptance report.
|
||||
|
||||
Criteria:
|
||||
- criterion-1: Return a concise result and residual risks when applicable
|
||||
|
||||
Required evidence: manual-notes, residual-risks
|
||||
|
||||
Finish with a fenced JSON block tagged `acceptance-report` in this shape:
|
||||
Use empty arrays when no items apply; array fields contain strings unless object entries are shown.
|
||||
```acceptance-report
|
||||
{
|
||||
"criteriaSatisfied": [
|
||||
{
|
||||
"id": "criterion-1",
|
||||
"status": "satisfied",
|
||||
"evidence": "specific proof"
|
||||
}
|
||||
],
|
||||
"changedFiles": [
|
||||
"src/file.ts"
|
||||
],
|
||||
"testsAddedOrUpdated": [
|
||||
"test/file.test.ts"
|
||||
],
|
||||
"commandsRun": [
|
||||
{
|
||||
"command": "command",
|
||||
"result": "passed",
|
||||
"summary": "short result"
|
||||
}
|
||||
],
|
||||
"validationOutput": [
|
||||
"validation output or concise summary"
|
||||
],
|
||||
"residualRisks": [
|
||||
"none"
|
||||
],
|
||||
"noStagedFiles": true,
|
||||
"diffSummary": "short description of the diff",
|
||||
"reviewFindings": [
|
||||
"blocker: file.ts:12 - issue found, or no blockers"
|
||||
],
|
||||
"manualNotes": "anything else the parent should know"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,37 @@
|
||||
{
|
||||
"runId": "187b7128",
|
||||
"agent": "ollama-orchestrator",
|
||||
"task": "\"list every file in the current\n directory and tell me which one is most likely to contain a bug\"",
|
||||
"exitCode": 0,
|
||||
"usage": {
|
||||
"input": 46741,
|
||||
"output": 3301,
|
||||
"cacheRead": 0,
|
||||
"cacheWrite": 0,
|
||||
"cost": 0,
|
||||
"turns": 5
|
||||
},
|
||||
"model": "ollama/minimax-m3:cloud:high",
|
||||
"attemptedModels": [
|
||||
"ollama/minimax-m3:cloud:high"
|
||||
],
|
||||
"modelAttempts": [
|
||||
{
|
||||
"model": "ollama/minimax-m3:cloud:high",
|
||||
"success": true,
|
||||
"exitCode": 0,
|
||||
"usage": {
|
||||
"input": 46741,
|
||||
"output": 3301,
|
||||
"cacheRead": 0,
|
||||
"cacheWrite": 0,
|
||||
"cost": 0,
|
||||
"turns": 5
|
||||
}
|
||||
}
|
||||
],
|
||||
"durationMs": 42304,
|
||||
"toolCount": 4,
|
||||
"transcriptPath": "/home/liph/dotfiles/pi/.pi/agent/.pi-subagents/artifacts/187b7128_ollama-orchestrator_0_transcript.jsonl",
|
||||
"timestamp": 1783169853950
|
||||
}
|
||||
@@ -0,0 +1,3 @@
|
||||
Done. Wrote the result to `orchestration.md` in the current directory.
|
||||
|
||||
**Summary:** Listed all 15 entries (5 directories + 10 files) in `/home/liph/dotfiles/pi/.pi/agent`. Picked **`settings.json`** as the file most likely to contain a bug — it is the single tightly-coupled config that wires packages, default model, and the entire `subagents.agentOverrides` map, so a single typo or stale model id cascades into every tool/agent call. Caveat: this is a heuristic judgment based on coupling, not measured evidence (no static analysis, test run, or git-history hot-spotting was performed), and subdirectories were listed but not inspected.
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,60 @@
|
||||
# Task for ollama-planner
|
||||
|
||||
You are a delegated subagent running from a fork of the parent session. Treat the inherited conversation as reference-only context, not a live thread to continue. Do not continue or answer prior messages as if they are waiting for a reply. Your sole job is to execute the task below and return a focused result for that task using your tools.
|
||||
|
||||
Task:
|
||||
"what can you plan ?"
|
||||
|
||||
---
|
||||
**Output:**
|
||||
Write your findings to exactly this path: /home/liph/dotfiles/pi/.pi/agent/agents/.pi-subagents/artifacts/outputs/4059014e/plan.md
|
||||
This path is authoritative for this run.
|
||||
Ignore any other output filename or output path mentioned elsewhere, including output destinations in the base agent prompt, system prompt, or task instructions.
|
||||
|
||||
## Acceptance Contract
|
||||
Acceptance level: checked
|
||||
Completion is not accepted from prose alone. End with a structured acceptance report.
|
||||
|
||||
Criteria:
|
||||
- criterion-1: Implement the requested change without widening scope
|
||||
|
||||
Required evidence: changed-files, tests-added, commands-run, residual-risks, no-staged-files
|
||||
|
||||
Finish with a fenced JSON block tagged `acceptance-report` in this shape:
|
||||
Use empty arrays when no items apply; array fields contain strings unless object entries are shown.
|
||||
```acceptance-report
|
||||
{
|
||||
"criteriaSatisfied": [
|
||||
{
|
||||
"id": "criterion-1",
|
||||
"status": "satisfied",
|
||||
"evidence": "specific proof"
|
||||
}
|
||||
],
|
||||
"changedFiles": [
|
||||
"src/file.ts"
|
||||
],
|
||||
"testsAddedOrUpdated": [
|
||||
"test/file.test.ts"
|
||||
],
|
||||
"commandsRun": [
|
||||
{
|
||||
"command": "command",
|
||||
"result": "passed",
|
||||
"summary": "short result"
|
||||
}
|
||||
],
|
||||
"validationOutput": [
|
||||
"validation output or concise summary"
|
||||
],
|
||||
"residualRisks": [
|
||||
"none"
|
||||
],
|
||||
"noStagedFiles": true,
|
||||
"diffSummary": "short description of the diff",
|
||||
"reviewFindings": [
|
||||
"blocker: file.ts:12 - issue found, or no blockers"
|
||||
],
|
||||
"manualNotes": "anything else the parent should know"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,37 @@
|
||||
{
|
||||
"runId": "4059014e",
|
||||
"agent": "ollama-planner",
|
||||
"task": "You are a delegated subagent running from a fork of the parent session. Treat the inherited conversation as reference-only context, not a live thread to continue. Do not continue or answer prior messages as if they are waiting for a reply. Your sole job is to execute the task below and return a focused result for that task using your tools.\n\nTask:\n\"what can you plan ?\"\n\n---\n**Output:**\nWrite your findings to exactly this path: /home/liph/dotfiles/pi/.pi/agent/agents/.pi-subagents/artifacts/outputs/4059014e/plan.md\nThis path is authoritative for this run.\nIgnore any other output filename or output path mentioned elsewhere, including output destinations in the base agent prompt, system prompt, or task instructions.",
|
||||
"exitCode": 0,
|
||||
"usage": {
|
||||
"input": 15536,
|
||||
"output": 3530,
|
||||
"cacheRead": 0,
|
||||
"cacheWrite": 0,
|
||||
"cost": 0,
|
||||
"turns": 3
|
||||
},
|
||||
"model": "ollama/minimax-m3:cloud:high",
|
||||
"attemptedModels": [
|
||||
"ollama/minimax-m3:cloud:high"
|
||||
],
|
||||
"modelAttempts": [
|
||||
{
|
||||
"model": "ollama/minimax-m3:cloud:high",
|
||||
"success": true,
|
||||
"exitCode": 0,
|
||||
"usage": {
|
||||
"input": 15536,
|
||||
"output": 3530,
|
||||
"cacheRead": 0,
|
||||
"cacheWrite": 0,
|
||||
"cost": 0,
|
||||
"turns": 3
|
||||
}
|
||||
}
|
||||
],
|
||||
"durationMs": 45809,
|
||||
"toolCount": 2,
|
||||
"transcriptPath": "/home/liph/dotfiles/pi/.pi/agent/agents/.pi-subagents/artifacts/4059014e_ollama-planner_0_transcript.jsonl",
|
||||
"timestamp": 1783167031499
|
||||
}
|
||||
@@ -0,0 +1,84 @@
|
||||
# Implementation Plan
|
||||
|
||||
## Goal
|
||||
Answer the meta-question "what can you plan?" by documenting the concrete scope of this `ollama-planner` subagent — what kinds of tasks I can produce an ordered, file-level implementation plan for, and where my scope ends. No code changes are produced; this document is the deliverable.
|
||||
|
||||
## Tasks
|
||||
This is a meta-question, not a code change request. The "plan" here is the capability description itself. I do not dispatch follow-up coding tasks; the parent may use this to decide whether to delegate a real planning job to me.
|
||||
|
||||
1. **Task 1 — Read context (already done)**
|
||||
- File: `/home/liph/dotfiles/pi/.pi/agent/agents/ollama-planner.md`
|
||||
- Changes: read my own role definition to ground the answer in my actual system prompt
|
||||
- Acceptance: confirmed I am a read-only planner paired with `ollama-coder`
|
||||
2. **Task 2 — Write capability summary to the required artifact path**
|
||||
- File: `/home/liph/dotfiles/pi/.pi/agent/agents/.pi-subagents/artifacts/outputs/4059014e/plan.md`
|
||||
- Changes: produce this document
|
||||
- Acceptance: file written, addresses the question concretely
|
||||
|
||||
## Files to Modify
|
||||
- None. This run is read-only and produces a single artifact.
|
||||
|
||||
## New Files
|
||||
- `agents/.pi-subagents/artifacts/outputs/4059014e/plan.md` — this capability summary (the deliverable)
|
||||
|
||||
## Dependencies
|
||||
- None. No follow-up `ollama-coder` dispatch is appropriate for a meta-question.
|
||||
|
||||
## Risks
|
||||
- Risk: user expected a code plan for some unstated real task. Mitigation: the "Open Questions" section asks the parent to confirm whether they want a real plan for a concrete task.
|
||||
- Risk: scope is misstated. Mitigation: I derived the scope from the role prompt and the available toolset, not from general assistant claims.
|
||||
|
||||
## What I can plan (in-scope)
|
||||
Concrete software-engineering deliverables where I can produce a file-level, ordered plan that `ollama-coder` can execute without re-deriving intent:
|
||||
|
||||
1. **Feature implementation** — new endpoints, UI panels, CLI flags, integrations. I name files, exact changes, and per-task acceptance checks.
|
||||
2. **Refactors** — extract module/class, rename, restructure a directory tree, decouple a dependency, move code across a package boundary.
|
||||
3. **Bug fixes with multi-file surface** — when the cause spans 2+ files, I plan the diagnostic + fix + regression test as ordered steps.
|
||||
4. **Migrations** — framework upgrades (e.g. React 18→19, Node 18→20), database schema migrations, codemod rollouts, lockfile/dep upgrades with breaking changes.
|
||||
5. **Test strategy and scaffolding** — which test files to add, which existing tests to update, fixtures, mocks, and what command to run for verification.
|
||||
6. **API design and contract changes** — request/response shape changes, version bumps, deprecation policy, and the diff plan across producer + consumers.
|
||||
7. **Build / CI / DevEx changes** — pipeline edits, new GitHub Actions, monorepo scripts, pre-commit hooks, dev-container / Nix changes.
|
||||
8. **Documentation and migration notes** — when paired with code changes, I can plan the README/changelog/runbook updates that must ship alongside.
|
||||
9. **Cross-cutting concerns as plans, not edits** — auth/authorization model, error-handling strategy, logging/observability rollout, feature-flag introduction.
|
||||
10. **Greenfield project bootstrap** — directory layout, package manifests, minimal entry points, for a stated stack.
|
||||
|
||||
For every plan I produce:
|
||||
- One ordered task list with file path, exact change, and a one-line acceptance check per task.
|
||||
- A "Files to Modify" / "New Files" inventory.
|
||||
- A "Dependencies" section so ordering is unambiguous.
|
||||
- A "Risks" section with mitigations.
|
||||
- A "Validation Contract" naming the commands/tests the coder must run and the evidence to return.
|
||||
|
||||
## Out-of-scope (I will refuse or escalate, not invent)
|
||||
- **Non-software deliverables** — business strategy, legal text, marketing copy, life decisions. If asked, I'll say so and ask the parent to re-route.
|
||||
- **Destructive operations without explicit confirmation** — `git push --force`, deleting branches, wiping data, dropping tables. I'll surface these as risks and ask before planning execution.
|
||||
- **Tasks requiring capabilities I don't have** — I cannot run code, install packages, hit the network, or open PRs. I can plan those actions; I cannot perform them.
|
||||
- **Ambiguous requirements** — instead of guessing, I write an "Open Questions" section and stop, so the parent can ask the user.
|
||||
|
||||
## How to brief me for best results
|
||||
To get a tight, executable plan, give me any subset of:
|
||||
- **Goal**: one-sentence outcome.
|
||||
- **Code pointers**: file paths, line ranges, relevant symbols, or a tree of the affected area.
|
||||
- **Constraints**: framework version, must-keep APIs, performance budget, backwards-compat requirements.
|
||||
- **Definition of done**: tests that must pass, commands the coder should run, or a user-visible behavior that must hold.
|
||||
- **Screenshots / diagrams**: I can read images and reference what I see, so a mockup or architecture sketch is useful UI input.
|
||||
|
||||
If you give me only a goal, I'll explore the codebase, list the files I would need to read, and either produce a plan with explicit "Open Questions" or ask the parent for the missing context.
|
||||
|
||||
## Format of what I produce
|
||||
Single `plan.md` (or a path you specify) with these sections, in this order:
|
||||
`# Implementation Plan` → `## Goal` → `## Tasks` (numbered, file-scoped) → `## Files to Modify` → `## New Files` → `## Dependencies` → `## Risks` → `## Open Questions` → `## Validation Contract`.
|
||||
|
||||
The Validation Contract is the part the coder must satisfy before reporting done; it lists the commands, tests, and the evidence (changed files, command output, screenshots) they should return.
|
||||
|
||||
## Open Questions
|
||||
1. Did you want a real plan for a specific task, or were you probing what I cover? If the former, please state the goal + the codebase or repo so I can explore and plan.
|
||||
2. Is there a stack/language/framework you want me to bias toward? (I am language-agnostic; explicit constraints produce tighter plans.)
|
||||
|
||||
## Validation Contract
|
||||
- **Behavior that must hold**: this `plan.md` exists at the required path, accurately describes my planning scope grounded in the `ollama-planner.md` role prompt, and ends with a structured acceptance report.
|
||||
- **Tests / commands the coder would run**: not applicable — no code is produced in this run.
|
||||
- **Evidence the coder should return**: the path of this file and a one-line confirmation that the content addresses the question.
|
||||
|
||||
---
|
||||
*No code was changed. No follow-up `ollama-coder` task was dispatched. This artifact is the deliverable.*
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,63 @@
|
||||
# Task for planner
|
||||
|
||||
You are a delegated subagent running from a fork of the parent session. Treat the inherited conversation as reference-only context, not a live thread to continue. Do not continue or answer prior messages as if they are waiting for a reply. Your sole job is to execute the task below and return a focused result for that task using your tools.
|
||||
|
||||
Task:
|
||||
can you plan a webpage for a candle company?
|
||||
|
||||
---
|
||||
**Output:**
|
||||
Write your findings to exactly this path: /home/liph/dotfiles/pi/.pi/.pi-subagents/artifacts/outputs/a22166b7/plan.md
|
||||
This path is authoritative for this run.
|
||||
Ignore any other output filename or output path mentioned elsewhere, including output destinations in the base agent prompt, system prompt, or task instructions.
|
||||
|
||||
## Acceptance Contract
|
||||
Acceptance level: attested
|
||||
Completion is not accepted from prose alone. End with a structured acceptance report.
|
||||
|
||||
Criteria:
|
||||
- criterion-1: Return a concise result and residual risks when applicable
|
||||
|
||||
Required evidence: manual-notes, residual-risks
|
||||
|
||||
Finish with a fenced JSON block tagged `acceptance-report` in this shape:
|
||||
Use empty arrays when no items apply; array fields contain strings unless object entries are shown.
|
||||
`criteriaSatisfied[].status` must be exactly one of: satisfied, not-satisfied, not-applicable.
|
||||
`commandsRun[].result` must be exactly one of: passed, failed, not-run.
|
||||
`manualNotes` and `notes` are optional strings; an empty string means no note and does not satisfy `manual-notes` evidence.
|
||||
```acceptance-report
|
||||
{
|
||||
"criteriaSatisfied": [
|
||||
{
|
||||
"id": "criterion-1",
|
||||
"status": "satisfied",
|
||||
"evidence": "specific proof"
|
||||
}
|
||||
],
|
||||
"changedFiles": [
|
||||
"src/file.ts"
|
||||
],
|
||||
"testsAddedOrUpdated": [
|
||||
"test/file.test.ts"
|
||||
],
|
||||
"commandsRun": [
|
||||
{
|
||||
"command": "command",
|
||||
"result": "passed",
|
||||
"summary": "short result"
|
||||
}
|
||||
],
|
||||
"validationOutput": [
|
||||
"validation output or concise summary"
|
||||
],
|
||||
"residualRisks": [
|
||||
"none"
|
||||
],
|
||||
"noStagedFiles": true,
|
||||
"diffSummary": "short description of the diff",
|
||||
"reviewFindings": [
|
||||
"blocker: file.ts:12 - issue found, or no blockers"
|
||||
],
|
||||
"manualNotes": "anything else the parent should know"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,124 @@
|
||||
{
|
||||
"runId": "a22166b7",
|
||||
"agent": "planner",
|
||||
"task": "You are a delegated subagent running from a fork of the parent session. Treat the inherited conversation as reference-only context, not a live thread to continue. Do not continue or answer prior messages as if they are waiting for a reply. Your sole job is to execute the task below and return a focused result for that task using your tools.\n\nTask:\ncan you plan a webpage for a candle company?\n\n---\n**Output:**\nWrite your findings to exactly this path: /home/liph/dotfiles/pi/.pi/.pi-subagents/artifacts/outputs/a22166b7/plan.md\nThis path is authoritative for this run.\nIgnore any other output filename or output path mentioned elsewhere, including output destinations in the base agent prompt, system prompt, or task instructions.",
|
||||
"exitCode": 0,
|
||||
"usage": {
|
||||
"input": 11073,
|
||||
"output": 3237,
|
||||
"cacheRead": 0,
|
||||
"cacheWrite": 0,
|
||||
"cost": 0,
|
||||
"turns": 3
|
||||
},
|
||||
"model": "ollama/minimax-m3:cloud:high",
|
||||
"attemptedModels": [
|
||||
"ollama/minimax-m3:cloud:high"
|
||||
],
|
||||
"modelAttempts": [
|
||||
{
|
||||
"model": "ollama/minimax-m3:cloud:high",
|
||||
"success": true,
|
||||
"exitCode": 0,
|
||||
"usage": {
|
||||
"input": 11073,
|
||||
"output": 3237,
|
||||
"cacheRead": 0,
|
||||
"cacheWrite": 0,
|
||||
"cost": 0,
|
||||
"turns": 3
|
||||
}
|
||||
}
|
||||
],
|
||||
"durationMs": 43577,
|
||||
"toolCount": 2,
|
||||
"acceptance": {
|
||||
"status": "attested",
|
||||
"explicit": false,
|
||||
"effectiveAcceptance": {
|
||||
"level": "attested",
|
||||
"explicit": false,
|
||||
"inferredReason": [
|
||||
"default lightweight attestation"
|
||||
],
|
||||
"criteria": [
|
||||
{
|
||||
"id": "criterion-1",
|
||||
"must": "Return a concise result and residual risks when applicable",
|
||||
"evidence": [
|
||||
"manual-notes",
|
||||
"residual-risks"
|
||||
],
|
||||
"severity": "required"
|
||||
}
|
||||
],
|
||||
"evidence": [
|
||||
"manual-notes",
|
||||
"residual-risks"
|
||||
],
|
||||
"verify": [],
|
||||
"stopRules": []
|
||||
},
|
||||
"inferredReason": [
|
||||
"default lightweight attestation"
|
||||
],
|
||||
"criteria": [
|
||||
{
|
||||
"id": "criterion-1",
|
||||
"must": "Return a concise result and residual risks when applicable",
|
||||
"evidence": [
|
||||
"manual-notes",
|
||||
"residual-risks"
|
||||
],
|
||||
"severity": "required"
|
||||
}
|
||||
],
|
||||
"runtimeChecks": [],
|
||||
"verifyRuns": [],
|
||||
"childReport": {
|
||||
"criteriaSatisfied": [
|
||||
{
|
||||
"id": "criterion-1",
|
||||
"status": "satisfied",
|
||||
"evidence": "Returned a concrete, ordered 12-task plan with exact files, acceptance criteria per task, dependencies, and an explicit residual-risks section covering brand/copy/commerce/legal gaps."
|
||||
}
|
||||
],
|
||||
"changedFiles": [
|
||||
"/home/liph/dotfiles/pi/.pi/.pi-subagents/artifacts/outputs/a22166b7/plan.md"
|
||||
],
|
||||
"testsAddedOrUpdated": [],
|
||||
"commandsRun": [
|
||||
{
|
||||
"command": "ls /home/liph/dotfiles/pi/.pi",
|
||||
"result": "passed",
|
||||
"summary": "Confirmed working directory before writing the plan artifact."
|
||||
},
|
||||
{
|
||||
"command": "write /home/liph/dotfiles/pi/.pi/.pi-subagents/artifacts/outputs/a22166b7/plan.md",
|
||||
"result": "passed",
|
||||
"summary": "Plan artifact written, 8771 bytes."
|
||||
}
|
||||
],
|
||||
"validationOutput": [
|
||||
"Plan structure validated: Goal, 12 Tasks (each with File/Changes/Acceptance), Files to Modify, New Files, Dependencies, Risks sections all present."
|
||||
],
|
||||
"residualRisks": [
|
||||
"Brand identity (name, palette, logo, voice) is not provided — plan uses 'Ember & Wick' placeholders.",
|
||||
"Product catalog data (SKUs, scent names, prices, imagery) is not provided — plan seeds 6 placeholder entries.",
|
||||
"Commerce model not specified — defaulted to Snipcart drop-in cart; needs owner confirmation (Shopify/Stripe/quote-only).",
|
||||
"Tech stack not specified — defaulted to Astro + Tailwind; React/Next or plain HTML alternative possible.",
|
||||
"Legal/compliance review still required: fragrance allergens, California Prop-65, and 'natural/eco' claims.",
|
||||
"Photography and web-font subsetting are likely performance/accessibility regression sources without owner-supplied assets."
|
||||
],
|
||||
"noStagedFiles": true,
|
||||
"diffSummary": "New plan file authored at artifacts/outputs/a22166b7/plan.md; no code or config changes.",
|
||||
"reviewFindings": [
|
||||
"no blockers",
|
||||
"Ambiguity: owner should confirm brand, commerce, and stack before implementation begins (see Risks in plan)."
|
||||
],
|
||||
"manualNotes": "Plan is intentionally framework-concrete (Astro) and scope-concrete (4 pages + contact API) to be executable; pivot is cheap before Task 1 (scaffold) runs. If owner prefers a single landing page with no commerce, Tasks 4, 6, 7, 9 can be collapsed into one Home page with a mailto form."
|
||||
}
|
||||
},
|
||||
"transcriptPath": "/home/liph/dotfiles/pi/.pi/.pi-subagents/artifacts/a22166b7_planner_0_transcript.jsonl",
|
||||
"timestamp": 1784832904248
|
||||
}
|
||||
@@ -0,0 +1,120 @@
|
||||
# Implementation Plan: Candle Company Marketing Webpage
|
||||
|
||||
## Goal
|
||||
Design and implement a single-page (or small multi-section) marketing website for a candle company that showcases products, brand story, and enables direct purchase or wholesale inquiries.
|
||||
|
||||
## Ambiguity to Resolve Before Coding
|
||||
The request is underspecified. Before implementation, the parent/owner should confirm the following (these are listed in **Risks** as well):
|
||||
- Company name, brand voice, color palette, and logo (or placeholders acceptable).
|
||||
- Product catalog: number of SKUs, scent names, prices, sizes, and imagery (or placeholders acceptable).
|
||||
- Commerce model: direct checkout (Shopify, Stripe, Snipcart) vs. "request a quote" / wholesale form vs. informational only.
|
||||
- Tech stack: plain HTML/CSS/JS, a static site generator (Astro, Eleventy, Hugo), or a React/Next.js app.
|
||||
- Hosting target: GitHub Pages, Netlify, Vercel, or self-hosted.
|
||||
- Pages required: single landing page, or Home / Shop / About / Contact split.
|
||||
- Compliance: any claims (e.g., "eco-friendly", "soy", "hand-poured") need substantiation; FDA/CPSC prop-65 warnings if marketed in CA.
|
||||
|
||||
Default assumptions (used to make the plan concrete; can be overridden):
|
||||
- **Stack**: Astro (static-first, SEO-friendly, easy to deploy to Netlify/Vercel).
|
||||
- **Scope**: Home, Shop, About, Contact — 4 routes plus a shared layout.
|
||||
- **Commerce**: Snipcart (drop-in cart) or a simple "Add to Cart" UI that posts to a hosted checkout. If the owner prefers no commerce, replace Shop with a product gallery and a Contact form.
|
||||
- **Brand**: placeholder name "Ember & Wick", warm neutral palette, serif display + sans body.
|
||||
- **Assets**: SVG placeholders for product imagery, real assets to be supplied later.
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
1. **Task 1: Scaffold project**
|
||||
- Files: `package.json`, `astro.config.mjs`, `tsconfig.json`, `.gitignore`, `README.md`.
|
||||
- Steps: `npm create astro@latest -- --template minimal --no-install`, add Tailwind via `npx astro add tailwind`, install Snipcart loader if commerce is in scope.
|
||||
- Acceptance: `npm run dev` serves a blank page at `http://localhost:4321`; `npm run build` produces `dist/`.
|
||||
|
||||
2. **Task 2: Define design tokens and global styles**
|
||||
- File: `src/styles/global.css` (or `tailwind.config.mjs` if using Tailwind).
|
||||
- Changes: palette (e.g., warm cream `#F6F1E7`, charcoal `#2B2A28`, ember `#C8553D`, wax `#E9DFC9`), typography scale (serif display, sans body), spacing scale, focus ring, reduced-motion media query.
|
||||
- Acceptance: Lighthouse contrast checks pass AA on body text and CTAs.
|
||||
|
||||
3. **Task 3: Build shared layout**
|
||||
- Files: `src/layouts/BaseLayout.astro`, `src/components/SiteHeader.astro`, `src/components/SiteFooter.astro`, `src/components/SeoHead.astro`.
|
||||
- Changes: sticky header with nav (Home / Shop / About / Contact), mobile hamburger, footer with newsletter signup (Mailchimp/Buttondown embed), SEO meta, Open Graph, favicon, JSON-LD `Organization` schema.
|
||||
- Acceptance: Header collapses to a working menu at <768px; OG image preview renders when sharing.
|
||||
|
||||
4. **Task 4: Author content collection for products**
|
||||
- Files: `src/content/config.ts`, `src/content/products/*.md` (one file per candle).
|
||||
- Changes: Zod schema with `name`, `slug`, `scentNotes` (top/heart/base), `burnHours`, `sizeOz`, `priceUSD`, `image`, `inStock`, `tags[]`. Seed with 6 placeholder SKUs.
|
||||
- Acceptance: `astro build` validates all entries; missing fields fail the build.
|
||||
|
||||
5. **Task 5: Home page**
|
||||
- File: `src/pages/index.astro`.
|
||||
- Sections: hero with brand tagline + CTA, "Best Sellers" carousel (3–6 products from collection), brand story teaser, Instagram/UGC grid (placeholder images), email capture, footer.
|
||||
- Acceptance: LCP < 2.5s on a simulated Fast 3G; hero CTA is keyboard-reachable.
|
||||
|
||||
6. **Task 6: Shop page**
|
||||
- File: `src/pages/shop.astro` plus `src/components/ProductCard.astro`, `src/components/ProductGrid.astro`, `src/components/FilterBar.astro`.
|
||||
- Changes: grid of `ProductCard`, client-side filter by `tags` (scent family, size), sort by price/name, "Add to Cart" button wired to Snipcart (or a placeholder alert if commerce out of scope).
|
||||
- Acceptance: filter/sort works with no layout shift; empty state when no results.
|
||||
|
||||
7. **Task 7: Product detail page**
|
||||
- File: `src/pages/shop/[slug].astro`.
|
||||
- Changes: large image, scent pyramid, burn time, ingredients, care instructions, related products, add-to-cart.
|
||||
- Acceptance: dynamic route generates one page per content entry; 404 for unknown slugs.
|
||||
|
||||
8. **Task 8: About page**
|
||||
- File: `src/pages/about.astro`.
|
||||
- Sections: founder story, process (sourcing, pouring, curing), sustainability claims (with citations where required), atelier/team photos.
|
||||
- Acceptance: every quantitative claim is either sourced or labeled as aspirational.
|
||||
|
||||
9. **Task 9: Contact / Wholesale page**
|
||||
- File: `src/pages/contact.astro`.
|
||||
- Changes: form fields (name, email, message, inquiry type: retail/wholesale/press), serverless handler (Astro endpoint `src/pages/api/contact.ts` posting to Resend or Formspree), inline validation, honeypot + Cloudflare Turnstile.
|
||||
- Acceptance: form rejects bots in staging; successful submission shows thank-you state and writes nothing to the client console.
|
||||
|
||||
10. **Task 10: Accessibility and performance pass**
|
||||
- Files: across components.
|
||||
- Changes: semantic landmarks, alt text on every `<img>`, `aria-live` for cart updates, focus management on mobile menu, lazy-load below-the-fold images (`loading="lazy"`, `decoding="async"`), preload hero image, self-host or subset fonts.
|
||||
- Acceptance: axe-core run via `npm run test:a11y` reports zero serious/critical issues; Lighthouse Performance ≥ 90, Accessibility ≥ 95 on the built site.
|
||||
|
||||
11. **Task 11: Analytics and consent**
|
||||
- File: `src/components/Analytics.astro`.
|
||||
- Changes: Plausible (cookieless, preferred) or GA4 with a cookie consent banner; respect `prefers-reduced-motion`.
|
||||
- Acceptance: no analytics scripts fire before consent; events tracked: `add_to_cart`, `view_item`, `form_submit`.
|
||||
|
||||
12. **Task 12: Deploy**
|
||||
- File: `netlify.toml` or `vercel.json`.
|
||||
- Changes: build command `npm run build`, publish `dist/`, security headers (CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy), redirects for trailing slashes.
|
||||
- Acceptance: preview deploy URL returns 200; security headers present in response.
|
||||
|
||||
---
|
||||
|
||||
## Files to Modify
|
||||
- `package.json` — add deps (`@astrojs/tailwind`, `astro`, `@astrojs/sitemap`, `snipcart` if used).
|
||||
- `astro.config.mjs` — integrations, site URL, sitemap, image service.
|
||||
- `src/styles/global.css` — tokens, base resets, typography.
|
||||
- `src/layouts/BaseLayout.astro` — shell, SEO, header, footer.
|
||||
- `src/components/*` — header, footer, product card, filter bar, analytics, seo head.
|
||||
- `src/pages/index.astro`, `src/pages/shop.astro`, `src/pages/shop/[slug].astro`, `src/pages/about.astro`, `src/pages/contact.astro`.
|
||||
- `src/pages/api/contact.ts` — form handler.
|
||||
- `src/content/config.ts` and `src/content/products/*.md` — product schema and seeds.
|
||||
|
||||
## New Files
|
||||
- `public/og-image.png`, `public/favicon.svg` — share assets.
|
||||
- `public/images/products/*.svg` — placeholder product imagery.
|
||||
- `src/env.d.ts` — Astro types.
|
||||
- `README.md` — run/build/deploy instructions and content authoring guide.
|
||||
|
||||
## Dependencies
|
||||
- Task 1 blocks all others.
|
||||
- Tasks 2 and 3 should land before 5–9.
|
||||
- Task 4 blocks Tasks 6 and 7.
|
||||
- Task 10 depends on every page being authored.
|
||||
- Task 12 depends on Task 10.
|
||||
|
||||
## Risks
|
||||
- **Underspecification**: brand name, palette, copy, product data, and commerce model are not provided. Plan defaults to placeholders; the owner should confirm before design polish.
|
||||
- **Compliance**: fragrance allergens (EU IFRA / US FDA), prop-65 in California, and "natural"/"eco" claims need legal review. Include a disclaimer block on product pages until cleared.
|
||||
- **Imagery**: stock or original photography significantly affects perceived quality; SVG placeholders look unfinished in production.
|
||||
- **Commerce integration**: Snipcart/Stripe accounts and tax/shipping configuration are external dependencies; budget setup time.
|
||||
- **Email deliverability**: domain DNS (SPF/DKIM/DMARC) must be set for the contact form and newsletter to avoid spam foldering.
|
||||
- **Performance budgets**: large hero images and web fonts are common regression sources; specify a max hero image size (e.g., 200 KB WebP/AVIF) and subset fonts.
|
||||
- **Accessibility regressions**: Snipcart's modal and the mobile menu are frequent focus-trap pitfalls; allocate explicit testing time.
|
||||
- **i18n**: if the brand sells internationally, currency, language, and date formatting need a strategy (Astro i18n routes or a future migration to a localized CMS).
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,120 @@
|
||||
# Implementation Plan: Candle Company Marketing Webpage
|
||||
|
||||
## Goal
|
||||
Design and implement a single-page (or small multi-section) marketing website for a candle company that showcases products, brand story, and enables direct purchase or wholesale inquiries.
|
||||
|
||||
## Ambiguity to Resolve Before Coding
|
||||
The request is underspecified. Before implementation, the parent/owner should confirm the following (these are listed in **Risks** as well):
|
||||
- Company name, brand voice, color palette, and logo (or placeholders acceptable).
|
||||
- Product catalog: number of SKUs, scent names, prices, sizes, and imagery (or placeholders acceptable).
|
||||
- Commerce model: direct checkout (Shopify, Stripe, Snipcart) vs. "request a quote" / wholesale form vs. informational only.
|
||||
- Tech stack: plain HTML/CSS/JS, a static site generator (Astro, Eleventy, Hugo), or a React/Next.js app.
|
||||
- Hosting target: GitHub Pages, Netlify, Vercel, or self-hosted.
|
||||
- Pages required: single landing page, or Home / Shop / About / Contact split.
|
||||
- Compliance: any claims (e.g., "eco-friendly", "soy", "hand-poured") need substantiation; FDA/CPSC prop-65 warnings if marketed in CA.
|
||||
|
||||
Default assumptions (used to make the plan concrete; can be overridden):
|
||||
- **Stack**: Astro (static-first, SEO-friendly, easy to deploy to Netlify/Vercel).
|
||||
- **Scope**: Home, Shop, About, Contact — 4 routes plus a shared layout.
|
||||
- **Commerce**: Snipcart (drop-in cart) or a simple "Add to Cart" UI that posts to a hosted checkout. If the owner prefers no commerce, replace Shop with a product gallery and a Contact form.
|
||||
- **Brand**: placeholder name "Ember & Wick", warm neutral palette, serif display + sans body.
|
||||
- **Assets**: SVG placeholders for product imagery, real assets to be supplied later.
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
1. **Task 1: Scaffold project**
|
||||
- Files: `package.json`, `astro.config.mjs`, `tsconfig.json`, `.gitignore`, `README.md`.
|
||||
- Steps: `npm create astro@latest -- --template minimal --no-install`, add Tailwind via `npx astro add tailwind`, install Snipcart loader if commerce is in scope.
|
||||
- Acceptance: `npm run dev` serves a blank page at `http://localhost:4321`; `npm run build` produces `dist/`.
|
||||
|
||||
2. **Task 2: Define design tokens and global styles**
|
||||
- File: `src/styles/global.css` (or `tailwind.config.mjs` if using Tailwind).
|
||||
- Changes: palette (e.g., warm cream `#F6F1E7`, charcoal `#2B2A28`, ember `#C8553D`, wax `#E9DFC9`), typography scale (serif display, sans body), spacing scale, focus ring, reduced-motion media query.
|
||||
- Acceptance: Lighthouse contrast checks pass AA on body text and CTAs.
|
||||
|
||||
3. **Task 3: Build shared layout**
|
||||
- Files: `src/layouts/BaseLayout.astro`, `src/components/SiteHeader.astro`, `src/components/SiteFooter.astro`, `src/components/SeoHead.astro`.
|
||||
- Changes: sticky header with nav (Home / Shop / About / Contact), mobile hamburger, footer with newsletter signup (Mailchimp/Buttondown embed), SEO meta, Open Graph, favicon, JSON-LD `Organization` schema.
|
||||
- Acceptance: Header collapses to a working menu at <768px; OG image preview renders when sharing.
|
||||
|
||||
4. **Task 4: Author content collection for products**
|
||||
- Files: `src/content/config.ts`, `src/content/products/*.md` (one file per candle).
|
||||
- Changes: Zod schema with `name`, `slug`, `scentNotes` (top/heart/base), `burnHours`, `sizeOz`, `priceUSD`, `image`, `inStock`, `tags[]`. Seed with 6 placeholder SKUs.
|
||||
- Acceptance: `astro build` validates all entries; missing fields fail the build.
|
||||
|
||||
5. **Task 5: Home page**
|
||||
- File: `src/pages/index.astro`.
|
||||
- Sections: hero with brand tagline + CTA, "Best Sellers" carousel (3–6 products from collection), brand story teaser, Instagram/UGC grid (placeholder images), email capture, footer.
|
||||
- Acceptance: LCP < 2.5s on a simulated Fast 3G; hero CTA is keyboard-reachable.
|
||||
|
||||
6. **Task 6: Shop page**
|
||||
- File: `src/pages/shop.astro` plus `src/components/ProductCard.astro`, `src/components/ProductGrid.astro`, `src/components/FilterBar.astro`.
|
||||
- Changes: grid of `ProductCard`, client-side filter by `tags` (scent family, size), sort by price/name, "Add to Cart" button wired to Snipcart (or a placeholder alert if commerce out of scope).
|
||||
- Acceptance: filter/sort works with no layout shift; empty state when no results.
|
||||
|
||||
7. **Task 7: Product detail page**
|
||||
- File: `src/pages/shop/[slug].astro`.
|
||||
- Changes: large image, scent pyramid, burn time, ingredients, care instructions, related products, add-to-cart.
|
||||
- Acceptance: dynamic route generates one page per content entry; 404 for unknown slugs.
|
||||
|
||||
8. **Task 8: About page**
|
||||
- File: `src/pages/about.astro`.
|
||||
- Sections: founder story, process (sourcing, pouring, curing), sustainability claims (with citations where required), atelier/team photos.
|
||||
- Acceptance: every quantitative claim is either sourced or labeled as aspirational.
|
||||
|
||||
9. **Task 9: Contact / Wholesale page**
|
||||
- File: `src/pages/contact.astro`.
|
||||
- Changes: form fields (name, email, message, inquiry type: retail/wholesale/press), serverless handler (Astro endpoint `src/pages/api/contact.ts` posting to Resend or Formspree), inline validation, honeypot + Cloudflare Turnstile.
|
||||
- Acceptance: form rejects bots in staging; successful submission shows thank-you state and writes nothing to the client console.
|
||||
|
||||
10. **Task 10: Accessibility and performance pass**
|
||||
- Files: across components.
|
||||
- Changes: semantic landmarks, alt text on every `<img>`, `aria-live` for cart updates, focus management on mobile menu, lazy-load below-the-fold images (`loading="lazy"`, `decoding="async"`), preload hero image, self-host or subset fonts.
|
||||
- Acceptance: axe-core run via `npm run test:a11y` reports zero serious/critical issues; Lighthouse Performance ≥ 90, Accessibility ≥ 95 on the built site.
|
||||
|
||||
11. **Task 11: Analytics and consent**
|
||||
- File: `src/components/Analytics.astro`.
|
||||
- Changes: Plausible (cookieless, preferred) or GA4 with a cookie consent banner; respect `prefers-reduced-motion`.
|
||||
- Acceptance: no analytics scripts fire before consent; events tracked: `add_to_cart`, `view_item`, `form_submit`.
|
||||
|
||||
12. **Task 12: Deploy**
|
||||
- File: `netlify.toml` or `vercel.json`.
|
||||
- Changes: build command `npm run build`, publish `dist/`, security headers (CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy), redirects for trailing slashes.
|
||||
- Acceptance: preview deploy URL returns 200; security headers present in response.
|
||||
|
||||
---
|
||||
|
||||
## Files to Modify
|
||||
- `package.json` — add deps (`@astrojs/tailwind`, `astro`, `@astrojs/sitemap`, `snipcart` if used).
|
||||
- `astro.config.mjs` — integrations, site URL, sitemap, image service.
|
||||
- `src/styles/global.css` — tokens, base resets, typography.
|
||||
- `src/layouts/BaseLayout.astro` — shell, SEO, header, footer.
|
||||
- `src/components/*` — header, footer, product card, filter bar, analytics, seo head.
|
||||
- `src/pages/index.astro`, `src/pages/shop.astro`, `src/pages/shop/[slug].astro`, `src/pages/about.astro`, `src/pages/contact.astro`.
|
||||
- `src/pages/api/contact.ts` — form handler.
|
||||
- `src/content/config.ts` and `src/content/products/*.md` — product schema and seeds.
|
||||
|
||||
## New Files
|
||||
- `public/og-image.png`, `public/favicon.svg` — share assets.
|
||||
- `public/images/products/*.svg` — placeholder product imagery.
|
||||
- `src/env.d.ts` — Astro types.
|
||||
- `README.md` — run/build/deploy instructions and content authoring guide.
|
||||
|
||||
## Dependencies
|
||||
- Task 1 blocks all others.
|
||||
- Tasks 2 and 3 should land before 5–9.
|
||||
- Task 4 blocks Tasks 6 and 7.
|
||||
- Task 10 depends on every page being authored.
|
||||
- Task 12 depends on Task 10.
|
||||
|
||||
## Risks
|
||||
- **Underspecification**: brand name, palette, copy, product data, and commerce model are not provided. Plan defaults to placeholders; the owner should confirm before design polish.
|
||||
- **Compliance**: fragrance allergens (EU IFRA / US FDA), prop-65 in California, and "natural"/"eco" claims need legal review. Include a disclaimer block on product pages until cleared.
|
||||
- **Imagery**: stock or original photography significantly affects perceived quality; SVG placeholders look unfinished in production.
|
||||
- **Commerce integration**: Snipcart/Stripe accounts and tax/shipping configuration are external dependencies; budget setup time.
|
||||
- **Email deliverability**: domain DNS (SPF/DKIM/DMARC) must be set for the contact form and newsletter to avoid spam foldering.
|
||||
- **Performance budgets**: large hero images and web fonts are common regression sources; specify a max hero image size (e.g., 200 KB WebP/AVIF) and subset fonts.
|
||||
- **Accessibility regressions**: Snipcart's modal and the mobile menu are frequent focus-trap pitfalls; allocate explicit testing time.
|
||||
- **i18n**: if the brand sells internationally, currency, language, and date formatting need a strategy (Astro i18n routes or a future migration to a localized CMS).
|
||||
@@ -0,0 +1,84 @@
|
||||
# Implementation Plan
|
||||
|
||||
## Goal
|
||||
Answer the meta-question "what can you plan?" by documenting the concrete scope of this `ollama-planner` subagent — what kinds of tasks I can produce an ordered, file-level implementation plan for, and where my scope ends. No code changes are produced; this document is the deliverable.
|
||||
|
||||
## Tasks
|
||||
This is a meta-question, not a code change request. The "plan" here is the capability description itself. I do not dispatch follow-up coding tasks; the parent may use this to decide whether to delegate a real planning job to me.
|
||||
|
||||
1. **Task 1 — Read context (already done)**
|
||||
- File: `/home/liph/dotfiles/pi/.pi/agent/agents/ollama-planner.md`
|
||||
- Changes: read my own role definition to ground the answer in my actual system prompt
|
||||
- Acceptance: confirmed I am a read-only planner paired with `ollama-coder`
|
||||
2. **Task 2 — Write capability summary to the required artifact path**
|
||||
- File: `/home/liph/dotfiles/pi/.pi/agent/agents/.pi-subagents/artifacts/outputs/4059014e/plan.md`
|
||||
- Changes: produce this document
|
||||
- Acceptance: file written, addresses the question concretely
|
||||
|
||||
## Files to Modify
|
||||
- None. This run is read-only and produces a single artifact.
|
||||
|
||||
## New Files
|
||||
- `agents/.pi-subagents/artifacts/outputs/4059014e/plan.md` — this capability summary (the deliverable)
|
||||
|
||||
## Dependencies
|
||||
- None. No follow-up `ollama-coder` dispatch is appropriate for a meta-question.
|
||||
|
||||
## Risks
|
||||
- Risk: user expected a code plan for some unstated real task. Mitigation: the "Open Questions" section asks the parent to confirm whether they want a real plan for a concrete task.
|
||||
- Risk: scope is misstated. Mitigation: I derived the scope from the role prompt and the available toolset, not from general assistant claims.
|
||||
|
||||
## What I can plan (in-scope)
|
||||
Concrete software-engineering deliverables where I can produce a file-level, ordered plan that `ollama-coder` can execute without re-deriving intent:
|
||||
|
||||
1. **Feature implementation** — new endpoints, UI panels, CLI flags, integrations. I name files, exact changes, and per-task acceptance checks.
|
||||
2. **Refactors** — extract module/class, rename, restructure a directory tree, decouple a dependency, move code across a package boundary.
|
||||
3. **Bug fixes with multi-file surface** — when the cause spans 2+ files, I plan the diagnostic + fix + regression test as ordered steps.
|
||||
4. **Migrations** — framework upgrades (e.g. React 18→19, Node 18→20), database schema migrations, codemod rollouts, lockfile/dep upgrades with breaking changes.
|
||||
5. **Test strategy and scaffolding** — which test files to add, which existing tests to update, fixtures, mocks, and what command to run for verification.
|
||||
6. **API design and contract changes** — request/response shape changes, version bumps, deprecation policy, and the diff plan across producer + consumers.
|
||||
7. **Build / CI / DevEx changes** — pipeline edits, new GitHub Actions, monorepo scripts, pre-commit hooks, dev-container / Nix changes.
|
||||
8. **Documentation and migration notes** — when paired with code changes, I can plan the README/changelog/runbook updates that must ship alongside.
|
||||
9. **Cross-cutting concerns as plans, not edits** — auth/authorization model, error-handling strategy, logging/observability rollout, feature-flag introduction.
|
||||
10. **Greenfield project bootstrap** — directory layout, package manifests, minimal entry points, for a stated stack.
|
||||
|
||||
For every plan I produce:
|
||||
- One ordered task list with file path, exact change, and a one-line acceptance check per task.
|
||||
- A "Files to Modify" / "New Files" inventory.
|
||||
- A "Dependencies" section so ordering is unambiguous.
|
||||
- A "Risks" section with mitigations.
|
||||
- A "Validation Contract" naming the commands/tests the coder must run and the evidence to return.
|
||||
|
||||
## Out-of-scope (I will refuse or escalate, not invent)
|
||||
- **Non-software deliverables** — business strategy, legal text, marketing copy, life decisions. If asked, I'll say so and ask the parent to re-route.
|
||||
- **Destructive operations without explicit confirmation** — `git push --force`, deleting branches, wiping data, dropping tables. I'll surface these as risks and ask before planning execution.
|
||||
- **Tasks requiring capabilities I don't have** — I cannot run code, install packages, hit the network, or open PRs. I can plan those actions; I cannot perform them.
|
||||
- **Ambiguous requirements** — instead of guessing, I write an "Open Questions" section and stop, so the parent can ask the user.
|
||||
|
||||
## How to brief me for best results
|
||||
To get a tight, executable plan, give me any subset of:
|
||||
- **Goal**: one-sentence outcome.
|
||||
- **Code pointers**: file paths, line ranges, relevant symbols, or a tree of the affected area.
|
||||
- **Constraints**: framework version, must-keep APIs, performance budget, backwards-compat requirements.
|
||||
- **Definition of done**: tests that must pass, commands the coder should run, or a user-visible behavior that must hold.
|
||||
- **Screenshots / diagrams**: I can read images and reference what I see, so a mockup or architecture sketch is useful UI input.
|
||||
|
||||
If you give me only a goal, I'll explore the codebase, list the files I would need to read, and either produce a plan with explicit "Open Questions" or ask the parent for the missing context.
|
||||
|
||||
## Format of what I produce
|
||||
Single `plan.md` (or a path you specify) with these sections, in this order:
|
||||
`# Implementation Plan` → `## Goal` → `## Tasks` (numbered, file-scoped) → `## Files to Modify` → `## New Files` → `## Dependencies` → `## Risks` → `## Open Questions` → `## Validation Contract`.
|
||||
|
||||
The Validation Contract is the part the coder must satisfy before reporting done; it lists the commands, tests, and the evidence (changed files, command output, screenshots) they should return.
|
||||
|
||||
## Open Questions
|
||||
1. Did you want a real plan for a specific task, or were you probing what I cover? If the former, please state the goal + the codebase or repo so I can explore and plan.
|
||||
2. Is there a stack/language/framework you want me to bias toward? (I am language-agnostic; explicit constraints produce tighter plans.)
|
||||
|
||||
## Validation Contract
|
||||
- **Behavior that must hold**: this `plan.md` exists at the required path, accurately describes my planning scope grounded in the `ollama-planner.md` role prompt, and ends with a structured acceptance report.
|
||||
- **Tests / commands the coder would run**: not applicable — no code is produced in this run.
|
||||
- **Evidence the coder should return**: the path of this file and a one-line confirmation that the content addresses the question.
|
||||
|
||||
---
|
||||
*No code was changed. No follow-up `ollama-coder` task was dispatched. This artifact is the deliverable.*
|
||||
Reference in New Issue
Block a user