@onlooker-community/ecosystem 0.34.0 → 0.43.0

package/plugins/librarian/scripts/lib/librarian-lesson-validate.sh

@@ -57,6 +57,82 @@ librarian_lesson_valid_range() {
 	[[ "$r" =~ $pattern ]]
 }
 
+# Everything both validators check, excluding the scope branch. Kept in one
+# place because it mirrors the vendored sub-schemas line for line; a second
+# copy is how the jq rules and the schema drifted apart once already.
+#
+# Composed into a jq program by each validator, which appends its own scope
+# clause. artifact_ids, session_ids, and observed_at are checked against the
+# same patterns as the vendored lesson-evidence.subschema.json (ULID,
+# non-empty string, RFC3339 date-time) — a provenance-less artifact
+# (session_id/created_at stitched in as "") must fail here, not pass through
+# and get buried permanently once librarian_lesson_seen marks it handled.
+#
+# The `keys - [...] | length == 0` checks mirror `additionalProperties:
+# false` on the vendored `evidence` and `applies_to` sub-schemas, and the
+# `all(type == "string" and length > 0)` checks mirror their array items'
+# `minLength: 1`. Neither is decorative: without them a model that
+# "helpfully" adds an extra field, or emits an empty-string array entry,
+# produces a proposal that passes here but fails ajv against the contract it
+# claims to satisfy — and lessons are meant to be shared with other people.
+# Each `keys` call is guarded by a preceding `type == "object"` check in the
+# same `and` chain: jq's `and` short-circuits left to right, so `keys` on a
+# missing/non-object value is never reached.
+_LIBRARIAN_LESSON_STRUCTURAL='
+	(.claim | type) == "string" and (.claim | length) > 0
+	and (.rationale | type) == "string" and (.rationale | length) > 0
+	and (.evidence | type) == "object"
+	and ((.evidence | keys) - ["artifact_ids", "session_ids", "project_key", "observed_at", "resolution"] | length) == 0
+	and (.evidence.artifact_ids | type) == "array" and (.evidence.artifact_ids | length) > 0
+	and (.evidence.artifact_ids | all(type == "string" and test("^[0-9A-HJKMNP-TV-Z]{26}$")))
+	and (.evidence.session_ids | type) == "array" and (.evidence.session_ids | length) > 0
+	and (.evidence.session_ids | all(type == "string" and length > 0))
+	and (.evidence.project_key | type) == "string"
+	and (.evidence.project_key | test("^[0-9a-f]{12}$"))
+	and (.evidence.observed_at | type) == "string"
+	and (.evidence.observed_at | test("^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"))
+	and (.evidence.resolution | type) == "string" and (.evidence.resolution | length) > 0
+	and (.applies_to | type) == "object"
+	and ((.applies_to | keys) - ["stack", "scope", "file_patterns", "task_kinds"] | length) == 0
+	and (.applies_to.stack | type) == "array" and (.applies_to.stack | length) > 0
+	and (.applies_to.stack | all(type == "string" and length > 0))
+	and (.applies_to.file_patterns | type) == "array"
+	and (.applies_to.file_patterns | all(type == "string" and length > 0))
+	and (.applies_to.task_kinds | type) == "array"
+	and (.applies_to.task_kinds | all(type == "string" and length > 0))
+'
+
+# The versioned branch, shared by both validators.
+_LIBRARIAN_LESSON_SCOPE_VERSIONED='
+	.applies_to.scope.kind == "versioned"
+	and ((.applies_to.scope | keys) - ["kind", "versions"] | length) == 0
+	and (.applies_to.scope.versions | type) == "object"
+	and (.applies_to.scope.versions | length) > 0
+'
+
+# Checks that only apply to a versioned candidate: the cross-field rule JSON
+# Schema cannot express, and the range pattern on each value.
+#
+# NUL-delimited, not newline-delimited: a range value with an embedded newline
+# would otherwise split into two lines that can each pass individually even
+# though the single value they came from is not a valid range. Do not skip
+# empty reads either — jq never emits one for a non-empty object of strings,
+# so an empty read means the range itself is empty, which is invalid.
+_librarian_lesson_check_versions() {
+	local candidate="$1"
+
+	printf '%s' "$candidate" | jq -e '
+		(.applies_to.scope.versions | keys) - .applies_to.stack | length == 0
+	' >/dev/null 2>&1 || return 1
+
+	local range
+	while IFS= read -r -d '' range; do
+		librarian_lesson_valid_range "$range" || return 1
+	done < <(printf '%s' "$candidate" | jq --raw-output0 '.applies_to.scope.versions[]' 2>/dev/null)
+
+	return 0
+}
+
 # Validate a full candidate. Prints nothing on success; prints a reason slug
 # to stderr on failure.
 #
