@evo-dev/evodev 0.0.1-alpha → 0.0.1-alpha.1

package/dist/plugins/evodev/package.json

@@ -1,16 +1,16 @@
 {
   "name": "@evo-dev/plugin",
-  "version": "0.0.1-alpha",
+  "version": "0.0.1-alpha.1",
   "type": "module",
   "exports": {
     ".": "./hooks/index.ts"
   },
   "dependencies": {
-    "@evo-dev/core": "0.0.1-alpha"
+    "@evo-dev/core": "workspace:*"
   },
   "engines": {
     "bun": ">=1.1.0"
   },
-  "files": ["hooks", ".claude-plugin", ".codex-plugin", "hooks", "package.json"],
+  "files": ["hooks", ".claude-plugin", ".codex-plugin", ".mcp.json", "skills", "package.json"],
   "license": "MIT"
 }

package/dist/plugins/evodev/skills/engineering-discipline/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: engineering-discipline
+description: Use when implementing, reviewing, or refactoring code to clarify assumptions, avoid overengineering, keep diffs focused, protect scope boundaries, and verify results.
+license: MIT
+---
+
+# Engineering Discipline
+
+## Purpose
+
+Engineering Discipline is a practical guardrail for AI-assisted development. It keeps each coding session anchored to the requested outcome, makes assumptions visible, and requires verification before reporting success.
+
+## Use this skill when
+
+- Implementing a feature, bug fix, refactor, or test change.
+- Reviewing code for correctness, safety, or maintainability.
+- Working under explicit MVP, privacy, release, or project-boundary constraints.
+- A task could expand into speculative architecture or unrelated cleanup.
+
+## Do not use this skill for
+
+- Pure brainstorming where no code or plan will be produced.
+- Tasks where the user explicitly asks for unconstrained exploration.
+- Replacing product, security, or legal review when those are required.
+
+## Core principles
+
+### 1. Assumption management
+
+State meaningful assumptions before acting. If an assumption changes the user-visible behavior, data boundary, or implementation scope, pause and ask instead of silently guessing.
+
+### 2. Simplicity control
+
+Prefer the smallest design that satisfies the current acceptance criteria. Avoid framework additions, broad abstractions, and future-facing features unless they are required now.
+
+### 3. Diff discipline
+
+Every modified file should have a clear reason tied to the task. Avoid drive-by formatting, unrelated refactors, and opportunistic rewrites.
+
+### 4. Verification loop
+
+Attach each important change to a verification method: test, typecheck, lint, dry-run, manual command, or explicit reason it cannot be run. Do not claim a gate passed unless it was actually executed.
+
+### 5. Scope boundary
+
+Respect project and privacy boundaries. Do not modify user project assets, user-level Code Agent configuration, secrets, logs, or learning data unless the task explicitly requires it and the relevant safeguards exist.
+
+## Operating steps
+
+1. Restate the goal and identify the current task, todo item, or acceptance criteria.
+2. Check the nearest source of truth: existing code, tests, implementation notes, or task instructions.
+3. List assumptions and ask when a choice is materially ambiguous.
+4. Make the smallest focused change that satisfies the goal.
+5. Verify with the most relevant local gate.
+6. Report what changed, what was tested, what failed or was skipped, and any remaining risk.
+
+## Output checklist
+
+- Goal remains unchanged from the request.
+- Modified files are directly related to the goal.
+- New behavior has a validation path.
+- User or project boundaries were not crossed.
+- Final report distinguishes PASS, FAIL, and not-run checks.

package/dist/plugins/evodev/skills/engineering-discipline/anti-patterns.md

@@ -0,0 +1,21 @@
+# Engineering Discipline Anti-Patterns
+
+## Scope creep
+
+Adding sync, plugin, workflow, or learning behavior while a task only asks for canonical assets.
+
+## Silent assumptions
+
+Choosing a destructive write path, external dependency, or user-data behavior without explaining the assumption or asking for confirmation.
+
+## Diff pollution
+
+Formatting unrelated files, renaming public APIs, or refactoring neighboring modules because they were nearby.
+
+## Verification theater
+
+Reporting success without running the relevant gate, or hiding a failed check behind vague wording.
+
+## Boundary violations
+
+Writing to project-level `CLAUDE.md`, `AGENTS.md`, `.claude/`, `.codex/`, or user private data unless the user explicitly requested it and the current task permits it.

package/dist/plugins/evodev/skills/engineering-discipline/examples.md

