lurqrun 0.0.8 → 0.0.10

package/dist/index.d.ts

@@ -208,6 +208,18 @@ interface ScoreBreakdown {
     reliability: number;
     efficiency: number | null;
     quality: number | null;
+    /**
+     * Field evidence (§3.1) — how this package actually fared after agents
+     * installed it, from `recommendation_outcomes`. `null` means no reports yet
+     * and the weight is redistributed, exactly like `efficiency`.
+     *
+     * Optional rather than required because it postdates the rows already in
+     * `packages.score_breakdown`: a stored breakdown from before this shipped
+     * decodes with the key absent, and `undefined` must read as "no evidence",
+     * never as 0. Treating it as 0 would drop every un-reported package's health
+     * the moment this deployed.
+     */
+    field?: number | null;
 }
 /**
  * Structured usage guide generated at ingest (product refinement: lurq explains,
@@ -284,13 +296,29 @@ interface VerifyOutput {
     advisoryCount: number;
 }
 
-/** Static identifiers shared across the CLI and MCP server. */
 declare const SERVER_NAME = "lurq";
 /** Published npm package name (the CLI command and MCP nickname stay `lurq`).
  *  Keep in sync with package.json "name". */
 declare const PACKAGE_NAME = "lurqrun";
-/** Keep in sync with package.json "version". */
-declare const VERSION = "0.0.8";
+/**
+ * Read from package.json rather than restated, so a release bump cannot leave
+ * it behind. This used to be a literal under a "keep in sync" comment, and it
+ * drifted the moment someone bumped package.json alone: 0.0.9 shipped to npm
+ * announcing itself as 0.0.8.
+ *
+ * That is not only cosmetic. github/workflow.ts defaults `cliSpec()` to this
+ * value and bakes it into the `npx lurqrun@<v>` line of every workflow lurq
+ * generates, so a stale constant writes users a CI job pinned to a version
+ * other than the one that wrote it.
+ *
+ * The import is resolved at build time — esbuild inlines the JSON, so there is
+ * no file read at runtime and no dependence on where the bundle sits on disk.
+ * That last part is why this is an import and not a `readFileSync` of a path
+ * relative to `import.meta.url`: the public bin lands at dist/bin/lurq.js and
+ * the library entry at dist/index.js, so any relative path correct for one is
+ * wrong for the other.
+ */
+declare const VERSION: string;
 /** Default hosted endpoint the install wizard writes into agent configs. The
  *  marketing site is `lurq.run`; the MCP service lives on the `api.` subdomain.
  *  Overridable per-invocation with `lurq install --url …` or `LURQ_ENDPOINT`. */