@@ -65,76 +141,69 @@ librarian_lesson_validate_candidate() {
 	local candidate="${1:-}"
 	[[ -z "$candidate" ]] && { printf 'schema_invalid\n' >&2; return 1; }
 
-	# Structural shape, including the versioned-only rule and a non-empty
-	# resolution. `versions` must be a non-empty object. artifact_ids,
-	# session_ids, and observed_at are checked against the same patterns as
-	# the vendored lesson-evidence.subschema.json (ULID, non-empty string,
-	# RFC3339 date-time) — a provenance-less artifact (session_id/created_at
-	# stitched in as "") must fail here, not pass through and get buried
-	# permanently once librarian_lesson_seen marks it handled.
-	#
-	# The `keys - [...] | length == 0` checks mirror `additionalProperties:
-	# false` on the vendored `evidence` and `applies_to` sub-schemas
-	# (including the "versioned" scope branch), and the `all(type ==
-	# "string" and length > 0)` checks mirror their array items' `minLength:
-	# 1`. Neither is decorative: without them a model that "helpfully" adds
-	# an extra field, or emits an empty-string array entry, produces a
-	# proposal that passes here but fails ajv against the contract it claims
-	# to satisfy — and lessons are meant to be shared with other people. Each
-	# `keys` call is guarded by a preceding `type == "object"` check in the
-	# same `and` chain: jq's `and` short-circuits left to right, so `keys` on
-	# a missing/non-object value is never reached.
-	if ! printf '%s' "$candidate" | jq -e '
-		(.claim | type) == "string" and (.claim | length) > 0
-		and (.rationale | type) == "string" and (.rationale | length) > 0
-		and (.evidence | type) == "object"
-		and ((.evidence | keys) - ["artifact_ids", "session_ids", "project_key", "observed_at", "resolution"] | length) == 0
-		and (.evidence.artifact_ids | type) == "array" and (.evidence.artifact_ids | length) > 0
-		and (.evidence.artifact_ids | all(type == "string" and test("^[0-9A-HJKMNP-TV-Z]{26}$")))
-		and (.evidence.session_ids | type) == "array" and (.evidence.session_ids | length) > 0
-		and (.evidence.session_ids | all(type == "string" and length > 0))
-		and (.evidence.project_key | type) == "string"
-		and (.evidence.project_key | test("^[0-9a-f]{12}$"))
-		and (.evidence.observed_at | type) == "string"
-		and (.evidence.observed_at | test("^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"))
-		and (.evidence.resolution | type) == "string" and (.evidence.resolution | length) > 0
-		and (.applies_to | type) == "object"
-		and ((.applies_to | keys) - ["stack", "scope", "file_patterns", "task_kinds"] | length) == 0
-		and (.applies_to.stack | type) == "array" and (.applies_to.stack | length) > 0
-		and (.applies_to.stack | all(type == "string" and length > 0))
-		and (.applies_to.file_patterns | type) == "array"
-		and (.applies_to.file_patterns | all(type == "string" and length > 0))
-		and (.applies_to.task_kinds | type) == "array"
-		and (.applies_to.task_kinds | all(type == "string" and length > 0))
-		and .applies_to.scope.kind == "versioned"
-		and ((.applies_to.scope | keys) - ["kind", "versions"] | length) == 0
-		and (.applies_to.scope.versions | type) == "object"
-		and (.applies_to.scope.versions | length) > 0
-	' >/dev/null 2>&1; then
+	# versioned ONLY. This is the guarantee that stops the transform minting
+	# lessons that never expire: private lessons run no jury, so nothing
+	# downstream would catch a bad version_independent claim. A human may
+	# assert that branch — see librarian_lesson_validate_confirmed — because
+	# the constraint in the review path forces it to a judged visibility.
+	if ! printf '%s' "$candidate" | jq -e \
+		"${_LIBRARIAN_LESSON_STRUCTURAL} and ${_LIBRARIAN_LESSON_SCOPE_VERSIONED}" \
+		>/dev/null 2>&1; then
 		printf 'schema_invalid\n' >&2
 		return 1
 	fi
 
-	# Cross-field rule JSON Schema cannot express: every versions key must
-	# name an entry in stack.
-	if ! printf '%s' "$candidate" | jq -e '
-		(.applies_to.scope.versions | keys) - .applies_to.stack | length == 0
-	' >/dev/null 2>&1; then
+	_librarian_lesson_check_versions "$candidate" || {
+		printf 'schema_invalid\n' >&2
+		return 1
+	}
+
+	return 0
+}
+
+# Validate a candidate a human has confirmed.
+#
+# Identical to librarian_lesson_validate_candidate except that it also permits
+# the version_independent branch, which requires a non-empty justification.
+#
+# The two are NOT redundant and the difference is not stylistic. They encode
+# different trust: this one bounds what a human may assert AND a jury will then
+# check, because the review path refuses version_independent at private
+# visibility. The transform's validator bounds what a model may assert
+# unsupervised, where nothing downstream would catch a bad claim. Deleting
+# either collapses that distinction.
+#
+# Usage: librarian_lesson_validate_confirmed <candidate_json>
+librarian_lesson_validate_confirmed() {
+	local candidate="${1:-}"
+	[[ -z "$candidate" ]] && { printf 'schema_invalid\n' >&2; return 1; }
+
+	local scope_clause='
+		(
+			('"${_LIBRARIAN_LESSON_SCOPE_VERSIONED}"')
+			or (
+				.applies_to.scope.kind == "version_independent"
+				and ((.applies_to.scope | keys) - ["kind", "justification"] | length) == 0
+				and (.applies_to.scope.justification | type) == "string"
+				and (.applies_to.scope.justification | length) > 0
+			)
+		)
+	'
+
+	if ! printf '%s' "$candidate" | jq -e \
+		"${_LIBRARIAN_LESSON_STRUCTURAL} and ${scope_clause}" \
+		>/dev/null 2>&1; then
 		printf 'schema_invalid\n' >&2
 		return 1
 	fi
 
-	# Every range must satisfy the vendored pattern. NUL-delimited, not
-	# newline-delimited: a range value with an embedded newline would
-	# otherwise split into two lines that can each pass individually even
-	# though the single value they came from is not a valid range. Do not
-	# skip empty reads either — jq never emits one for a non-empty object
-	# of strings, so an empty read means the range itself is empty, and
-	# librarian_lesson_valid_range already rejects that.
-	local range
-	while IFS= read -r -d '' range; do
-		librarian_lesson_valid_range "$range" || { printf 'schema_invalid\n' >&2; return 1; }
-	done < <(printf '%s' "$candidate" | jq --raw-output0 '.applies_to.scope.versions[]' 2>/dev/null)
+	# Range and subset rules apply only to the versioned branch.
+	if printf '%s' "$candidate" | jq -e '.applies_to.scope.kind == "versioned"' >/dev/null 2>&1; then
+		_librarian_lesson_check_versions "$candidate" || {
+			printf 'schema_invalid\n' >&2
+			return 1
+		}
+	fi
 
 	return 0
 }

