@codyswann/lisa 2.260.1 → 2.261.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/core/upstream-evidence-manifest.d.ts.map +1 -1
- package/dist/core/upstream-evidence-manifest.js +11 -0
- package/dist/core/upstream-evidence-manifest.js.map +1 -1
- package/package.json +1 -1
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa/rules/eager/claim-evidence-mapping.md +51 -0
- package/plugins/lisa/rules/reference/claim-evidence-mapping.md +132 -0
- package/plugins/lisa-agy/plugin.json +1 -1
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-agy/plugin.json +1 -1
- package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/rules/eager/claim-evidence-mapping.md +51 -0
- package/plugins/lisa-copilot/rules/reference/claim-evidence-mapping.md +132 -0
- package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cursor/rules/claim-evidence-mapping-reference.mdc +137 -0
- package/plugins/lisa-cursor/rules/claim-evidence-mapping.mdc +56 -0
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-agy/plugin.json +1 -1
- package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-agy/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-agy/plugin.json +1 -1
- package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-agy/plugin.json +1 -1
- package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-agy/plugin.json +1 -1
- package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-agy/plugin.json +1 -1
- package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-agy/plugin.json +1 -1
- package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-agy/plugin.json +1 -1
- package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/src/base/rules/eager/claim-evidence-mapping.md +51 -0
- package/plugins/src/base/rules/reference/claim-evidence-mapping.md +132 -0
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Claim → Evidence Mapping Contract (load-bearing)"
|
|
3
|
+
alwaysApply: true
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Claim → Evidence Mapping Contract (load-bearing)
|
|
7
|
+
|
|
8
|
+
**Every claim about the software declares a boundary, and a claim is established only by evidence of
|
|
9
|
+
a kind that reaches that boundary.** Unit tests are a quality prerequisite, not a claim discharger:
|
|
10
|
+
a passing unit `test-run-log` reaches only the **code-unit** boundary. Citing evidence whose *kind*
|
|
11
|
+
does not reach a claim's *boundary* — a unit log offered as proof that a button works in the browser
|
|
12
|
+
— is a contract violation, and a review-rejectable defect.
|
|
13
|
+
|
|
14
|
+
## The claim-boundary taxonomy (closed set)
|
|
15
|
+
|
|
16
|
+
Every claim binds to exactly one boundary, and each boundary is discharged only by evidence of the
|
|
17
|
+
kind(s) that reach it. The boundaries and their establishing evidence kinds are seeded verbatim from
|
|
18
|
+
the `verification` rule's artifact-type taxonomy — no new vocabulary is invented here:
|
|
19
|
+
|
|
20
|
+
- **`code-unit`** — pure-logic behavior in isolation → unit `test-run-log`. Reaches no boundary
|
|
21
|
+
below it.
|
|
22
|
+
- **`browser`** — user-visible UI behavior → `screenshot`, `recording`. **Never** a unit
|
|
23
|
+
`test-run-log`.
|
|
24
|
+
- **`http-api`** — request/response contract → `http-transcript`. **Never** a unit `test-run-log`.
|
|
25
|
+
- **`cli`** — command behavior → `cli-output`.
|
|
26
|
+
- **`data`** — persisted state → `db-query-output`, `state-dump`.
|
|
27
|
+
- **`deploy-health`** — a healthy running deployment → `deploy-log`. **Never** any pre-deploy
|
|
28
|
+
artifact.
|
|
29
|
+
- **`performance`** — latency/throughput/frame timing → `perf-trace` (with methodology).
|
|
30
|
+
- **`standards-compat`** — conformance to an external standard → `cli-output` / `test-run-log` from
|
|
31
|
+
the compat runner.
|
|
32
|
+
|
|
33
|
+
## The core inequality
|
|
34
|
+
|
|
35
|
+
**unit tests ≠ browser behavior ≠ healthy deployment ≠ standards compatibility.** Each is a distinct
|
|
36
|
+
boundary; evidence at one never discharges a claim at another. "Verified" must name the boundary its
|
|
37
|
+
evidence actually reaches, so a report read at the gate states its own limits (`factory-model`
|
|
38
|
+
rule 5).
|
|
39
|
+
|
|
40
|
+
## Field names (fixed here, made executable later)
|
|
41
|
+
|
|
42
|
+
A claim carries three fields — `claim_id`, `boundary`, and `required_evidence_kinds` — named here so
|
|
43
|
+
every downstream surface uses one spelling. This ticket only writes the contract down; the schema and
|
|
44
|
+
gate that make these fields executable ship with **BCE-2 (#1836)** — do not assume that surface is
|
|
45
|
+
present in this branch. A claim with no reaching evidence is **Not established** (defined fully in
|
|
46
|
+
**BCE-3 (#1837)**), an artifact's identity is pinned in **BCE-4 (#1838)**, and the conservative
|
|
47
|
+
security-bucket default is set in **BCE-5 (#1839)** — each named here, defined there.
|
|
48
|
+
|
|
49
|
+
## No behavior change; degrade, never block
|
|
50
|
+
|
|
51
|
+
This rule is documentation, not a gate: it changes no schema, no skill, and no check. Where a later
|
|
52
|
+
surface it names is not yet installed, cite the boundary a claim reaches and continue — never block
|
|
53
|
+
on the absent surface. Read the contract to someone who has never seen Lisa and they should be able
|
|
54
|
+
to say why a unit-test log does not prove a button works in the browser.
|
|
55
|
+
|
|
56
|
+
Full contract (claim-boundary taxonomy, core inequality, worked example, field names): [reference/claim-evidence-mapping.md](claim-evidence-mapping-reference.mdc).
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.261.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.261.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.261.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.261.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.261.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# Claim → Evidence Mapping Contract (load-bearing)
|
|
2
|
+
|
|
3
|
+
**Every claim about the software declares a boundary, and a claim is established only by evidence of
|
|
4
|
+
a kind that reaches that boundary.** Unit tests are a quality prerequisite, not a claim discharger:
|
|
5
|
+
a passing unit `test-run-log` reaches only the **code-unit** boundary. Citing evidence whose *kind*
|
|
6
|
+
does not reach a claim's *boundary* — a unit log offered as proof that a button works in the browser
|
|
7
|
+
— is a contract violation, and a review-rejectable defect.
|
|
8
|
+
|
|
9
|
+
## The claim-boundary taxonomy (closed set)
|
|
10
|
+
|
|
11
|
+
Every claim binds to exactly one boundary, and each boundary is discharged only by evidence of the
|
|
12
|
+
kind(s) that reach it. The boundaries and their establishing evidence kinds are seeded verbatim from
|
|
13
|
+
the `verification` rule's artifact-type taxonomy — no new vocabulary is invented here:
|
|
14
|
+
|
|
15
|
+
- **`code-unit`** — pure-logic behavior in isolation → unit `test-run-log`. Reaches no boundary
|
|
16
|
+
below it.
|
|
17
|
+
- **`browser`** — user-visible UI behavior → `screenshot`, `recording`. **Never** a unit
|
|
18
|
+
`test-run-log`.
|
|
19
|
+
- **`http-api`** — request/response contract → `http-transcript`. **Never** a unit `test-run-log`.
|
|
20
|
+
- **`cli`** — command behavior → `cli-output`.
|
|
21
|
+
- **`data`** — persisted state → `db-query-output`, `state-dump`.
|
|
22
|
+
- **`deploy-health`** — a healthy running deployment → `deploy-log`. **Never** any pre-deploy
|
|
23
|
+
artifact.
|
|
24
|
+
- **`performance`** — latency/throughput/frame timing → `perf-trace` (with methodology).
|
|
25
|
+
- **`standards-compat`** — conformance to an external standard → `cli-output` / `test-run-log` from
|
|
26
|
+
the compat runner.
|
|
27
|
+
|
|
28
|
+
## The core inequality
|
|
29
|
+
|
|
30
|
+
**unit tests ≠ browser behavior ≠ healthy deployment ≠ standards compatibility.** Each is a distinct
|
|
31
|
+
boundary; evidence at one never discharges a claim at another. "Verified" must name the boundary its
|
|
32
|
+
evidence actually reaches, so a report read at the gate states its own limits (`factory-model`
|
|
33
|
+
rule 5).
|
|
34
|
+
|
|
35
|
+
## Field names (fixed here, made executable later)
|
|
36
|
+
|
|
37
|
+
A claim carries three fields — `claim_id`, `boundary`, and `required_evidence_kinds` — named here so
|
|
38
|
+
every downstream surface uses one spelling. This ticket only writes the contract down; the schema and
|
|
39
|
+
gate that make these fields executable ship with **BCE-2 (#1836)** — do not assume that surface is
|
|
40
|
+
present in this branch. A claim with no reaching evidence is **Not established** (defined fully in
|
|
41
|
+
**BCE-3 (#1837)**), an artifact's identity is pinned in **BCE-4 (#1838)**, and the conservative
|
|
42
|
+
security-bucket default is set in **BCE-5 (#1839)** — each named here, defined there.
|
|
43
|
+
|
|
44
|
+
## No behavior change; degrade, never block
|
|
45
|
+
|
|
46
|
+
This rule is documentation, not a gate: it changes no schema, no skill, and no check. Where a later
|
|
47
|
+
surface it names is not yet installed, cite the boundary a claim reaches and continue — never block
|
|
48
|
+
on the absent surface. Read the contract to someone who has never seen Lisa and they should be able
|
|
49
|
+
to say why a unit-test log does not prove a button works in the browser.
|
|
50
|
+
|
|
51
|
+
Full contract (claim-boundary taxonomy, core inequality, worked example, field names): [reference/claim-evidence-mapping.md](../reference/claim-evidence-mapping.md).
|
|
@@ -0,0 +1,132 @@
|
|
|
1
|
+
# Claim → Evidence Mapping Contract
|
|
2
|
+
|
|
3
|
+
Lisa's verification machinery already proves outcomes empirically, but nothing states *which kind of
|
|
4
|
+
evidence establishes which kind of claim*. So a claim about browser-visible behavior, supported only
|
|
5
|
+
by a unit-test log, currently reads as "verified" — the report never names the boundary its evidence
|
|
6
|
+
actually reaches. This contract writes the mapping down once, as the single spine every evidence
|
|
7
|
+
surface cites: **every claim declares a boundary, and a claim is established only by evidence of a
|
|
8
|
+
kind that reaches that boundary.**
|
|
9
|
+
|
|
10
|
+
It is a **single vendor-neutral contract**. The later tickets of this PRD instantiate it rather than
|
|
11
|
+
redefine it: the `verification-status.json` schema and gate that make the claim fields executable
|
|
12
|
+
(**BCE-2, #1836**), the *Not-established* section and evidence templates (**BCE-3, #1837**), artifact
|
|
13
|
+
identity (**BCE-4, #1838**), and security buckets (**BCE-5, #1839**) each cite this slug. This ticket
|
|
14
|
+
adds no schema, no gate, and no skill edit — exactly as the `automation-runbook-contract` rule
|
|
15
|
+
preceded the skills that made it executable.
|
|
16
|
+
|
|
17
|
+
## Consumers
|
|
18
|
+
|
|
19
|
+
Every surface that asserts a claim is proved cites this contract for what "proved" means at that
|
|
20
|
+
claim's boundary: the verification flow and its `verification-specialist`, the evidence-posting and
|
|
21
|
+
completion gates, the QA and Verify factories' reports, and any report a human reads at a gate. None
|
|
22
|
+
of them redefines the mapping; each binds its claim to a boundary and cites evidence of a reaching
|
|
23
|
+
kind.
|
|
24
|
+
|
|
25
|
+
## The claim-boundary taxonomy
|
|
26
|
+
|
|
27
|
+
Every claim binds to exactly one **boundary**. The table binds each boundary to the evidence kind(s)
|
|
28
|
+
that establish it and at least one kind that cannot. The **establishing evidence kind(s)** column is
|
|
29
|
+
drawn verbatim from the `verification` rule's artifact-type taxonomy (its fixed set:
|
|
30
|
+
`screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`,
|
|
31
|
+
`perf-trace`, `test-run-log`, `deploy-log`, `state-dump`) — this contract invents no new evidence
|
|
32
|
+
types; it only says which reach which boundary.
|
|
33
|
+
|
|
34
|
+
| Claim boundary | What it asserts | Establishing evidence kind(s) | Cannot be established by |
|
|
35
|
+
|---|---|---|---|
|
|
36
|
+
| `code-unit` | pure-logic behavior in isolation | `test-run-log` (unit) | — (but never satisfies any boundary below) |
|
|
37
|
+
| `browser` | user-visible UI behavior | `screenshot`, `recording` | unit `test-run-log` |
|
|
38
|
+
| `http-api` | request/response contract | `http-transcript` | unit `test-run-log` |
|
|
39
|
+
| `cli` | command behavior | `cli-output` | prose |
|
|
40
|
+
| `data` | persisted state | `db-query-output`, `state-dump` | unit `test-run-log` |
|
|
41
|
+
| `deploy-health` | a healthy running deployment | `deploy-log` | any pre-deploy artifact |
|
|
42
|
+
| `performance` | latency/throughput/frame timing | `perf-trace` (with methodology) | screenshot |
|
|
43
|
+
| `standards-compat` | conformance to an external standard | `cli-output` / `test-run-log` from the compat runner | assertion prose |
|
|
44
|
+
|
|
45
|
+
Reciprocal cross-link: the `verification` rule's artifact-type taxonomy is the source of the
|
|
46
|
+
establishing-evidence column above; that rule's reference body should point back here for the
|
|
47
|
+
boundary each type reaches. Cite these slugs, do not restate them: `verification` (the artifact-type
|
|
48
|
+
taxonomy), `factory-model` (operator-readable writing — rule 5), and `empirical-inquiry` (observe the
|
|
49
|
+
real result before claiming).
|
|
50
|
+
|
|
51
|
+
## The core inequality
|
|
52
|
+
|
|
53
|
+
The whole contract reduces to one inequality, stated explicitly so no surface can blur it:
|
|
54
|
+
|
|
55
|
+
**unit tests ≠ browser behavior ≠ healthy deployment ≠ standards compatibility.**
|
|
56
|
+
|
|
57
|
+
A passing unit `test-run-log` establishes only `code-unit` behavior. It can **never** establish a
|
|
58
|
+
`browser`, `http-api`, `deploy-health`, or `standards-compat` claim — those live at boundaries a
|
|
59
|
+
unit test does not reach. Unit tests are a *quality prerequisite* (they gate the commit); they are
|
|
60
|
+
not a *claim discharger* for any boundary above `code-unit`. Symmetrically, a green `deploy-log`
|
|
61
|
+
proves a healthy deployment but says nothing about whether the UI renders correctly, and a
|
|
62
|
+
`screenshot` proves the pixels but not the latency. Each boundary stands on its own evidence.
|
|
63
|
+
|
|
64
|
+
## The review-rejection rule
|
|
65
|
+
|
|
66
|
+
Citing evidence whose *kind* does not reach a claim's *boundary* is a **review-rejectable defect** —
|
|
67
|
+
a machine-checkable one once BCE-2's gate ships, and a review-rejectable one in prose review today.
|
|
68
|
+
"It passed unit tests" is not an answer to "does the button work in the browser." A reviewer rejects
|
|
69
|
+
the claim, names the boundary, and asks for evidence of a reaching kind.
|
|
70
|
+
|
|
71
|
+
## The claim fields
|
|
72
|
+
|
|
73
|
+
A claim is three fields, named here so BCE-2's schema reuses one spelling — this contract only
|
|
74
|
+
defines the names; it stores nothing:
|
|
75
|
+
|
|
76
|
+
| Field | Meaning |
|
|
77
|
+
|---|---|
|
|
78
|
+
| `claim_id` | stable identifier for the claim being made |
|
|
79
|
+
| `boundary` | exactly one value from the claim-boundary taxonomy above |
|
|
80
|
+
| `required_evidence_kinds` | the evidence kind(s) that reach that boundary, from the `verification` artifact-type set |
|
|
81
|
+
|
|
82
|
+
A claim whose `required_evidence_kinds` has no captured, reaching artifact is **Not established** —
|
|
83
|
+
the concept is named here and defined fully, with its evidence templates, in **BCE-3 (#1837)**; do
|
|
84
|
+
not assume that section is present in this branch. Artifact identity — what makes two captured
|
|
85
|
+
artifacts the same or different — is pinned in **BCE-4 (#1838)**, and the conservative default
|
|
86
|
+
bucket for a security-sensitive claim is set in **BCE-5 (#1839)**. Each is named here as the field
|
|
87
|
+
BCE-2's schema will carry; none is defined by this contract. Each ships with that ticket — do not
|
|
88
|
+
assume its section is present in this branch.
|
|
89
|
+
|
|
90
|
+
### Worked example
|
|
91
|
+
|
|
92
|
+
```text
|
|
93
|
+
Claim: "The checkout button submits the order and shows a confirmation."
|
|
94
|
+
|
|
95
|
+
boundary browser
|
|
96
|
+
required_evidence_kinds screenshot | recording
|
|
97
|
+
|
|
98
|
+
Reaching evidence A screenshot of the confirmation state after a real click, or a
|
|
99
|
+
recording of the click-through. EITHER establishes the browser claim.
|
|
100
|
+
|
|
101
|
+
Non-reaching A passing unit test-run-log for the submit handler. It establishes the
|
|
102
|
+
code-unit boundary only — the handler's logic in isolation — and can
|
|
103
|
+
NEVER establish this browser claim. Offered as proof here, it is a
|
|
104
|
+
review-rejectable defect; the claim stays Not established until a
|
|
105
|
+
screenshot or recording is captured.
|
|
106
|
+
|
|
107
|
+
Claim: "The service is deployed and healthy."
|
|
108
|
+
|
|
109
|
+
boundary deploy-health
|
|
110
|
+
required_evidence_kinds deploy-log
|
|
111
|
+
|
|
112
|
+
Non-reaching Any pre-deploy artifact — a green CI test-run-log, a local screenshot.
|
|
113
|
+
A healthy deployment is established only by a deploy-log / health-check
|
|
114
|
+
response from the target environment.
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
## Philosophical precedent
|
|
118
|
+
|
|
119
|
+
This generalizes the **bounded-claim discipline** of `lisa-improve-harness`: one trajectory supports
|
|
120
|
+
one trajectory's claim, and a result record may claim only what its cited evidence reaches. Here the
|
|
121
|
+
same discipline is applied to every claim in the factory — a claim reaches exactly as far as the
|
|
122
|
+
*kind* of evidence behind it, and no further. BCE-3 generalizes the *Not established* half of that
|
|
123
|
+
discipline into a first-class report state.
|
|
124
|
+
|
|
125
|
+
## No behavior change; degrade, never block
|
|
126
|
+
|
|
127
|
+
This rule ships as documentation that later tickets make executable. It changes no schema, no gate,
|
|
128
|
+
and no skill. Where a surface it names (BCE-2's gate, BCE-3's templates) is not yet installed in a
|
|
129
|
+
given branch, name the boundary a claim reaches and continue — the contract never blocks on an absent
|
|
130
|
+
sibling surface. Every claim written under it must be operator-readable (`factory-model` rule 5): a
|
|
131
|
+
person who does not code should be able to read the boundary and see why the evidence does or does
|
|
132
|
+
not reach it.
|