@bvdm/delano 0.1.4 → 0.1.7

package/HANDBOOK.md

@@ -633,6 +633,7 @@ This keeps rapid learning without weakening team governance.
 
 **Primary components**
 
+- skill: `prototype-skill`
 - discovery artifacts from `spec.md`
 - targeted prototype commands or narrow experiments
 - `pm/validate.sh` if probe findings mutate contracts

package/README.md

@@ -16,7 +16,7 @@ The npm package is intentionally thin. It distributes the approved runtime paylo
 
 - Package: `@bvdm/delano`
 - Binary: `delano`
-- Commands: `install`, `init`, `validate`, `status`, `next`
+- Commands: `onboarding`, `install`, `init`, `validate`, `status`, `next`
 - Primary v1.1 goal: bootstrap a repo safely, then stay out of the way
 
 ## One-command bootstrap
@@ -84,9 +84,18 @@ Notes:
 
 ## How to use Delano after install
 
+Recommended first step:
+
+```bash
+delano onboarding
+```
+
+`delano onboarding` searches upward for `AGENTS.md`, asks for explicit approval before it analyzes anything, and prints recommendations using the packaged onboarding skill rubric. It does not edit `AGENTS.md` on its own.
+
 If you bootstrap with one-shot `npx`, keep using `npx` for wrapper commands:
 
 ```bash
+npx -y @bvdm/delano@latest onboarding --approve-agents-analysis
 npx -y @bvdm/delano@latest validate
 npx -y @bvdm/delano@latest status
 npx -y @bvdm/delano@latest next -- --all
@@ -95,6 +104,7 @@ npx -y @bvdm/delano@latest next -- --all
 If the package is installed locally or globally, run these inside the target repository:
 
 ```bash
+delano onboarding
 delano validate
 delano status
 delano next -- --all
@@ -132,6 +142,8 @@ The CLI does not bundle its own shell or Python runtime.
 - it does not install or overwrite repo-root Git config files such as `.gitignore` or `.gitattributes`
 
 The base install payload intentionally excludes top-level adapter entry docs such as `AGENTS.md`, `CLAUDE.md`, `CODEX.md`, `OPENCODE.md`, and `PI.md`. Those remain opt-in only.
+The installable `.project/context/` pack is seeded from generic templates during packaging; it does not ship Delano's own repo-specific context files into consumer repositories.
+After install, the recommended first step is `delano onboarding`, which requires explicit approval before it reviews `AGENTS.md`.
 
 ## Optional AGENTS.md / CLAUDE.md snippet
 
@@ -160,6 +172,7 @@ This package is deliberately narrow:
 
 - npm is the distribution surface
 - `.project` remains repo-owned after install
+- `.project/context/` installs as generic starter context that the target repo must replace with its own reality
 - `.agents` remains the runtime surface
 - wrapper commands stay thin in v1.1
 - `install-delano.sh` remains available as the legacy bridge installer

package/assets/install-manifest.json