package/plugins/librarian/skills/librarian/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: librarian
-description: Review the librarian's pending memory promotion proposals queued from past sessions. Walk pending entries with the user one at a time, surfacing provenance and conflict state, and route each to accept (writes the typed memory file and updates MEMORY.md), reject (writes a body-hash tombstone so the same content won't re-propose), or defer (leave in the queue). Use when the user types `/librarian`, `/librarian review`, `/librarian triage`, `/librarian status`, or `/librarian list`, or asks to review librarian proposals.
+description: Review the librarian's pending memory promotion proposals and lesson candidates queued from past sessions. Walk pending entries with the user one at a time, surfacing provenance and conflict state, and route each to accept (writes the typed memory file and updates MEMORY.md), reject (writes a body-hash tombstone so the same content won't re-propose), or defer (leave in the queue). Lesson candidates route separately to confirm (with a visibility), pass, or defer, with unconfirm to take back a confirmation before the jury sees it. Use when the user types `/librarian`, `/librarian review`, `/librarian triage`, `/librarian status`, `/librarian list`, `/librarian lessons`, `/librarian lessons review`, or `/librarian lessons judge`, or asks to review librarian proposals or lesson candidates.
 ---
 
 # Librarian: Promotion Queue Review
@@ -17,6 +17,9 @@ Read the user's argument after `/librarian`:
 - `list` → print the pending table and stop
 - `status` → print one-line counts and stop
 - a proposal id (starts with a ULID-shaped string) → jump straight to **show** for that id