@@ -0,0 +1,19 @@
+# Engineering Discipline Examples
+
+## Focused implementation
+
+**Situation:** The task asks for a scanner-valid built-in asset.
+
+**Disciplined response:** Add only the asset directory, manifest, entry file, and concise support files. Validate with the asset scanner or project check. Do not implement plugin sync or CLI behavior in the same task.
+
+## Assumption handling
+
+**Situation:** Two output formats are possible and both affect users.
+
+**Disciplined response:** Explain the options and ask for direction, or choose the option already specified by the current source of truth.
+
+## Verification report
+
+**Good report:** `bun run check` was run and passed. Asset manifests scan with registry keys `coding/engineering-discipline` and `review/code-reviewer`.
+
+**Bad report:** “Looks good” without saying what was run or whether any gate failed.

package/dist/plugins/evodev/skills/engineering-discipline/verification.md

@@ -0,0 +1,11 @@
+# Engineering Discipline Verification
+
+Use this quick gate before reporting completion:
+
+1. **Scope:** Does every change map to the current request, todo item, or acceptance criteria?
+2. **Safety:** Did the work avoid project assets, secrets, private logs, and user configuration unless explicitly allowed?
+3. **Simplicity:** Is there any new abstraction, dependency, or feature not needed for the current goal?
+4. **Evidence:** Was the most relevant test, typecheck, lint, scanner, or dry-run executed?
+5. **Report:** Are failures and skipped checks stated plainly?
+
+If any answer is no, fix the issue or report the remaining risk instead of claiming the gate passed.

package/dist/plugins/evodev/skills/knowledge-distillation/SKILL.md