@@ -1,6 +1,6 @@
 {
-  "version": 1,
-  "paths": [
+  "version": 2,
+  "files": [
     ".agents/adapters/claude/README.md",
     ".agents/adapters/codex/README.md",
     ".agents/adapters/opencode/README.md",
@@ -49,10 +49,22 @@
     ".agents/skills/closeout-skill/SKILL.md",
     ".agents/skills/closeout-skill/templates/closure-checklist.md",
     ".agents/skills/closeout-skill/templates/outcome-review.md",
+    ".agents/skills/manage-context/references/context-audit-checklist.md",
+    ".agents/skills/manage-context/references/runbook.md",
+    ".agents/skills/manage-context/SKILL.md",
+    ".agents/skills/manage-context/templates/context-debt-report.md",
+    ".agents/skills/manage-context/templates/context-refresh-summary.md",
+    ".agents/skills/onboarding/references/agents-md-best-practices.md",
+    ".agents/skills/onboarding/SKILL.md",
     ".agents/skills/discovery-skill/references/runbook.md",
     ".agents/skills/discovery-skill/SKILL.md",
     ".agents/skills/discovery-skill/templates/clarification-questions.md",
     ".agents/skills/discovery-skill/templates/discovery-summary.md",
+    ".agents/skills/prototype-skill/references/probe-design-checklist.md",
+    ".agents/skills/prototype-skill/references/runbook.md",
+    ".agents/skills/prototype-skill/SKILL.md",
+    ".agents/skills/prototype-skill/templates/probe-approval-recommendation.md",
+    ".agents/skills/prototype-skill/templates/probe-findings.md",
     ".agents/skills/execution-skill/references/runbook.md",
     ".agents/skills/execution-skill/SKILL.md",
     ".agents/skills/execution-skill/templates/blocker-update.md",
@@ -75,16 +87,46 @@
     ".agents/skills/sync-skill/templates/conflict-resolution-actions.md",
     ".agents/skills/sync-skill/templates/drift-report.md",
     ".delano/README.md",
-    ".project/context/gui-testing.md",
-    ".project/context/product-context.md",
-    ".project/context/progress.md",
-    ".project/context/project-brief.md",
-    ".project/context/project-overview.md",
-    ".project/context/project-structure.md",
-    ".project/context/project-style-guide.md",
-    ".project/context/README.md",
-    ".project/context/system-patterns.md",
-    ".project/context/tech-context.md",
+    {
+      "source": "assets/templates/context/gui-testing.md",
+      "target": ".project/context/gui-testing.md"
+    },
+    {
+      "source": "assets/templates/context/product-context.md",
+      "target": ".project/context/product-context.md"
+    },
+    {
+      "source": "assets/templates/context/progress.md",
+      "target": ".project/context/progress.md"
+    },
+    {
+      "source": "assets/templates/context/project-brief.md",
+      "target": ".project/context/project-brief.md"
+    },
+    {
+      "source": "assets/templates/context/project-overview.md",
+      "target": ".project/context/project-overview.md"
+    },
+    {
+      "source": "assets/templates/context/project-structure.md",
+      "target": ".project/context/project-structure.md"
+    },
+    {
+      "source": "assets/templates/context/project-style-guide.md",
+      "target": ".project/context/project-style-guide.md"
+    },
+    {
+      "source": "assets/templates/context/README.md",
+      "target": ".project/context/README.md"
+    },
+    {
+      "source": "assets/templates/context/system-patterns.md",
+      "target": ".project/context/system-patterns.md"
+    },
+    {
+      "source": "assets/templates/context/tech-context.md",
+      "target": ".project/context/tech-context.md"
+    },
     ".project/projects/.gitkeep",
     ".project/registry/linear-map.json",
     ".project/registry/migration-map.json",

package/assets/payload/.agents/scripts/pm/validate.sh

@@ -91,6 +91,7 @@ fi
 # Required skill contracts
 required_skills=(
   discovery-skill
+  prototype-skill
   planning-skill
   breakdown-skill
   sync-skill

package/assets/payload/.agents/skills/README.md

@@ -5,6 +5,7 @@ Handbook-aligned skill contracts.
 Core workflow skills:
 
 - `discovery-skill`
+- `prototype-skill`
 - `planning-skill`
 - `breakdown-skill`
 - `sync-skill`
@@ -13,6 +14,11 @@ Core workflow skills:
 - `closeout-skill`
 - `learning-skill`
 
+Utility skills:
+
+- `manage-context`
+- `onboarding`
+
 Each skill defines:
 - intent and trigger context
 - required inputs

package/assets/payload/.agents/skills/manage-context/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: manage-context
+description: Repair and maintain `.project/context/` so it reflects current project reality. Use when context files are stale, contradictory, still template-like, after major scope or architecture changes, before handoff, or when execution friction suggests context debt.
+---
+
+# manage-context
+
+## Trigger context
+- `.project/context/` still contains starter or placeholder language
+- implementation reality has drifted from spec, plan, or workstreams
+- repeated confusion appears around scope, terminology, ownership, architecture, or testing
+- a handoff, restart, or milestone review needs trustworthy context
+- a major scope, workflow, or architecture change landed and context was not refreshed
+
+## Required inputs
+- current `.project/context/` files
+- related project docs (`spec.md`, `plan.md`, `workstreams/*.md`, `decisions.md`, progress notes)
+- recent execution evidence (task state, code changes, review feedback, logs)
+
+## Output schema
+- updated `.project/context/*.md` files where needed
+- context debt summary
+- explicit contradictions or evidence gaps list
+- recommended follow-up actions when context cannot be repaired safely
+
+## Quality checks
+- no obvious template placeholders remain
+- context matches current implementation and delivery reality
+- terminology is consistent across files
+- scope, constraints, and non-goals are explicit
+- progress reflects evidence, not aspiration
+- unresolved uncertainty is stated plainly instead of being hidden
+
+## Failure behavior
+- do not invent missing facts
+- stop short of rewriting uncertain sections as if they were confirmed
+- return evidence gaps and contradiction notes when repair is partial
+- prefer an explicit partial refresh over fake completeness
+
+## Allowed side effects
+- update files under `.project/context/`
+- remove stale placeholder text from context files
+- normalize duplicated or conflicting phrasing across context files
+- add concise dated notes when they improve handoff clarity
+
+## Script hooks
+- `bash .agents/scripts/pm/validate.sh`
+- `bash .agents/scripts/pm/status.sh`
+- `bash .agents/scripts/pm/search.sh "<term>"`
+
+## Execution assets
+- `references/runbook.md`
+- `references/context-audit-checklist.md`
+- `templates/context-debt-report.md`
+- `templates/context-refresh-summary.md`

package/assets/payload/.agents/skills/manage-context/references/context-audit-checklist.md

@@ -0,0 +1,26 @@
+# Context Audit Checklist
+
+Use this checklist before declaring the context pack healthy.
+
+## Reality check
+- Does `project-overview.md` describe the project as it exists now?
+- Does `project-brief.md` still match the active outcome and constraints?
+- Does `tech-context.md` match the real implementation shape?
+- Does `product-context.md` match the real user or delivery problem?
+- Does `progress.md` describe actual current status rather than intended status?
+
+## Drift check
+- Are there claims that conflict with `spec.md`, `plan.md`, or workstreams?
+- Are there terms used inconsistently across context files?
+- Are owners, boundaries, or dependencies implied in one file but absent in others?
+- Are testing expectations current, especially in `gui-testing.md`?
+
+## Template debt check
+- Are placeholder markers or generic starter phrases still present?
+- Are sections filled with boilerplate rather than repo-specific facts?
+- Does the pack still read like an install scaffold instead of a lived project?
+
+## Handoff check
+- Could a new agent or teammate resume work from this context pack without guessing?
+- Are the main constraints, risks, and non-goals easy to find?
+- Are open questions explicit?

package/assets/payload/.agents/skills/manage-context/references/runbook.md

@@ -0,0 +1,26 @@
+# Context Runbook
+
+1. Read `.project/context/README.md` to confirm the expected context pack shape.
+2. Review all current `.project/context/*.md` files.
+3. Cross-check the context pack against the active source of truth:
+   - `.project/projects/<slug>/spec.md`
+   - `.project/projects/<slug>/plan.md`
+   - `.project/projects/<slug>/workstreams/*.md`
+   - `.project/projects/<slug>/decisions.md`
+   - recent task state, code changes, and review feedback
+4. Mark context debt before editing:
+   - stale claims
+   - template placeholders
+   - contradictory terminology
+   - missing constraints or ownership
+   - progress statements without evidence
+5. Repair only what the evidence supports.
+6. Record unresolved contradictions or evidence gaps explicitly.
+7. Validate:
+   - `bash .agents/scripts/pm/validate.sh`
+   - `bash .agents/scripts/pm/status.sh`
+
+Exit gate:
+- context pack is trustworthy enough for handoff or resumed execution
+- open uncertainty is visible
+- no placeholder text remains in edited sections

package/assets/payload/.agents/skills/manage-context/templates/context-debt-report.md

@@ -0,0 +1,22 @@
+# Context Debt Report
+
+## Summary
+
+## Stale or Contradictory Sections
+- File:
+- Issue:
+- Evidence:
+- Action:
+
+## Placeholder or Template Debt
+- File:
+- Section:
+- Replacement needed:
+
+## Missing Context
+- Gap:
+- Why it matters:
+- Best source of truth:
+
+## Recommended Follow-up
+- 

package/assets/payload/.agents/skills/manage-context/templates/context-refresh-summary.md

@@ -0,0 +1,13 @@
+# Context Refresh Summary
+
+## Refreshed Files
+- 
+
+## What Changed
+- 
+
+## Remaining Uncertainty
+- 
+
+## Next Action
+- Resume execution or handoff using the refreshed context pack.

package/assets/payload/.agents/skills/onboarding/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: onboarding
+description: Analyze a repository `AGENTS.md` before broader work begins and improve it only when the user gives explicit approval. Use when the user wants a first-pass review of repo instructions, wants to tighten `AGENTS.md` quality, or needs a compact operating-rules and source-of-truth map for future agent turns.
+---
+
+# onboarding
+
+## Trigger context
+- the user wants an explicit first-turn onboarding pass for a repository
+- `AGENTS.md` exists but may be too thin, stale, or missing key guidance
+- the user asks to review, critique, or improve repo-level agent instructions
+- Delano has just been introduced and `AGENTS.md` should be checked before deeper work starts
+
+## Required inputs
+- repo-root `AGENTS.md`
+- directly relevant source-of-truth docs referenced by `AGENTS.md`
+- explicit user approval before analyzing `AGENTS.md`
+- separate explicit user approval before editing `AGENTS.md`
+
+## Output schema
+- concise gap analysis against `references/agents-md-best-practices.md`
+- keep/add/remove recommendations tied to the repo's actual workflow
+- if edit approval is given, an updated `AGENTS.md` that stays compact and retrieval-oriented
+- explicit note when analysis or edits were skipped because approval was not given
+
+## Quality checks
+- do not analyze `AGENTS.md` until the user explicitly approves the review
+- do not edit `AGENTS.md` until the user explicitly approves changes
+- preserve repo-specific truth instead of pasting generic boilerplate
+- keep `AGENTS.md` compact and point to deeper docs instead of duplicating them
+- make approval boundaries, order of operations, and verification expectations explicit
+
+## Failure behavior
+- if approval is missing, stop and ask plainly
+- if `AGENTS.md` is absent, report that and propose only a minimal skeleton
+- if source-of-truth docs disagree, surface the conflict instead of flattening it
+- if the repo intentionally keeps `AGENTS.md` thin, prefer the minimum coherent improvement
+
+## Allowed side effects
+- read `AGENTS.md` and directly relevant source-of-truth docs
+- update `AGENTS.md` only after explicit edit approval
+- add concise retrieval hints that point to canonical docs
+
+## Script hooks
+- `delano onboarding`
+- `bash .agents/scripts/pm/validate.sh`
+
+## Execution assets
+- `references/agents-md-best-practices.md`

package/assets/payload/.agents/skills/onboarding/references/agents-md-best-practices.md

@@ -0,0 +1,76 @@
+# How to write an AGENTS.md that works
+
+AGENTS.md carries the context the agent needs every turn. Skills and `docs/` hold optional, task-specific workflows. Do not confuse the two.
+
+## What belongs in AGENTS.md
+
+1. Operating rules: startup sequence, approval boundaries, destructive-action handling, definition of done, default workspace.
+2. Source-of-truth map: compact index pointing to where real knowledge lives. Include version-sensitive areas and "if working on X, read Y first" hints.
+3. Order-of-operations: phrase as a sequence, not a blanket rule. Not "always read docs first" but: explore structure -> retrieve relevant docs -> implement -> verify.
+4. Stable, high-impact constraints: repo location, branch policy, style rules, runtime quirks, business-logic conventions. High-frequency, high-impact, easy to miss.
+
+## What does not belong
+
+Long prose, full runbooks, rarely-used procedures, or anything duplicated from `docs/`. Point to it instead.
+
+## Example skeleton (Delano-style)
+
+```markdown
+## Mission
+One line: what this project is, what good work looks like.
+
+## First-Turn Workflow
+1. Inspect repo structure and current git state before assuming shape or ownership.
+2. Read the relevant local source of truth for the area being changed.
+3. Prefer current repo reality over stale plans or model memory.
+4. Make the smallest coherent change that satisfies the task.
+5. Verify with the narrowest meaningful check, then report done / partial / blocked explicitly.
+
+## Source of Truth
+- `HANDBOOK.md`: delivery model, project contracts, evidence, continuity rules.
+- `ARCHITECTURE.md`: product architecture and runtime/orchestration model.
+- `.project/context/`: current project memory - start with `README.md`, then only what is relevant.
+- `.project/projects/<project>/`: active delivery contracts (`spec.md`, `plan.md`, `decisions.md`, `workstreams/`, `tasks/`, `updates/`).
+- `.agents/`: shared delivery/runtime assets, skills, rules, hooks, PM scripts.
+- `README.md`: product status, setup, commands, operational gaps.
+- `src/`, `skills/`, `starter/`, `fixtures/`, `tests/`: implemented surface.
+- `possible-specs.md`: archived only - not active guidance.
+
+## Retrieval Index
+- Delivery workflow -> `HANDBOOK.md` + matching `.agents/skills/<step>-skill/SKILL.md`
+- Active scope / acceptance -> `spec.md` + relevant task files
+- Architecture / runtime -> `ARCHITECTURE.md`, `plan.md`, `.project/context/system-patterns.md`
+- Repo layout -> `.project/context/project-structure.md`
+- Stack / commands -> `.project/context/tech-context.md`, `README.md`, `package.json`
+- Style / docs conventions -> `.project/context/project-style-guide.md`
+- GUI/browser checks -> `.project/context/gui-testing.md`
+- Status / evidence -> `.project/context/progress.md`, `updates/`
+- CRM/provider work -> `src/connectors/`, `fixtures/providers/`, provider tests
+- Starter/runtime assets -> `starter/`, `.runtime/` expectations, starter validation tests
+
+## Delano Order of Operations
+Use the full flow for features, contract changes, or material improvements:
+1. Discovery - define measurable outcome in `spec.md` (`discovery-skill`).
+2. Prototype Probe - time-boxed, only if uncertainty is high; findings back to spec.
+3. Planning - architecture, milestones, rollout, rollback in `plan.md` (`planning-skill`).
+4. Breakdown - atomic tasks, binary acceptance, acyclic dependencies (`breakdown-skill`).
+5. Synchronization - reconcile with Linear/GitHub when tracker state is involved (`sync-skill`).
+6. Execution - dependency-safe tasks inside workstream boundaries, evidence in `updates/` (`execution-skill`).
+7. Quality Ops - risk-based checks, verify acceptance before closure (`quality-skill`).
+8. Closeout - compare to outcome, update project memory, close the loop (`closeout-skill`).
+
+For small local fixes: follow the first-turn workflow; update delivery/context files only when scope, architecture, status, or evidence changes.
+
+## Safety
+- No destructive actions without approval.
+- Prefer recoverable edits.
+- Confirm before outbound/public actions.
+
+## Verification
+- Run lint/test/build when relevant; if skipped, say why.
+- Mark done / partial / blocked explicitly.
+```
+
+## Core principle
+
+AGENTS.md should contain the minimum persistent context needed to make correct decisions reliably, and a compact map for retrieving everything else.

package/assets/payload/.agents/skills/prototype-skill/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: prototype-skill
+description: Run a time-boxed Prototype Probe to retire material uncertainty before spec approval. Use when `spec.md` is still draft, `probe_required: true`, or a narrow experiment is needed to bound technical or delivery risk before planning.
+---
+
+# prototype-skill
+
+## Trigger context
+- `spec.md` is still draft and contains material uncertainty
+- `probe_required: true`
+- approval would otherwise be speculative
+- a narrow experiment can retire a specific technical, UX, integration, or delivery risk faster than discussion alone
+
+## Required inputs
+- `spec.md` with uncertainty and probe fields populated
+- target uncertainty to retire or bound
+- time-box and experiment constraints
+- success or failure evidence expected from the probe
+
+## Output schema
+- updated draft `spec.md`
+- probe findings summary
+- explicit approval recommendation (`approve`, `revise`, or `run another narrow probe`)
+- touched surfaces and footguns list
+
+## Quality checks
+- probe stays time-boxed, normally `<= 1 day`
+- experiment is narrow and directly tied to the uncertainty being tested
+- no production merge happens directly from probe output
+- findings are folded back into `spec.md` before continuation
+- touched surfaces, footguns, and remaining uncertainty are explicit
+
+## Failure behavior
+- stop if the probe is too broad, open-ended, or not tied to a material uncertainty
+- return a narrower probe design when the current one is not safe or useful
+- do not present exploratory output as production-ready implementation
+
+## Allowed side effects
+- update draft `spec.md`
+- create or update temporary probe notes inside the project folder when needed
+- record approval recommendation and follow-up actions
+
+## Script hooks
+- `bash .agents/scripts/pm/validate.sh`
+- `bash .agents/scripts/pm/status.sh`
+
+## Execution assets
+- `references/runbook.md`
+- `references/probe-design-checklist.md`
+- `templates/probe-findings.md`
+- `templates/probe-approval-recommendation.md`

package/assets/payload/.agents/skills/prototype-skill/references/probe-design-checklist.md

@@ -0,0 +1,26 @@
+# Probe Design Checklist
+
+Use this before running a Prototype Probe.
+
+## Probe quality
+- Is the uncertainty material enough to justify a probe?
+- Is the probe tied to one concrete question?
+- Is the probe smaller than full implementation?
+- Can the result change the spec approval decision?
+
+## Scope control
+- What is explicitly in scope?
+- What is explicitly out of scope?
+- Which surfaces may be touched?
+- What would make this probe too broad?
+
+## Evidence
+- What outcome would justify approval?
+- What outcome would require revision?
+- What outcome would suggest another narrow probe?
+- What footguns or side effects must be recorded even if the probe succeeds?
+
+## Safety
+- Is there any risk of probe code being treated like production-ready output?
+- Is there a clean way to prevent direct merge from probe artifacts?
+- Are follow-up tasks likely to be needed after the probe?

package/assets/payload/.agents/skills/prototype-skill/references/runbook.md

@@ -0,0 +1,27 @@
+# Prototype Probe Runbook
+
+1. Read the draft `spec.md` and identify the single material uncertainty to retire or bound.
+2. Confirm `probe_required: true` and keep the probe narrow.
+3. Define the smallest useful experiment:
+   - what is being tested
+   - what evidence is needed
+   - what touched surfaces are in scope
+   - what is explicitly out of scope
+4. Time-box the probe, normally to `<= 1 day`.
+5. Run the experiment using the safest path, CLI-first when feasible.
+6. Do not merge probe output directly into production delivery flow.
+7. Fold findings back into `spec.md`:
+   - what changed after probe
+   - touched surfaces
+   - footguns
+   - remaining uncertainty
+   - approval recommendation
+8. Validate if contracts changed:
+   - `bash .agents/scripts/pm/validate.sh`
+9. Snapshot status when useful:
+   - `bash .agents/scripts/pm/status.sh`
+
+Exit gate:
+- probe findings recorded
+- approval recommendation is clear
+- next step is explicit: approve, revise, or run another narrow probe

package/assets/payload/.agents/skills/prototype-skill/templates/probe-approval-recommendation.md

@@ -0,0 +1,13 @@
+# Probe Approval Recommendation
+
+## Recommendation
+- Approve
+- Revise
+- Run another narrow probe
+
+## Why
+
+## Remaining Uncertainty
+
+## Immediate Next Action
+- 

package/assets/payload/.agents/skills/prototype-skill/templates/probe-findings.md

@@ -0,0 +1,16 @@
+# Probe Findings
+
+## Uncertainty Tested
+
+## Experiment Shape
+
+## Evidence Observed
+
+## Touched Surfaces
+- 
+
+## Footguns
+- 
+
+## What Changed In The Spec
+- 

package/assets/payload/.project/context/README.md

@@ -1,6 +1,8 @@
 # Delano Context Pack
 
-Keep this folder current for execution continuity.
+This folder is seeded by `delano install` with generic starter context.
+
+Update each file to describe this repository's real delivery context before active implementation work begins.
 
 Required context files:
 

package/assets/payload/.project/context/gui-testing.md

@@ -1,20 +1,16 @@
 # GUI Testing Policy
 
 ## Enforcement Mode
-- `advisory`
+- `<advisory|required>`
 
 ## Smoke Routes
-- No GUI smoke route is required for the current core repo because Delano is presently handbook- and script-driven.
-- If a project introduces or changes `.delano/` UI surfaces, that project should add the routes and critical flows to exercise here or in project-specific context.
+- <list any critical UI routes or state that must be exercised>
 
 ## Console Filtering
-- Block browser/runtime errors for any UI surface that is introduced.
-- Allow only documented, known development-only noise during local testing.
+- <describe which browser or runtime errors are blocking>
 
 ## Evidence Requirements
-- Capture screenshots, console output, and comparison notes only for work that touches `.delano/` or other browser-visible surfaces.
-- Script- and contract-only changes do not require GUI evidence.
+- <describe what screenshots, logs, or notes must be captured>
 
 ## Design Validation Threshold
-- For UI work, critical flows must render correctly, remain usable on supported viewports, and ship without blocked console errors.
-- For non-UI work in this repo, this section is not a gating constraint.
+- <describe the usability and visual quality bar for UI work>

package/assets/payload/.project/context/product-context.md

@@ -1,17 +1,10 @@
 # Product Context
 
 ## Users
-- Maintainers evolving Delano's handbook, runtime, and installer behavior.
-- Operators adding Delano to existing repositories and using the PM/runtime scripts day to day.
-- Coding agents working through Delano's shared contracts and adapter notes instead of tool-specific process variants.
+- <describe the primary operator, maintainer, or end-user groups>
 
 ## Core Flows
-- Start with an outcome, draft a spec, make the probe decision explicit, plan workstreams, decompose tasks, execute, validate, and close out with evidence.
-- Install Delano into a repository, then operate primarily through `.project/` contracts and `.agents/scripts/pm/*`.
-- Use `validate`, `status`, `next`, and related scripts to keep delivery state coherent and dependency-safe.
+- <describe the critical workflows that should remain intact>
 
 ## Constraints
-- Delano must stay agent-agnostic and protocol-first rather than becoming a proprietary execution host.
-- `.project` remains the source of truth for delivery state.
-- `.agents` remains the canonical runtime and `.claude` is compatibility only.
-- `.delano` remains optional and must not become process truth.
+- <record the major product, policy, or architectural constraints>