+- `lessons`, `lessons review` → **walk the lesson queue** (see below)
+- `lessons list` / `lessons status` → print and stop (`lessons list --confirmed` lists confirmed lessons instead of pending ones)
+- `lessons judge` → **run the jury over confirmed candidates** (see below)
 
 If the user passes a free-form intent ("clear out the queue", "what's pending?"), map it to `review` or `list` as appropriate.
 
@@ -26,13 +29,23 @@ Source the plugin helpers and invoke `librarian_cli`. Run this in a single bash
 
 ```bash
 set -uo pipefail
+PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(cd "$(dirname "${BASH_SOURCE[0]}")/../.." && pwd)}"
+export CLAUDE_PLUGIN_ROOT="$PLUGIN_ROOT"
 source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-config.sh"
 source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-project-key.sh"
 source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-storage.sh"
 source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-emit.sh"
+source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-lesson-storage.sh"
+source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-lesson-validate.sh"
+source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-lesson-review.sh"
+source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-lesson-rubric.sh"
+source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-lesson-judge.sh"
+source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-author-key.sh"
+source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-lesson-promote.sh"
 source "$CLAUDE_PLUGIN_ROOT/scripts/lib/librarian-cli.sh"
 
 # action is one of: list | show <id> | accept <id> | reject <id> [reason] | defer <id> | status
+# or: lessons <list [--confirmed]|show <id>|confirm <id> <visibility> [--justification TEXT]|pass <id> [reason]|unconfirm <id>|defer <id>|status>
 librarian_cli "<action>" "<args...>"
 ```
 
@@ -55,9 +68,93 @@ For `review` (the default), loop:
 
 For `list` and `status`, just call `librarian_cli <action>` once and render the output.
 