@@ -0,0 +1,248 @@
+---
+name: knowledge-distillation
+description: Use when turning reviewed execution evidence into atomic, privacy-filtered, role-tagged engineering knowledge candidates, evos cases, repo asset proposals, or role-agent/team suggestions.
+license: MIT
+---
+
+# Knowledge Distillation / 提炼
+
+## Purpose
+
+Knowledge Distillation is an evidence curation pipeline. It turns reviewed execution evidence into atomic, reusable, role-tagged proposals that a user can inspect before anything becomes accepted knowledge or a project asset.
+
+It is not a trace summarizer, automatic memory writer, or team launcher.
+
+## Use This Skill When
+
+- A completed task produced a repeatable repository-specific lesson.
+- A review, failure, postmortem, or user correction should become a rule, warning, checklist item, decision, pattern, or evos case.
+- Execution evidence suggests a repo-local skill, rule, role agent, subagent, or EvoHub team.
+- Reviewed execution evidence shows a task split, tool call, skill output, or subagent handoff was incomplete, inaccurate, inefficient, or unsafe.
+- Role-specific knowledge should later be available to a role agent, subject to explicit consent and runtime scope.
+
+## Do Not Use This Skill For
+
+- Writing `CLAUDE.md`, `AGENTS.md`, `.claude/`, `.codex/`, `.evodev/`, source files, or project assets without explicit project opt-in.
+- Storing raw prompts, transcripts, source dumps, raw command output, secrets, tokens, internal links, or private URLs.
+- Treating unreviewed observations, model reflection, or trace logs as accepted memory.
+- Starting subagents or teams automatically.
+
+## Inputs
+
+Work from one bounded evidence window. Prefer reviewed, minimized inputs:
+
+- Task goal, final outcome, and repository scope.
+- Verification evidence, failures, fixes, and review findings.
+- Accepted corrections or explicit user feedback.
+- Relevant external authority, when the lesson depends on a standard, official documentation, or upstream behavior.
+- Candidate roles that should care, such as `architect`, `implementer`, `reviewer`, `tester`, `security`, `release`, `docs`, or user-defined role slugs.
+
+Do not ingest raw traces wholesale. If trace evidence is needed, use a redacted summary and evidence references.
+
+## Evidence Policy
+
+Classify every input before extraction:
+
+| Evidence class | Use | Constraint |
+|---|---|---|
+| `verified-run` | Test/build/lint/check outcomes and accepted fixes | Store references and summaries, not raw output |
+| `reviewed-finding` | Code review, security review, or user correction | Keep finding, impact, and accepted action separate |
+| `decision-record` | Architecture or workflow decision | Preserve context, decision, alternatives, consequences |
+| `postmortem-case` | Failure, incident, or after-action review | Preserve expected vs actual, cause, action item |
+| `official-reference` | Standards, docs, upstream behavior | Include URL/version/date; do not overquote |
+| `model-reflection` | Agent-generated synthesis | Candidate only; never accepted without review |
+| `tool-call-summary` | Tool selection, risk class, status, and recovery | No raw command or raw stdout/stderr by default |
+| `skill-invocation` | Skill id/version, input class, output schema, and reviewed result | Record omissions or inaccuracies as findings; do not store raw prompts/source |
+| `subagent-lifecycle` | Role, reason, scope, status, output refs, and merge result | No raw transcript |
+| `evo-eval-result` | Eval case pass/fail and assertion summary | Store fixture refs and assertion results, not private raw data |
+
+## Distillation Pipeline
+
+1. **Scope**: identify repo, task, role audience, evidence ids, and explicit project opt-in status.
+2. **Minimize**: remove raw prompts, raw logs, source dumps, secrets, personal data, internal links, and one-off noise.
+3. **Analyze execution structure**: when event evidence is present, identify task slices, owner roles, dependencies, key tool calls, skill invocations, subagent lifecycle events, verification gates, and merge outcomes.
+4. **Extract atomic candidates**: one claim per candidate. Allowed `kind` values are `rule`, `decision`, `pattern`, `anti-pattern`, `warning`, `checklist`, `concept`, `workflow-improvement`, `task-split-improvement`, `tool-use-improvement`, `skill-improvement`, `repo-asset-suggestion`, `role-agent-suggestion`, `team-suggestion`, `eval-set`, and `open-question`.
+5. **Separate fact from inference**: mark whether the candidate is directly evidenced or inferred from evidence.
+6. **Classify**: add `roleTags`, `repoScope`, `domainTags`, `stability`, `sensitivity`, `reviewState`, and `targetStore`.
+7. **Score**: estimate evidence strength, reuse value, actionability, stability, novelty, privacy risk, and duplication risk.
+8. **Pair improvements with evals**: every proposed skill, role-agent, team, workflow, routing, tool-use, or subagent behavior change should include an `evoEvalSets` entry, unless the proposal explains why eval coverage is not applicable.
+9. **Privacy gate**: defer candidates that require raw private content to remain meaningful.
+10. **Route**: propose a user-local knowledge/evos write, a repo-local asset suggestion, or no write.
+11. **Review plan**: list exact proposed paths, summaries, rollback notes, and why human review is required.
+
+## Output Schema
+
+Return a proposal. Use structured Markdown or JSON, but preserve these fields:
+
+```json
+{
+  "summary": "What reusable improvement was found.",
+  "scope": {
+    "level": "user | project | workflow | skill",
+    "repo": "optional repository identifier",
+    "projectOptIn": false
+  },
+  "roleTags": ["reviewer"],
+  "executionAnalysis": {
+    "taskSlices": [
+      {
+        "id": "slice-1",
+        "goal": "Review skill output gap",
+        "ownerRole": "reviewer",
+        "dependencies": [],
+        "expectedEvidence": ["reviewed-finding"],
+        "stopCondition": "Skill gap and regression eval target are identified"
+      }
+    ],
+    "keyEvents": [
+      {
+        "id": "event-1",
+        "type": "tool-call | skill-invocation | subagent-lifecycle | verification | review-finding | route-decision",
+        "summary": "Knowledge skill proposed a behavior change without eval coverage.",
+        "evidenceRefs": ["review:skill-output-gap"],
+        "rawContentStored": false
+      }
+    ],
+    "qualityFindings": [
+      {
+        "category": "task-split-gap | tool-use-gap | skill-output-gap | subagent-routing-gap | verification-gap | privacy-gap",
+        "severity": "low | medium | high | critical",
+        "claim": "Skill proposal lacked regression eval cases for a skill change.",
+        "expectedBehavior": "Skill changes should include evoEvalSets.",
+        "roleTags": ["reviewer", "tester"]
+      }
+    ]
+  },
+  "evidenceRefs": [
+    {
+      "id": "verification:typecheck",
+      "class": "verified-run",
+      "storedRawContent": false
+    }
+  ],
+  "knowledgeCandidates": [
+    {
+      "kind": "rule",
+      "claim": "For TypeScript CLI changes, run the workspace check before reporting completion.",
+      "basis": "direct | inferred",
+      "howToApply": "Add bun run check to the verification plan.",
+      "antiCriteria": ["Do not mark completion from lint alone."],
+      "roleTags": ["implementer", "reviewer"],
+      "repoScope": { "level": "project", "pathPrefixes": ["packages/cli/"] },
+      "stability": "stable | evolving | volatile",
+      "sensitivity": "public | local-private | restricted",
+      "scores": {
+        "evidenceStrength": 4,
+        "reuseValue": 4,
+        "actionability": 5,
+        "stability": 4,
+        "novelty": 2,
+        "privacyRisk": 1,
+        "duplicationRisk": 1
+      },
+      "targetStore": "knowledge | evos | repo-asset-proposal | none",
+      "reviewState": "proposed"
+    }
+  ],
+  "evoCases": [],
+  "skillImprovementSuggestions": [
+    {
+      "skillId": "coding/knowledge-distillation",
+      "gapClass": "missing-eval-set | output-omission | inaccurate-claim | schema-drift | trigger-mismatch | privacy-defect",
+      "evidenceRefs": ["review:skill-output-gap"],
+      "observedBehavior": "A proposed skill change lacked regression eval coverage.",
+      "expectedBehavior": "Every skill behavior change includes at least one eval case or an explicit not-applicable reason.",
+      "changeSummary": "Extend the skill output contract with evoEvalSets.",
+      "targetPaths": ["packages/core/assets/skills/coding/knowledge-distillation/SKILL.md"],
+      "acceptanceCriteria": ["Output includes an eval set for each skill behavior change."],
+      "reviewState": "proposed"
+    }
+  ],
+  "evoEvalSets": [
+    {
+      "id": "eval-knowledge-distillation-skill-change-needs-evals",
+      "target": { "kind": "skill", "id": "coding/knowledge-distillation" },
+      "purpose": "Prevent skill-change proposals without regression evals.",
+      "roleTags": ["reviewer", "tester"],
+      "cases": [
+        {
+          "id": "case-skill-output-gap",
+          "inputRefs": ["fixture:reviewed-skill-gap"],
+          "assertions": [
+            "skillImprovementSuggestions[0].skillId is present",
+            "evoEvalSets contains at least one case for the skill change",
+            "privacyCheck.rawPromptsStored == false",
+            "privacyCheck.sourceDumpsStored == false",
+            "privacyCheck.rawCommandOutputStored == false"
+          ],
+          "expectedReviewState": "proposed"
+        }
+      ],
+      "privacy": {
+        "usesRawPrompt": false,
+        "usesSourceDump": false,
+        "usesRawCommandOutput": false
+      },
+      "reviewState": "proposed"
+    }
+  ],
+  "repoAssetSuggestions": [],
+  "teamSuggestions": [],
+  "privacyCheck": {
+    "rawPromptsStored": false,
+    "rawLogsStored": false,
+    "sourceDumpsStored": false,
+    "rawCommandOutputStored": false,
+    "secretsStored": false,
+    "internalLinksStored": false,
+    "deferredCandidates": []
+  }
+}
+```
+
+Scoring uses 1-5 integers. A candidate should not be proposed for accepted knowledge unless evidence strength, reuse value, and actionability are high enough to justify future retrieval and privacy risk is low.
+
+## Write Targets
+
+Default output is review-only.
+
+- `knowledge`: stable accepted facts, decisions, constraints, concepts, and reusable rules after review.
+- `evos`: reviewed process improvement cases with trigger, intervention, evidence, and expected future behavior.
+- `evo-eval-set`: proposed or accepted regression cases for skill, role-agent, team, workflow, routing, tool-use, or subagent behavior.
+- `repo-asset-proposal`: suggested repo rules, skills, role agents, subagents, or teams. Requires explicit project opt-in before any write.
+- `none`: useful observation that should stay in the report and not become durable knowledge.
+
+Project-local writes require an explicit opt-in step that lists exact paths, content summaries, rollback notes, and privacy checks before any file write.
+
+## Role Tags
+
+Every durable candidate must include at least one role tag. Prefer stable role slugs:
+
+- `architect`
+- `implementer`
+- `reviewer`
+- `tester`
+- `security`
+- `release`
+- `docs`
+
+Use user-defined role slugs only when a reviewed role-agent definition exists. Treat role tags as retrieval/routing filters, not decorative labels.
+
+## Review Triggers
+
+Require explicit review before persistence when a candidate:
+
+- Affects security, privacy, release, architecture, or cross-repo behavior.
+- Suggests a project-local file write.
+- Suggests changing a skill, role agent, team, workflow, routing rule, tool-use policy, or subagent behavior without an associated `evoEvalSets` entry or explicit not-applicable reason.
+- Has low evidence strength, high privacy risk, or ambiguous repo scope.
+- Would change role-agent behavior, EvoHub team composition, or future runtime retrieval.
+- Is derived primarily from model reflection rather than verified evidence.
+
+## Runtime Attention Boundary
+
+Accepted role-tagged knowledge may later help a selected role focus on relevant rules, decisions, cases, or warnings. Runtime loading remains gated by role selection, repo scope, privacy policy, and consent. Pending, rejected, or deferred candidates must not influence routing or runtime behavior.
+
+## References
+
+For method comparisons and design rationale, read `references/knowledge-distillation-methods.md` in this skill directory.

