lastlight 0.12.3 → 0.12.4
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/package.json
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
"$schema": "https://json.schemastore.org/claude-code-plugin.json",
|
|
3
3
|
"name": "lastlight",
|
|
4
4
|
"displayName": "Last Light",
|
|
5
|
-
"version": "0.12.
|
|
5
|
+
"version": "0.12.4",
|
|
6
6
|
"description": "Install, configure and operate Last Light (GitHub maintenance agent) — its server, CLI client, deployment overlay, and the Last Light Evals harness.",
|
|
7
7
|
"author": {
|
|
8
8
|
"name": "Clifton Cunningham"
|
|
@@ -27,14 +27,24 @@ guardrail — report it as such.
|
|
|
27
27
|
|
|
28
28
|
CHECK THESE GUARDRAILS:
|
|
29
29
|
|
|
30
|
-
|
|
31
|
-
|
|
30
|
+
The rule for each check below: **if it is present, it MUST pass; if it is not
|
|
31
|
+
present, that's fine.** A configured command that FAILS is a blocker. A command
|
|
32
|
+
that simply doesn't exist is NOT a blocker.
|
|
33
|
+
|
|
34
|
+
1. **Test Framework** — Does the repo have a test runner (vitest, jest, pytest,
|
|
35
|
+
cargo test, etc.)? Do test files exist? Does the test command run AND pass?
|
|
36
|
+
(Tests are the primary signal — a repo with no test framework at all is the
|
|
37
|
+
one absent-tooling case that still blocks, since there's nothing to verify
|
|
38
|
+
the build against.)
|
|
32
39
|
|
|
33
40
|
2. **Linting** — Is a linter configured (eslint, biome, ruff, clippy, etc.)?
|
|
34
|
-
|
|
41
|
+
If configured, the lint command MUST pass → a failing lint BLOCKS. If no
|
|
42
|
+
linter is configured at all, that's fine — note it and do NOT block.
|
|
35
43
|
|
|
36
|
-
3. **Type Checking** — Is type checking configured (tsconfig.json + tsc, mypy,
|
|
37
|
-
|
|
44
|
+
3. **Type Checking** — Is type checking configured (tsconfig.json + tsc, mypy,
|
|
45
|
+
cargo check, etc.)? If configured, the typecheck command MUST pass → a
|
|
46
|
+
failing typecheck BLOCKS. If not configured at all, that's fine — note it
|
|
47
|
+
and do NOT block.
|
|
38
48
|
|
|
39
49
|
4. **CI Pipeline** (informational only) — Does .github/workflows/ exist with test/lint steps?
|
|
40
50
|
|
|
@@ -61,7 +71,17 @@ no `guardrails:` prefix — judge it from the issue's intent.
|
|
|
61
71
|
|
|
62
72
|
Otherwise (the issue is normal feature/bug work, not about adding tooling):
|
|
63
73
|
|
|
64
|
-
|
|
74
|
+
Apply the present-must-pass rule. BLOCK if ANY of these hold:
|
|
75
|
+
- there is no test framework at all, or the test command is broken / fails;
|
|
76
|
+
- a linter IS configured but the lint command fails;
|
|
77
|
+
- type checking IS configured but the typecheck command fails;
|
|
78
|
+
- the dependency install itself failed.
|
|
79
|
+
|
|
80
|
+
A check that is simply ABSENT (no linter configured, no typecheck configured) is
|
|
81
|
+
NOT a blocker — note it in the report and proceed. Do not create a guardrails
|
|
82
|
+
issue merely because lint or typecheck tooling is missing.
|
|
83
|
+
|
|
84
|
+
IF A BLOCKING CONDITION ABOVE HOLDS:
|
|
65
85
|
- Use the MCP tool github_create_issue to create a guardrails issue in the repo with:
|
|
66
86
|
- title prefixed exactly with "guardrails:" (e.g. "guardrails: no test framework configured")
|
|
67
87
|
- labels including {{bootstrapLabel}} so subsequent build attempts on this issue
|
|
@@ -70,7 +90,7 @@ IF ANY BLOCKING GUARDRAIL IS MISSING (no test framework at all, or tests complet
|
|
|
70
90
|
- Use github_add_issue_comment on issue #{{issueNumber}} to link the guardrails issue
|
|
71
91
|
- OUTPUT must include: BLOCKED
|
|
72
92
|
|
|
73
|
-
|
|
93
|
+
OTHERWISE — every check that EXISTS passes (absent lint/typecheck is fine):
|
|
74
94
|
- OUTPUT must include: READY
|
|
75
95
|
|
|
76
96
|
OUTPUT: Exactly one of READY or BLOCKED, followed by a brief summary of what was found.
|