+## The lesson walkthrough
+
+Lesson candidates are a separate queue from memory proposals — confirming one is a step toward publishing beyond this machine, not writing a local file, so it gets its own walk rather than folding into the loop above.
+
+For `lessons` / `lessons review` (default for the `lessons` route), loop:
+
+1. Call `librarian_cli lessons list`. If the output says `No pending lessons.`, tell the user the queue is clear and stop.
+2. Take the first pending id. Call `librarian_cli lessons show <id>` to render it.
+3. Present the candidate to the user in plain English, showing: `claim`, `rationale`, `evidence.resolution`, `applies_to.stack`, `scope.versions` (or the scope kind if unversioned), and the source artifact id.
+4. Ask the user how to route it: **confirm** (with a visibility), **pass** (optionally with a reason), or **defer**.
+5. Route the answer:
+   - **confirm** → `librarian_cli lessons confirm <id> <visibility> [--justification TEXT]`. Confirming **requires** a visibility (`private`, `org`, or `public`) — never call confirm without one. `--justification` rewrites the scope to `version_independent` and requires `org` or `public` visibility: a `private` lesson runs no jury, so its justification would go unchecked. If the user wants version-independence at `private`, tell them why it's refused rather than silently dropping the justification.
+   - **pass** → `librarian_cli lessons pass <id> "<reason>"`. The reason is optional.
+   - **defer** → `librarian_cli lessons defer <id>`. The candidate stays pending; mention it'll resurface next session.
+6. After each routed decision, fetch the next pending id and repeat. When `list` returns no rows, finish with `librarian_cli lessons status` so the user sees the final count.
+
+A confirm made at the wrong visibility isn't stuck that way — `librarian_cli lessons unconfirm <id>` takes it back, returning the lesson to pending so the user can confirm it again at the right visibility. It only works on a `confirmed` lesson: a `passed` lesson stays passed, because that decision already has its own record and unconfirm won't touch it.
+
+Finding the lesson is its own step, because `lessons list` shows only the pending queue and a confirmed lesson is by definition not in it. The user regretting a confirm is usually back in a later session with the claim in mind and no id, so start from `librarian_cli lessons list --confirmed`, which prints the same `<id>  <claim>` rows for everything confirmed and not yet judged. Then `librarian_cli lessons show <id>` — its `visibility` line is what tells you which tier the lesson currently sits at, and whether unconfirming is what the user actually wants.
+
+For `lessons list`, `lessons list --confirmed`, and `lessons status`, just call `librarian_cli lessons <action>` once and render the output.
+
+For `lessons judge`, run the jury over confirmed candidates:
+
+1. Call `librarian_cli lessons list --confirmed --json`. Each row carries `id`,
+   `visibility`, and the full `candidate`. If the array is empty, tell the user
+   there is nothing awaiting judgment and stop.
+2. **Report the batch before spending anything.** Say how many candidates are
+   confirmed and how many are `public`, and ask whether to proceed. This is the
+   most expensive step in the pipeline. If the user declines, stop — nothing is
+   written and every candidate stays `confirmed`.
+3. For each candidate, in order:
+   - **If `visibility` is `private`, dispatch no judges at all.** Call
+     `librarian_cli lessons judge <id> '[]'` and move on. Private lessons run no
+     jury; that is what makes cost scale with intent rather than artifact volume.
+   - Otherwise spawn **both** `tribunal-judge-standard` and
+     `tribunal-judge-adversarial` with the Task tool. Give each the candidate's
+     `claim`, `rationale`, `evidence.resolution`, and `applies_to`, plus the
+     rubric criteria for its visibility: for `org`, grounding / scope_accuracy /
+     generality; for `public`, those three plus **disclosure** — does the text
+     leak a credential, internal hostname, customer name, or proprietary detail?
+   - Each judge returns a JSON object with `score`, `passed`, `judge_type`,
+     `feedback_summary`, and `criterion_scores` — a map from **each rubric
+     criterion name you gave it** to a score in `[0,1]`. **Tell each judge it
+     must score every criterion you listed.** Every criterion in both lesson
+     rubrics carries a floor, and a floor no judge scored makes the whole panel
+     UNJUDGED — the candidate stays `confirmed` and is re-judged, at full cost,
+     on the next run. So an omission here does not soften a verdict; it prevents
+     one. That differs from tribunal, which degrades to a plain mean instead of
+     refusing, and the shared judge agents describe tribunal's behavior.
+     A judge that genuinely cannot assess a criterion should say so in
+     `feedback_summary` and score its honest worst case rather than omit the
+     key. Collect both verdicts into a JSON array **verbatim** — never summarize
+     or reconstruct a judge's verdict.
+   - Call `librarian_cli lessons judge <id> '<verdicts-json>'`. Record before
+     moving to the next candidate, so an interrupted run costs at most one
+     re-judgment. Recording a verdict also promotes the lesson in the same
+     call — approved candidates land in the pool and rejected ones in the
+     declined ledger, with no separate step. If the output instead says the
+     lesson was judged but not promoted, the verdict is already recorded;
+     retry once with `librarian_cli lessons promote <id>`, not by re-judging —
+     re-judging would spend tokens again for a verdict that already exists.
+     **If that retry itself fails, do not loop on it.** Add the id to the
+     judged-but-not-promoted bucket and move to the next candidate; report it
+     at the end alongside the retry command rather than retrying again here.
+4. **If either judge fails to return parseable JSON, do not invent a verdict and
+   do not drop that judge.** The array must still have one entry per empaneled
+   judge: put that judge's raw output, as a JSON string, in its slot instead of
+   a parsed verdict object. Pass that array to the CLI; it will exit 2, leave
+   the candidate `confirmed`, and report that it could not be judged. Collect
+   those ids and list them at the end so the user knows to re-run. A broken judge
+   must never become a rejection — the artifact's watermark has already moved,
+   so a false rejection buries a good lesson permanently.
+5. Finish by reporting counts: approved, rejected, could-not-judge, and
+   **judged but not promoted** (verdict recorded, pool write still pending —
+   list these ids with `librarian_cli lessons promote <id>` as the next step).
+   Don't fold this bucket into "approved": a lesson here has no pool entry yet.
+
+`scope_accuracy` is the criterion that matters most on a `version_independent`
+candidate. The schema guarantees such a lesson **carries** a justification; this
+criterion asks whether it is **true**.
+
 ## Safety rules
 
 - **Never accept a proposal on the user's behalf without explicit confirmation.** Accepting writes a file to the user's typed memory store and that memory will be loaded into every future session in this project. Treat each accept like editing a CLAUDE.md.
 - **Do not edit MEMORY.md directly.** `accept` updates the index for you; hand-editing risks duplicate entries or stale links.
 - **Do not delete proposal files manually.** Reject (with a tombstone) is the cleanup path. Direct deletion would let the same body re-propose on the next scan.
 - **Conflict-state proposals deserve a careful read.** When `conflict_state` is `near_duplicate` or `contradicts_existing`, surface the conflict to the user before they decide. Often the right answer is reject (the existing memory is better) or accept-and-then-prune (you can mention that follow-up).