package/dist/plugins/evodev/skills/knowledge-distillation/references/knowledge-distillation-methods.md

@@ -0,0 +1,122 @@
+# Knowledge Distillation Method Notes
+
+This reference explains why the skill uses an evidence curation pipeline instead of a generic summarization workflow.
+
+## Method Comparison
+
+| Method | What it contributes | EvoDev adaptation |
+|---|---|---|
+| Postmortem / SRE review | Blameless failure analysis, root cause, impact, action items | Use for failure-derived `warning`, `anti-pattern`, `checklist`, and `workflow-improvement` candidates |
+| After Action Review | Expected vs actual, what went well, what failed, what changes next time | Use for evos cases and team/process improvement candidates |
+| Lessons learned systems | Reviewed lessons from projects/programs, not raw incident notes | Keep accepted knowledge separate from raw evidence and candidates |
+| ADR / decision logs | One durable decision with context, alternatives, rationale, consequences | Use `decision` candidates for architecture/workflow choices |
+| SKOS-style knowledge organization | Concepts, labels, narrower/broader/related terms, scope notes | Keep role tags and domain tags controlled enough for retrieval |
+| Agent memory research | Semantic facts, episodic cases, procedural improvements | Split knowledge, evos cases, and repo asset suggestions instead of one memory bucket |
+| Agent skills | Small triggerable procedures with references/assets for larger material | Keep `SKILL.md` operational and place long examples/taxonomies in references |
+| Evaluation-driven development | Behavior changes need regression cases and objective assertions | Pair skill, role, team, workflow, routing, tool-use, and subagent proposals with evo eval sets |
+
+## Evidence Quality
+
+Prefer evidence in this order:
+
+1. Verified local outcomes: tests, typecheck, lint, build, release dry-run, smoke checks, or accepted fixes.
+2. Reviewed findings: code review, security review, user correction, or postmortem conclusion.
+3. Official or upstream references: standards, vendor docs, framework docs, release notes, or source repositories.
+4. Existing repository contracts: `AGENTS.md`, design docs, task contracts, tests, schemas, and explicit policy files.
+5. Model reflection: useful for candidate generation only; never enough for accepted knowledge.
+
+## Candidate Types
+
+- `rule`: normative guidance with a clear trigger and expected behavior.
+- `decision`: accepted choice plus context, alternatives, and consequences.
+- `pattern`: repeatable implementation or workflow shape.
+- `anti-pattern`: repeatable bad shape to avoid.
+- `warning`: risk that should influence planning or review.
+- `checklist`: short verification list for a role or workflow.
+- `concept`: term, domain note, taxonomy entry, or glossary item.
+- `workflow-improvement`: process change with trigger and expected future behavior.
+- `task-split-improvement`: improved decomposition, dependencies, owner roles, evidence, or stop conditions.
+- `tool-use-improvement`: improved tool selection, risk classification, command gating, or verification behavior.
+- `skill-improvement`: proposed change to a skill trigger, input requirements, output schema, references, or behavior.
+- `repo-asset-suggestion`: proposed project rule, skill, agent, subagent, or config file.
+- `role-agent-suggestion`: proposed user/project role definition or role capability.
+- `team-suggestion`: proposed EvoHub team composition and trigger.
+- `eval-set`: proposed regression cases for a skill, role, team, workflow, routing, tool-use, or subagent behavior.
+- `open-question`: unresolved issue that should not become accepted memory yet.
+
+## Scoring Rubric
+
+Use 1-5 integers. Keep the score approximate; it is a review aid, not a scientific metric.
+
+| Score | High value means | Low value means |
+|---|---|---|
+| `evidenceStrength` | Directly supported by verified/reviewed evidence | Mostly inferred or speculative |
+| `reuseValue` | Likely useful across future similar tasks | One-off or too narrow |
+| `actionability` | Clear trigger and next action | Vague or only descriptive |
+| `stability` | Likely to remain true for the repo/workflow | Depends on volatile context |
+| `novelty` | Adds knowledge not already captured | Duplicates existing guidance |
+| `privacyRisk` | Higher is worse: needs sensitive context | Redacted summary is enough |
+| `duplicationRisk` | Higher is worse: likely duplicate | Distinct from existing entries |
+
+Suggested write queue rule:
+
+- Propose accepted knowledge only when `evidenceStrength >= 4`, `reuseValue >= 3`, `actionability >= 3`, `privacyRisk <= 2`, and `duplicationRisk <= 3`.
+- Propose evos cases when the item is mainly about a trigger/intervention/outcome history.
+- Propose repo assets only when repeated future execution would benefit from a rule, skill, role, or team and explicit project opt-in can be obtained.
+- Propose evo eval sets whenever a skill, role-agent, team, workflow, routing, tool-use, or subagent behavior change is proposed. If no eval is useful, state why in the proposal.
+
+## Evolution Event Analysis
+
+Use reviewed event evidence to explain why the future behavior should change.
+
+| Signal | Good analysis asks |
+|---|---|
+| Task slices | Was the work decomposed into verifiable units with owner roles, dependencies, and stop conditions? |
+| Tool calls | Was the selected tool appropriate, gated by risk, and followed by verification or recovery? |
+| Skill invocations | Did the skill trigger correctly, receive the needed evidence, and produce a complete schema with privacy checks? |
+| Subagent lifecycle | Was the role necessary, bounded, mergeable, and verified without storing transcript content? |
+| Verification | Did required checks run at the right time and produce evidence for the claim? |
+
+Common skill defects:
+
+- `trigger-mismatch`: the skill was invoked when it should not have been, or missed when it should have run.
+- `input-gap`: required evidence class was missing.
+- `output-omission`: a required proposal, field, path, role tag, privacy check, or eval set was absent.
+- `inaccurate-claim`: output contradicted verified evidence.
+- `schema-drift`: output did not match the declared contract.
+- `privacy-defect`: output depended on raw private content.
+
+## Evo Eval Set Types
+
+| Type | Checks |
+|---|---|
+| `schema` | Required fields, enum values, ids, and status are present. |
+| `omission-detection` | Missing recommendations, evidence refs, privacy checks, or eval sets are caught. |
+| `privacy` | Raw prompt/source/command output/secrets are not stored. |
+| `routing` | A skill, workflow, role, or team should or should not trigger. |
+| `role-attention` | Role-tagged knowledge is selected only when scope, consent, and role policy match. |
+| `tool-use` | Tool choice, risk classification, and verification behavior are correct. |
+| `subagent-routing` | Role selection, scope, output contract, and merge requirements are correct. |
+
+## Storage Mapping
+
+| Candidate target | Canonical layer | Notes |
+|---|---|---|
+| `knowledge` | Accepted knowledge | Human-reviewable Markdown/JSON with provenance |
+| `evos` | Evolution cases | Case history with trigger, intervention, evidence, result |
+| `evo-eval-set` | Evolution eval sets | Regression cases tied to proposed or accepted behavior changes |
+| `repo-asset-proposal` | Proposal queue first | Never write project files by default |
+| `none` | Report only | Useful but not durable |
+
+Indexes, vector search, graph exports, and runtime caches are derived views. They must be rebuildable from accepted canonical records and must not store raw private content.
+
+## Source Notes
+
+- Google SRE postmortem practice: https://sre.google/sre-book/postmortem-culture/
+- US Army AAR guidance: https://www.first.army.mil/Portals/102/FM%207-0%20Appendix%20K.pdf
+- NASA Lessons Learned: https://www.nasa.gov/nasa-lessons-learned/
+- ADR references and templates: https://adr.github.io/
+- W3C SKOS Reference: https://www.w3.org/TR/skos-reference/
+- W3C PROV-O provenance ontology: https://www.w3.org/TR/prov-o/
+- OpenAI Agents SDK sessions/memory reference: https://openai.github.io/openai-agents-python/sessions/
+- Claude Code skills documentation: https://docs.anthropic.com/en/docs/claude-code/skills

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@evo-dev/evodev",
-  "version": "0.0.1-alpha",
+  "version": "0.0.1-alpha.1",
   "description": "AI Coding infrastructure CLI for real R&D workflows.",
   "type": "module",
   "repository": {
@@ -9,12 +9,9 @@
     "directory": "packages/cli"
   },
   "bin": {
-    "evodev": "dist/evodev"
+    "evodev": "./dist/evodev"
   },
-  "files": [
-    "dist",
-    "package.json"
-  ],
+  "files": ["dist", "package.json"],
   "engines": {
     "node": ">=20"
   },