@freetesh/zeno 0.9.0 → 0.9.1

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
   "name": "zeno",
-  "version": "0.9.0",
+  "version": "0.9.1",
   "description": "Keeps your domain knowledge and AI rules local and enforces them, so Claude hallucinates less.",
   "author": {
     "name": "Ritesh Firodiya",

package/README.md

@@ -1,10 +1,28 @@
-# zeno
+<p align="center">
+  <img src=".github/assets/icon.svg" width="96" height="96" alt="zeno icon">
+</p>
 
-A productivity tool for the whole product development lifecycle (PDLC), from
-idea to release. zeno keeps your domain knowledge, decisions and AI rules local,
-in your own repos, and enforces them: Claude searches them before it answers,
-weighs a request against them before it acts, and `zeno check` fails when code
-or docs break them. The AI hallucinates less, and your team ships faster.
+<h1 align="center">zeno</h1>
+
+<p align="center">
+  <b>Facts, not assumptions.</b> Your rules, kept in your repo. Enforced.<br>
+  A Claude Code plugin and CLI · MIT
+</p>
+
+<p align="center">
+  <a href="https://www.npmjs.com/package/@freetesh/zeno"><img alt="npm" src="https://img.shields.io/npm/v/@freetesh/zeno"></a>
+  <a href="LICENSE"><img alt="MIT license" src="https://img.shields.io/badge/license-MIT-blue"></a>
+</p>
+
+zeno keeps your domain knowledge, decisions and AI rules in your own repos, and
+enforces them. Claude searches them before it answers. It weighs each request
+against them before it acts, and it checks every claim in the request against
+facts. `zeno check` fails when code or docs break a rule. The AI guesses less,
+and you redo less work.
+
+<p align="center">
+  <img src=".github/assets/demo.svg" alt="zeno weighs a request. Two of three claims have no facts and the request breaks a decided rule, so it pushes back and stops until the user brings facts, agrees to terms, or drops it.">
+</p>
 
 It has two halves that read the same config:
 
@@ -87,17 +105,6 @@ starter `.dependency-cruiser.cjs` to your layers. `evals/fixtures/streaks` is a
 small product with a wiki and decision records, if you want to see the
 `.context/` layout before touching your own repo.
 
-For local development of zeno itself, link the repo as a skills-dir plugin so
-edits apply on the next session: `ln -s "$PWD" ~/.claude/skills/zeno`.
-Run the CLI from source (Node 23.6+ runs the TypeScript directly):
-`pnpm install && ln -s "$PWD/cli/src/index.ts" ~/.local/bin/zeno`.
-`pnpm test`, `pnpm typecheck` and `pnpm build` run from the repo root.
-
-**Releasing.** Bump `version` in `package.json` and `.claude-plugin/plugin.json`,
-then push or merge to `main`. The `release` workflow runs the tests, publishes
-`@freetesh/zeno` to npm, tags `vX.Y.Z` and creates the GitHub release. A push
-without a bump releases nothing. It needs the `NPM_TOKEN` Actions secret.
-
 ## CLI
 
 ```bash
@@ -145,7 +152,7 @@ context:
 
 ```yaml
 # <repo>/.claude/zeno.yaml — written by `zeno init`
-zeno: 0.6.0
+zeno: 0.9.0
 kind: expo-app                      # expo-app | web | content
 modules: [docs, knowledge, code, listing]   # all optional; design is added when .context/designs exists, metrics only when asked
 packs: [expo]
@@ -164,7 +171,7 @@ carry a `reason:`, and `zeno check` lists every override.
 
 | zeno default | What it holds |
 |---|---|
-| `constitution.md` | Principles C-01–C-13 a request is weighed against. A team adds C-20+ in its own `constitution.md`. |
+| `constitution.md` | Principles C-01–C-15 a request is weighed against. A team adds C-20+ in its own `constitution.md`. |
 | `wiki-schema.md` | Wiki page types, frontmatter, required sections, lint rules |
 | `context-layout.md` | The `.context/` ten-folder layout, `features/` and `tasks.md` |
 | `agent-contract.md` | What every agent does before, during and after work |
@@ -199,3 +206,16 @@ scripts/          log-verdict.mjs — append-only override log
 cli/              the zeno CLI (TypeScript, vitest; built to cli/dist for npm)
 evals/            plugin evals and the fixture product
 ```
+
+## Develop zeno
+
+Link the repo as a skills-dir plugin so edits apply on the next session:
+`ln -s "$PWD" ~/.claude/skills/zeno`.
+Run the CLI from source (Node 23.6+ runs the TypeScript directly):
+`pnpm install && ln -s "$PWD/cli/src/index.ts" ~/.local/bin/zeno`.
+`pnpm test`, `pnpm typecheck` and `pnpm build` run from the repo root.
+
+**Releasing.** Bump `version` in `package.json` and `.claude-plugin/plugin.json`,
+then push or merge to `main`. The `release` workflow runs the tests, publishes
+`@freetesh/zeno` to npm, tags `vX.Y.Z` and creates the GitHub release. A push
+without a bump releases nothing. It needs the `NPM_TOKEN` Actions secret.

package/cli/dist/checks/sources.js

@@ -3,8 +3,9 @@ import { join } from "node:path";
 import { parseFrontmatter } from "../lib/frontmatter.js";
 import { wikiPages } from "./wiki-frontmatter.js";
 // zeno has no connectors: a source page must say which MCP server, skill or CLI
-// reads it, or the weigh gate cannot turn a claim into a fact.
-const ACCESS = /^(mcp|skill|cli):\s*(\S+)/;
+// reads it, or that a person reads it by hand (`manual:`), or the weigh gate
+// cannot turn a claim into a fact.
+const ACCESS = /^(mcp|skill|cli|manual):\s*(\S+)/;
 const HOW_TO_QUERY = /^## How to query\s*$/m;
 function accessValue(body, id) {
     const row = body.split("\n").find((line) => line.replace(/\s/g, "").startsWith(`|${id}.ACCESS|`));
@@ -13,7 +14,7 @@ function accessValue(body, id) {
 export const sources = {
     id: "sources",
     module: "docs",
-    description: "each SOURCE.* page says how to read it (mcp, skill or a cli in doctor.tools) and has a How to query section",
+    description: "each SOURCE.* page says how to read it (mcp, skill, manual, or a cli in doctor.tools) and has a How to query section",
     run({ repo, config }) {
         const tools = new Set(config.doctor.tools.map((tool) => tool.tool));
         return wikiPages(repo).flatMap((file) => {
@@ -30,7 +31,7 @@ export const sources = {
             if (access === null)
                 add(`no ${id}.ACCESS row — say how to read it`);
             else if (!match)
-                add(`${id}.ACCESS is "${access}" — write mcp: <server>, skill: <name> or cli: <command>`);
+                add(`${id}.ACCESS is "${access}" — write mcp: <server>, skill: <name>, cli: <command> or manual: <where>`);
             else if (match[1] === "cli" && !tools.has(match[2]))
                 add(`cli ${match[2]} is not in doctor.tools — zeno doctor cannot report it missing`);
             return findings;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@freetesh/zeno",
-  "version": "0.9.0",
+  "version": "0.9.1",
   "description": "zeno CLI: keep your domain knowledge and AI rules in your repo, and enforce them.",
   "license": "MIT",
   "author": "Ritesh Firodiya",

package/skills/weigh/SKILL.md

@@ -49,8 +49,9 @@ product's `.claude/zeno.yaml` may tighten this under `weigh.trivial`.
    **not backed**, with the fact and its source. Look in what step 3 read, the
    code and `.context/raw/`. When that is not enough, look for a data source:
    query qmd for `SOURCE` pages in this product's wiki. Each says what it holds,
-   how to read it (`mcp:`, `skill:` or `cli:`) and which claims it answers. If
-   one fits, run its query and follow the query rules in `wiki-schema.md`
+   how to read it (`mcp:`, `skill:`, `cli:` or `manual:`) and which claims it
+   answers. For `manual:`, ask the user for the numbers and say where to find
+   them; do not guess. If one fits, run its query and follow the query rules in `wiki-schema.md`
    ("Data sources"): read only, one or two small queries, counts not people.
    Save a result that decides the verdict to `.context/raw/`. If the tool is not
    available, say so and leave the claim not backed. If no source fits, name
@@ -114,7 +115,9 @@ Open questions: <only if a real ambiguity blocks a good answer>
   already accepted it and **Assumed** is "none"; otherwise stop and ask.
 - **PUSH BACK** → stop. Do not start the work, not even a part of it.
 - **Something is assumed** → stop, and give the user three choices: bring the
-  facts (and say where they would go), agree to terms, or drop it.
+  facts (and say where they would go), agree to terms, or drop it. Any terms
+  you show, here or later, are a numbered list, so the user can agree line by
+  line.
 
 Write the whole reply in plain words (C-15): short sentences, common words, no
 jargon the wiki does not define.

package/standards/wiki-schema.md

@@ -67,8 +67,9 @@ The claims this source can answer, and one example query for each.
 ```
 
 zeno has no connector of its own. The repo picks what does the reading, and
-`ACCESS` names it: `mcp: <server>`, `skill: <name>` or `cli: <command>`. A
-`cli:` must also be in `doctor.tools` in `.claude/zeno.yaml`, so `zeno doctor`
+`ACCESS` names it: `mcp: <server>`, `skill: <name>`, `cli: <command>`, or
+`manual: <where>` for a dashboard with no API, which a person reads and pastes
+into `raw/`. A `cli:` must also be in `doctor.tools` in `.claude/zeno.yaml`, so `zeno doctor`
 reports when it is missing. `zeno check` fails a source page that breaks either
 rule or has no `## How to query`. Never put a key or token on the page.