+- **Never confirm a lesson on the user's behalf without an explicit visibility.** Confirming commits a candidate toward leaving this machine — a decision separate from, and heavier than, accepting a memory proposal.
+- **Never dispatch judges without reporting the batch and getting the user's go-ahead first.** Judge dispatch is the most expensive step in the pipeline; report the confirmed and `public` counts and wait before spawning a single judge.

package/plugins/tribunal/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "tribunal",
-  "version": "1.1.2",
+  "version": "1.2.7",
   "description": "Multi-agent execution with LLM-as-a-Judge quality gates. An Actor performs work; a jury of typed Judges scores it against a project-overridable rubric; a Meta-Judge reviews the jury for bias; the gate decides accept, retry, or exhaust. Grounded in LLM-as-a-Judge (Zheng et al. 2023) and LLM-as-a-Meta-Judge (Wu et al. 2024). Builds on the Onlooker ecosystem plugin.",
   "author": {
     "name": "Onlooker Community",

package/plugins/tribunal/CHANGELOG.md

@@ -1,5 +1,68 @@
 # Changelog
 
+## [1.2.7](https://github.com/onlooker-community/ecosystem/compare/tribunal-v1.2.6...tribunal-v1.2.7) (2026-08-16)
+
+
+### Bug Fixes
+
+* **tribunal:** let every blocking arm name the floor it tripped over :label: ([#166](https://github.com/onlooker-community/ecosystem/issues/166)) ([1819b5f](https://github.com/onlooker-community/ecosystem/commit/1819b5f7ad0348584bcb0e72e28c9af153ba3a4d))
+
+## [1.2.6](https://github.com/onlooker-community/ecosystem/compare/tribunal-v1.2.5...tribunal-v1.2.6) (2026-08-16)
+
+
+### Bug Fixes
+
+* **tribunal:** stop a low criterion from hiding why the panel failed :arrows_counterclockwise: ([#164](https://github.com/onlooker-community/ecosystem/issues/164)) ([a3ec128](https://github.com/onlooker-community/ecosystem/commit/a3ec128f1e2e723e02396580b9ffbcff26f0787f))
+
+## [1.2.5](https://github.com/onlooker-community/ecosystem/compare/tribunal-v1.2.4...tribunal-v1.2.5) (2026-08-16)
+
+
+### Bug Fixes
+
+* **tribunal:** a floor you cannot read is a floor you cannot clear :lock: ([#162](https://github.com/onlooker-community/ecosystem/issues/162)) ([4ff2ec0](https://github.com/onlooker-community/ecosystem/commit/4ff2ec0f772af51ad4b5ea631ae2d3c68d229499))
+
+## [1.2.4](https://github.com/onlooker-community/ecosystem/compare/tribunal-v1.2.3...tribunal-v1.2.4) (2026-08-16)
+
+
+### Bug Fixes
+
+* **tribunal:** refuse a score that is not on the scale it claims :straight_ruler: ([#160](https://github.com/onlooker-community/ecosystem/issues/160)) ([bab2855](https://github.com/onlooker-community/ecosystem/commit/bab28558a68402c1dd67623f469467fd99302ba6))
+
+## [1.2.3](https://github.com/onlooker-community/ecosystem/compare/tribunal-v1.2.2...tribunal-v1.2.3) (2026-08-16)
+
+
+### Bug Fixes
+
+* **tribunal:** stop a verdict nobody scored from voting to approve :no_entry: ([#158](https://github.com/onlooker-community/ecosystem/issues/158)) ([1d6c2dc](https://github.com/onlooker-community/ecosystem/commit/1d6c2dc9c8f5833891732dc7e6637c496ba81f6f))
+
+## [1.2.2](https://github.com/onlooker-community/ecosystem/compare/tribunal-v1.2.1...tribunal-v1.2.2) (2026-08-15)
+
+
+### Bug Fixes
+
+* **tribunal:** drop scoreless verdicts instead of averaging them in :bug: ([#154](https://github.com/onlooker-community/ecosystem/issues/154)) ([f546757](https://github.com/onlooker-community/ecosystem/commit/f5467574f08094b0369f0bd699983cb41ded2cc3))
+
+## [1.2.1](https://github.com/onlooker-community/ecosystem/compare/tribunal-v1.2.0...tribunal-v1.2.1) (2026-08-15)
+
+
+### Bug Fixes
+
+* **tribunal:** close two ways a criterion floor could still be escaped :relieved: ([#152](https://github.com/onlooker-community/ecosystem/issues/152)) ([5b2ddee](https://github.com/onlooker-community/ecosystem/commit/5b2ddee8a787ba0f3e8656a6522b12f348f74859))
+
+## [1.2.0](https://github.com/onlooker-community/ecosystem/compare/tribunal-v1.1.3...tribunal-v1.2.0) (2026-08-15)
+
+
+### Features
+
+* **tribunal,librarian:** make rubric weights and min_pass floors real :straight_ruler: ([#150](https://github.com/onlooker-community/ecosystem/issues/150)) ([f8f8e28](https://github.com/onlooker-community/ecosystem/commit/f8f8e28b60f6d13d5a2a54e26ca284137b77f99a))
+
+## [1.1.3](https://github.com/onlooker-community/ecosystem/compare/tribunal-v1.1.2...tribunal-v1.1.3) (2026-08-10)
+
+
+### Bug Fixes
+
+* make the local bats suite tell the truth :mag: ([#135](https://github.com/onlooker-community/ecosystem/issues/135)) ([f0763e0](https://github.com/onlooker-community/ecosystem/commit/f0763e09f3caf2d39c89f28befd12567af0af845))
+
 ## [1.1.2](https://github.com/onlooker-community/ecosystem/compare/tribunal-v1.1.1...tribunal-v1.1.2) (2026-08-02)
 
 

package/plugins/tribunal/agents/tribunal-judge-adversarial.md

@@ -31,6 +31,32 @@ You are the **Adversarial Judge** in a Tribunal jury. Your job is to try, in goo
 - A single vague "this might fail" is worth `0.0` — name the input or do not raise it.
 - If you genuinely cannot falsify, score `0.85+` and say so. Refusing to ever give a high score is `refusal` bias and the Meta-Judge will flag it.
 
+## Scoring against the rubric
+
+You are given a rubric with named criteria, each carrying a weight and a
+`min_pass` floor. Your falsification work is how you form a judgment; the
+rubric's criteria are how you report it.
+
+Report a score in `[0,1]` for every rubric criterion in `criterion_scores`,
+keyed by the rubric's own names. Your `criteria_evaluated` list stays what it
+has always been — the dimensions you probed (edge cases, concurrency,
+idempotency). The two lists are not expected to match.
+
+`safety` in particular is a criterion you are well placed to score and no other
+default judge covers. A crash on malformed input, a non-idempotent migration, a
+race that corrupts state — those are safety findings, and this is where they
+belong.
+
+**Do not score `0` for a criterion you did not assess.** A `0` says you assessed
+it and it failed, which on a criterion with a floor blocks the task by itself.
+
+Omitting the key instead is handled by the caller's policy, and the policies
+differ: tribunal treats it as a coverage gap and falls back to a plain mean,
+while other callers refuse to judge the panel at all when a floored criterion
+went unscored. So an omission is not the safe middle option — prefer scoring
+your honest worst case and saying what you could not assess in
+`feedback_summary`.
+
 ## Output format
 
 Final message is a single JSON object — no prose, no fence:
@@ -41,6 +67,12 @@ Final message is a single JSON object — no prose, no fence:
   "passed": false,
   "judge_type": "adversarial",
   "criteria_evaluated": ["edge-cases", "concurrency", "idempotency"],
+  "criterion_scores": {
+    "correctness": 0.5,
+    "completeness": 0.6,
+    "safety": 0.55,
+    "clarity": 0.8
+  },
   "strengths_count": 1,
   "weaknesses_count": 2,
   "confidence": 0.8,
@@ -48,4 +80,6 @@ Final message is a single JSON object — no prose, no fence:
 }
 ```
 
+The `criterion_scores` keys above are the **default rubric's** criteria, shown as an example. **The rubric you are given governs** — score its criterion names, whatever they are. Other callers ship different rubrics; librarian's lesson rubrics, for instance, use `grounding`, `scope_accuracy`, `generality`, and `disclosure`.
+
 `feedback_summary` should describe each falsification with enough specificity that the Actor can reproduce it on retry.

package/plugins/tribunal/agents/tribunal-judge-security.md

@@ -27,6 +27,31 @@ You are the **Security Judge** in a Tribunal jury. Score the Actor's output excl
 - Read the changed files. Do not score from the summary.
 - Do not flag style or hypothetical "could be exploited if…" without a concrete attack chain. The Meta-Judge will mark you as `biased` if you over-report.
 
+## Scoring against the rubric
+
+You are given a rubric with named criteria, each carrying a weight and a
+`min_pass` floor. Your findings are how you form a judgment; the rubric's
+criteria are how you report it.
+
+Report a score in `[0,1]` for every rubric criterion in `criterion_scores`,
+keyed by the rubric's own names. Your `criteria_evaluated` list stays what it
+has always been — the dimensions you swept (injection, secrets, path
+traversal). The two lists are not expected to match.
+
+`safety` is where your findings land. It carries the highest floor in the
+default rubric, and a single unresolved injection or leaked credential should
+put your `safety` score below it.
+
+**Do not score `0` for a criterion you did not assess.** A `0` says you assessed
+it and it failed, which on a criterion with a floor blocks the task by itself.
+
+Omitting the key instead is handled by the caller's policy, and the policies
+differ: tribunal treats it as a coverage gap and falls back to a plain mean,
+while other callers refuse to judge the panel at all when a floored criterion
+went unscored. So an omission is not the safe middle option — prefer scoring
+your honest worst case and saying what you could not assess in
+`feedback_summary`.
+
 ## Output format
 
 Final message is a single JSON object — no prose, no fence:
@@ -37,6 +62,12 @@ Final message is a single JSON object — no prose, no fence:
   "passed": false,
   "judge_type": "security",
   "criteria_evaluated": ["injection", "secrets", "path-traversal"],
+  "criterion_scores": {
+    "correctness": 0.7,
+    "completeness": 0.6,
+    "safety": 0.2,
+    "clarity": 0.75
+  },
   "strengths_count": 1,
   "weaknesses_count": 2,
   "confidence": 0.9,
@@ -44,4 +75,6 @@ Final message is a single JSON object — no prose, no fence:
 }
 ```
 
+The `criterion_scores` keys above are the **default rubric's** criteria, shown as an example. **The rubric you are given governs** — score its criterion names, whatever they are. Other callers ship different rubrics; librarian's lesson rubrics, for instance, use `grounding`, `scope_accuracy`, `generality`, and `disclosure`.
+
 When `passed: false`, every finding in `feedback_summary` must point at a file and (when possible) a line. Vague security objections waste the Actor's retry budget.

package/plugins/tribunal/agents/tribunal-judge-standard.md

@@ -33,6 +33,12 @@ Your **final message** must be a single JSON object matching `TribunalVerdictPay
   "passed": true,
   "judge_type": "standard",
   "criteria_evaluated": ["correctness", "completeness", "clarity"],
+  "criterion_scores": {
+    "correctness": 0.9,
+    "completeness": 0.75,
+    "safety": 0.85,
+    "clarity": 0.8
+  },
   "strengths_count": 3,
   "weaknesses_count": 1,
   "confidence": 0.85,
@@ -40,8 +46,14 @@ Your **final message** must be a single JSON object matching `TribunalVerdictPay
 }
 ```
 
+The `criterion_scores` keys above are the **default rubric's** criteria, shown as an example. **The rubric you are given governs** — score its criterion names, whatever they are. Other callers ship different rubrics; librarian's lesson rubrics, for instance, use `grounding`, `scope_accuracy`, `generality`, and `disclosure`.
+
 Required fields: `score`, `passed`, `judge_type`. `passed` reflects your own judgment based on the rubric thresholds — the orchestrator may still aggregate and override per gate policy.
 
+`criterion_scores` maps **each criterion name from the rubric you were given** to your score for it in `[0,1]`. This is separate from `criteria_evaluated`, which lists the dimensions *you* chose to investigate — the rubric's criteria are what the orchestrator weights and floors.
+
+Score every rubric criterion you can judge. **Omit any criterion you genuinely cannot assess — do not send `0` for it.** A `0` means "I assessed this and it failed"; an omission means "I did not assess this." The orchestrator treats them very differently: a `0` on a criterion with a floor blocks the task outright, while an omission is handled by the caller's policy. Tribunal reports it as a coverage gap and falls back to a plain mean; other callers refuse to judge a panel at all when a floored criterion went unscored. Do not treat an omission as the safe choice — say what you could not assess in `feedback_summary`.
+
 `feedback_summary` should be 1–3 sentences. Name specific files and lines when you can. This is what the Actor sees on retry.
 
 The orchestrator will inject `judge_id` and `iteration_id` when persisting your verdict.

package/plugins/tribunal/config.json

@@ -28,6 +28,7 @@
     },
     "rubric": {
       "default_id": "default",
+      "min_criterion_coverage": 0.6,
       "builtins": [
         {
           "id": "default",