@codyswann/lisa 2.282.0 → 2.283.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/all/create-only/.lisa/DEPENDENCY_DECISIONS.md +175 -0
- package/dist/core/upstream-evidence-manifest.d.ts.map +1 -1
- package/dist/core/upstream-evidence-manifest.js +12 -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/dependency-decision-records.md +32 -0
- package/plugins/lisa/rules/reference/dependency-decision-records.md +140 -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/dependency-decision-records.md +32 -0
- package/plugins/lisa-copilot/rules/reference/dependency-decision-records.md +140 -0
- package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cursor/rules/dependency-decision-records-reference.mdc +145 -0
- package/plugins/lisa-cursor/rules/dependency-decision-records.mdc +37 -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/dependency-decision-records.md +32 -0
- package/plugins/src/base/rules/reference/dependency-decision-records.md +140 -0
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.283.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.283.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.283.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.283.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.283.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,32 @@
|
|
|
1
|
+
# Dependency Decisions (load-bearing)
|
|
2
|
+
|
|
3
|
+
Material dependencies are recorded as decisions, not lockfile trivia. The
|
|
4
|
+
governed record is `.lisa/DEPENDENCY_DECISIONS.md`, seeded once by `lisa apply`
|
|
5
|
+
from the `all/create-only` template surface and never overwritten afterward.
|
|
6
|
+
|
|
7
|
+
A *material* dependency is one that owns a user-visible capability or would cost
|
|
8
|
+
real time to replace. Each record entry must name, in this order: why we keep it
|
|
9
|
+
in plain language, what it is, its owned capability, trust basis, exposure,
|
|
10
|
+
replacement cost, detection evidence, owner/review cadence, and last-reviewed
|
|
11
|
+
date. Field labels lead with the operator's question and keep the technical term
|
|
12
|
+
in parentheses. "Why we keep it" comes first on purpose — an entry that opens
|
|
13
|
+
with a version range opens with the trivia the record exists to replace.
|
|
14
|
+
|
|
15
|
+
When you add, upgrade across a major version, or remove a material dependency,
|
|
16
|
+
update its entry in the same change. When you cannot name the detection evidence
|
|
17
|
+
that would fail if an update broke the owned capability, write "nothing would
|
|
18
|
+
catch it" rather than inventing a check — the gap is the finding.
|
|
19
|
+
|
|
20
|
+
Write every entry so a non-technical operator can tell why the dependency is
|
|
21
|
+
kept and what evidence would detect a bad update. Lead with the outcome it
|
|
22
|
+
protects, not the mechanism.
|
|
23
|
+
|
|
24
|
+
Entries are repeatable blocks appended under `## Records`, so a seeding script
|
|
25
|
+
can add one without rewriting the file. An honest gap is written as
|
|
26
|
+
`_Not yet decided_` — never left blank.
|
|
27
|
+
|
|
28
|
+
Escalate, rather than just recording, when detection evidence says "nothing
|
|
29
|
+
would catch it", when `Last reviewed` predates the dependency's last major
|
|
30
|
+
upgrade, or when the trust basis names no maintainer or owner.
|
|
31
|
+
|
|
32
|
+
Full prose: [reference/dependency-decision-records.md](../reference/dependency-decision-records.md).
|
|
@@ -0,0 +1,140 @@
|
|
|
1
|
+
# Dependency Decisions
|
|
2
|
+
|
|
3
|
+
Lisa already governs dependency *mechanics* — pinning, audit gates, override
|
|
4
|
+
resolution, duplicate detection. What those mechanics cannot tell anyone is
|
|
5
|
+
**why** a dependency is in the project at all, what capability it owns, how much
|
|
6
|
+
blast radius it has, or what would fail if a bad update shipped. Dependency
|
|
7
|
+
decision records close that gap: they turn dependency posture into decisions an
|
|
8
|
+
operator can read, instead of package-manager trivia only an engineer can
|
|
9
|
+
interpret.
|
|
10
|
+
|
|
11
|
+
## Where the record lives
|
|
12
|
+
|
|
13
|
+
The governed record is the markdown file `.lisa/DEPENDENCY_DECISIONS.md` in the
|
|
14
|
+
host project.
|
|
15
|
+
|
|
16
|
+
It is distributed through Lisa's `all/create-only` template surface, so:
|
|
17
|
+
|
|
18
|
+
- Every project that runs `lisa apply` receives the scaffold, regardless of
|
|
19
|
+
stack — the record is stack-independent because dependency posture is.
|
|
20
|
+
- The strategy is **create-only**: Lisa seeds the file once and never overwrites
|
|
21
|
+
it. Host projects own their content outright, and Lisa upstream never carries
|
|
22
|
+
a copy of any host project's private dependency inventory.
|
|
23
|
+
- It lives in the cold `.lisa/` directory rather than an auto-loaded rules tree,
|
|
24
|
+
so a long record is never injected raw into every session. Agents read the
|
|
25
|
+
entry they need, when they need it.
|
|
26
|
+
|
|
27
|
+
Markdown is deliberate. The record's primary audience is the product gate, where
|
|
28
|
+
a non-technical operator has to make a keep/replace/escalate judgment. A machine
|
|
29
|
+
format would serve tooling and fail that reader.
|
|
30
|
+
|
|
31
|
+
## What an entry must name
|
|
32
|
+
|
|
33
|
+
Each material-dependency entry names nine things, in this order. Every label
|
|
34
|
+
leads with the operator's question and keeps the technical term in parentheses,
|
|
35
|
+
because the record's primary reader is looking for an answer, not a term:
|
|
36
|
+
|
|
37
|
+
- **Why we keep it** — plain-language reason, written for a non-technical
|
|
38
|
+
reader, leading with the outcome it protects. This is deliberately the FIRST
|
|
39
|
+
bullet: an entry that opens with a version range opens with exactly the
|
|
40
|
+
package-manager trivia this record exists to replace.
|
|
41
|
+
- **What it is (dependency)** — package or service, plus the version range in
|
|
42
|
+
use.
|
|
43
|
+
- **What it does for us (owned capability)** — the single capability the
|
|
44
|
+
dependency is responsible for. A dependency with no nameable capability is
|
|
45
|
+
either not material, or is doing too much and should be split in the record.
|
|
46
|
+
- **Why we believe it's safe (trust basis)** — the evidence that it will still
|
|
47
|
+
be maintained and safe next quarter: maintainer, release cadence,
|
|
48
|
+
security-response history, breadth of adoption, whether the version is pinned.
|
|
49
|
+
- **What breaks if this is compromised (exposure)** — what it can reach and what
|
|
50
|
+
breaks when it misbehaves: build-time versus runtime, and whether it touches
|
|
51
|
+
user data, secrets, the network, or CI credentials.
|
|
52
|
+
- **What it would take to replace (replacement cost)** — the honest effort to
|
|
53
|
+
remove or swap it, what would need rewriting, and whether a viable alternative
|
|
54
|
+
exists today.
|
|
55
|
+
- **What would catch a bad update (detection evidence)** — the named check that
|
|
56
|
+
would **fail** if an update broke the owned capability: a test, suite,
|
|
57
|
+
workflow, or monitor. "Nothing would catch it" is a legitimate and high-value
|
|
58
|
+
answer.
|
|
59
|
+
- **Who owns this and how often we recheck (owner / review cadence)** — who is
|
|
60
|
+
accountable, and how often the entry gets re-read.
|
|
61
|
+
- **Last reviewed** — ISO `YYYY-MM-DD` date of the most recent actual review.
|
|
62
|
+
|
|
63
|
+
## When to escalate
|
|
64
|
+
|
|
65
|
+
The record exists to produce decisions, so three states are escalations rather
|
|
66
|
+
than to-dos. Raise them to an owner instead of leaving them recorded:
|
|
67
|
+
|
|
68
|
+
- Detection evidence says "nothing would catch it" — the capability is trusted
|
|
69
|
+
blind.
|
|
70
|
+
- `Last reviewed` predates the dependency's last major upgrade — the record
|
|
71
|
+
describes software no longer running.
|
|
72
|
+
- The trust basis names no maintainer, owner, or release history.
|
|
73
|
+
|
|
74
|
+
An entry full of `_Not yet decided_` is not an escalation; it is unstarted work.
|
|
75
|
+
These three are escalations precisely because someone already looked and the
|
|
76
|
+
answer was bad.
|
|
77
|
+
|
|
78
|
+
## What counts as material
|
|
79
|
+
|
|
80
|
+
Material means: if this dependency vanished, broke, or shipped a hostile update,
|
|
81
|
+
a user would notice, or replacing it would cost real time. Test frameworks,
|
|
82
|
+
linters, HTTP clients, ORMs, auth libraries, UI toolkits, and build tooling are
|
|
83
|
+
usually material. Transitive packages and single-function utilities usually are
|
|
84
|
+
not — record the direct dependency that owns the capability, not everything
|
|
85
|
+
underneath it.
|
|
86
|
+
|
|
87
|
+
Do not attempt to record the whole lockfile. An exhaustive record decays into
|
|
88
|
+
noise and stops being read, which is worse than a short record that is true.
|
|
89
|
+
|
|
90
|
+
## Maintenance
|
|
91
|
+
|
|
92
|
+
Update the relevant entry in the same change that adds a material dependency,
|
|
93
|
+
upgrades one across a major version, or removes one. Refresh `Last reviewed`
|
|
94
|
+
whenever someone actually re-reads an entry, even when nothing else changes — a
|
|
95
|
+
stale date is the signal that the record has drifted from reality.
|
|
96
|
+
|
|
97
|
+
When detection evidence fails for a dependency, treat the entry as the first
|
|
98
|
+
place to look and the first place to correct: either the evidence was wrong
|
|
99
|
+
about what it protects, or the exposure was understated.
|
|
100
|
+
|
|
101
|
+
## Entry format
|
|
102
|
+
|
|
103
|
+
Entries are uniform and appendable by design, because a later seeding pass adds
|
|
104
|
+
them mechanically rather than by rewriting the document:
|
|
105
|
+
|
|
106
|
+
- An entry is a level-3 heading (`### <name>`) followed by the nine field
|
|
107
|
+
bullets in the fixed order above.
|
|
108
|
+
- Entries live under `## Records`, the final section of the file, and new
|
|
109
|
+
entries are appended to its end. A `###` heading inside `## Records` is always
|
|
110
|
+
an entry, never guidance — that scoping is what makes the section safe to
|
|
111
|
+
parse and append to.
|
|
112
|
+
- `_Not yet decided_` is the reserved marker for a field nobody has answered
|
|
113
|
+
yet. Never leave a field blank and never guess: a blank field is
|
|
114
|
+
indistinguishable from an overlooked one, and a guess is a wrong answer that
|
|
115
|
+
nobody re-checks.
|
|
116
|
+
|
|
117
|
+
Note that `_Not yet decided_` and "nothing would catch it" are different
|
|
118
|
+
statements. The first means nobody has looked. The second is a finding — a real
|
|
119
|
+
capability with no detection evidence behind it.
|
|
120
|
+
|
|
121
|
+
## Scaffold, not inventory
|
|
122
|
+
|
|
123
|
+
The seeded file is a scaffold: field structure, guidance, and one clearly marked
|
|
124
|
+
worked example so an operator can see the intended shape. The example is meant
|
|
125
|
+
to be replaced or deleted once real entries exist. Lisa does not pre-populate a
|
|
126
|
+
host project's dependency inventory — only the project knows which of its
|
|
127
|
+
dependencies are material.
|
|
128
|
+
|
|
129
|
+
## Agent parity
|
|
130
|
+
|
|
131
|
+
The record is a governed markdown artifact, not a runtime behavior, so every
|
|
132
|
+
supported coding agent — Claude Code, Codex, Cursor, OpenCode, Antigravity, and
|
|
133
|
+
Copilot — reaches it identically through the shared rules mirror and the same
|
|
134
|
+
`.lisa/DEPENDENCY_DECISIONS.md` path in the host project. There is no per-agent
|
|
135
|
+
enforcement surface to diverge.
|
|
136
|
+
|
|
137
|
+
The documented gap, uniform across all six runtimes: no agent runtime enforces
|
|
138
|
+
that entries stay accurate or current. Nothing blocks a commit whose dependency
|
|
139
|
+
change skips the record, and nothing fails when `Last reviewed` goes stale.
|
|
140
|
+
Freshness is carried by this rule and by review, not by a hook or a lint gate.
|