logic-guardian

Name: logic-guardian
Author: Rune-kit

80stars21forks

How to install logic-guardian?

rune-kit/rune/logic-guardian

$curl -o .claude/agents/logic-guardian.md https://raw.githubusercontent.com/Rune-kit/rune/HEAD/agents/logic-guardian.md

Installs into the current project.

Summary

Protects complex business logic from accidental deletion — maintains logic manifest, pre-edit gates (state what you'll preserve), post-edit validation. Use on trading bots, payment systems, state machines.

Files · 1

View on GitHub

agents/logic-guardian.md

1	# logic-guardian
2
3	## Purpose
4
5	Complex projects (trading bots, payment systems, game engines, state machines) contain interconnected logic that AI agents routinely destroy by accident. The pattern is always the same: new session starts, agent doesn't know existing logic, rewrites or deletes working code, project regresses. `logic-guardian` breaks this cycle by maintaining a machine-readable logic manifest, enforcing a pre-edit gate on logic files, and validating that edits don't silently remove existing logic. It is the "institutional memory" for business logic.
6
7	## Triggers
8
9	- `/rune logic-guardian` — manual invocation (scan project, generate/update manifest)
10	- Auto-trigger: when `cook` or `fix` targets a file listed in `.rune/logic-manifest.json`
11	- Auto-trigger: when `surgeon` plans refactoring on logic-heavy modules
12	- Auto-trigger: when `.rune/logic-manifest.json` exists in project root
13
14	## Calls (outbound connections)
15
16	- `scout` (L2): scan project to discover logic files and extract function signatures
17	- `verification` (L3): run tests after logic edits to confirm no regression
18	- `hallucination-guard` (L3): verify that referenced functions/imports actually exist after edit
19	- `journal` (L3): record logic changes as ADRs for cross-session persistence
20	- `session-bridge` (L3): save manifest state so next session loads it immediately
21
22	## Called By (inbound connections)
23
24	- `cook` (L1): Phase 1.5 — when complex logic project detected, load manifest before planning
25	- `fix` (L2): pre-edit gate — before modifying any file in the manifest
26	- `surgeon` (L2): pre-refactor — before restructuring logic modules
27	- `team` (L1): validate logic integrity across parallel workstreams
28	- `review` (L2): check if reviewed diff removes or modifies manifested logic
29
30	## Workflow
31
32	### Phase 0 — Load Manifest + Invariants
33
34	1. Use `Read` on `.rune/logic-manifest.json`
35	2. If file exists:
36	- Parse manifest, display summary: "Loaded logic manifest: N components, M functions, K parameters"
37	- Proceed to step 4 (load invariants)
38	3. If manifest does NOT exist:
39	- Announce: "No logic manifest found. Scanning project to generate one."
40	- Proceed to Phase 3 (Generate)
41	4. Obtain invariants (seeded by `onboard` — see onboard Step 5.4):
42	- Preferred: consume the `invariants.loaded` signal emitted by `session-bridge` at session start (contains pre-parsed `rules[]` + stats). No second file read needed.
43	- Fallback: if no signal was emitted this session, `Read` `.rune/INVARIANTS.md` directly and invoke `skills/session-bridge/scripts/load-invariants.js` to parse.
44	- Entries come from `## Danger Zones`, `## Critical Invariants`, `## State Machine Rules`, `## Cross-File Consistency`, and `## Auto-detected (new)`. Archived rules are automatically excluded by the loader.
45	- Each entry follows the `WHAT / WHERE / WHY` contract from `invariants-template.md`.
46	- Treat `INVARIANTS.md` as the primary source of cross-file rules — the JSON manifest covers component-level signatures; INVARIANTS.md covers rules that span files (shared constants, state transitions, mirrored schemas).
47	- If the file is absent, log WARN: "INVARIANTS.md not found — run `rune onboard` to seed baseline rules." Do not block.
48	- Cache parsed rules keyed by glob so Phase 2 can match the edit target in O(rules × globs) time.
49
50	### Phase 1 — Validate Manifest Against Codebase
51
52	Ensure the manifest matches the actual code (detect drift):
53
54	1. For each component in the manifest:
55	- Use `Read` on the component's `file_path`
56	- Verify each listed function exists (by name + signature match)
57	- Check if any NEW functions exist in the file that aren't in the manifest
58	2. Report:
59	- `SYNCED` — manifest matches code perfectly
60	- `DRIFT_DETECTED` — list specific discrepancies (missing functions, new unlisted functions, changed signatures)
61	3. If drift detected: ask user whether to update manifest or investigate changes
62
63	### Phase 2 — Pre-Edit Gate (called by fix/surgeon/cook)
64
65	Before ANY edit to a manifested file:
66
67	1. Load the manifest (Phase 0)
68	2. Display the affected component's current spec:
69	```
70	COMPONENT: [name]
71	STATUS: ACTIVE \| TESTING \| DEPRECATED
72	FUNCTIONS: [list with one-line descriptions]
73	PARAMETERS: [configurable values with current settings]
74	DEPENDENCIES: [what other components depend on this]
75	LAST_MODIFIED: [date]
76	```
77	3. Require the agent to explicitly state:
78	- What it intends to change
79	- What it will NOT change
80	- Which

People who liked this also viewed

6 picks

Type

logic-guardian

80stars21forks

View on GitHub

How to install logic-guardian?

rune-kit/rune/logic-guardian

$curl -o .claude/agents/logic-guardian.md https://raw.githubusercontent.com/Rune-kit/rune/HEAD/agents/logic-guardian.md

Installs into the current project.

Summary

Files · 1

View on GitHub

agents/logic-guardian.md

1	# logic-guardian
2
3	## Purpose
4
5	Complex projects (trading bots, payment systems, game engines, state machines) contain interconnected logic that AI agents routinely destroy by accident. The pattern is always the same: new session starts, agent doesn't know existing logic, rewrites or deletes working code, project regresses. `logic-guardian` breaks this cycle by maintaining a machine-readable logic manifest, enforcing a pre-edit gate on logic files, and validating that edits don't silently remove existing logic. It is the "institutional memory" for business logic.
6
7	## Triggers
8
9	- `/rune logic-guardian` — manual invocation (scan project, generate/update manifest)
10	- Auto-trigger: when `cook` or `fix` targets a file listed in `.rune/logic-manifest.json`
11	- Auto-trigger: when `surgeon` plans refactoring on logic-heavy modules
12	- Auto-trigger: when `.rune/logic-manifest.json` exists in project root
13
14	## Calls (outbound connections)
15
16	- `scout` (L2): scan project to discover logic files and extract function signatures
17	- `verification` (L3): run tests after logic edits to confirm no regression
18	- `hallucination-guard` (L3): verify that referenced functions/imports actually exist after edit
19	- `journal` (L3): record logic changes as ADRs for cross-session persistence
20	- `session-bridge` (L3): save manifest state so next session loads it immediately
21
22	## Called By (inbound connections)
23
24	- `cook` (L1): Phase 1.5 — when complex logic project detected, load manifest before planning
25	- `fix` (L2): pre-edit gate — before modifying any file in the manifest
26	- `surgeon` (L2): pre-refactor — before restructuring logic modules
27	- `team` (L1): validate logic integrity across parallel workstreams
28	- `review` (L2): check if reviewed diff removes or modifies manifested logic
29
30	## Workflow
31
32	### Phase 0 — Load Manifest + Invariants
33
34	1. Use `Read` on `.rune/logic-manifest.json`
35	2. If file exists:
36	- Parse manifest, display summary: "Loaded logic manifest: N components, M functions, K parameters"
37	- Proceed to step 4 (load invariants)
38	3. If manifest does NOT exist:
39	- Announce: "No logic manifest found. Scanning project to generate one."
40	- Proceed to Phase 3 (Generate)
41	4. Obtain invariants (seeded by `onboard` — see onboard Step 5.4):
42	- Preferred: consume the `invariants.loaded` signal emitted by `session-bridge` at session start (contains pre-parsed `rules[]` + stats). No second file read needed.
43	- Fallback: if no signal was emitted this session, `Read` `.rune/INVARIANTS.md` directly and invoke `skills/session-bridge/scripts/load-invariants.js` to parse.
44	- Entries come from `## Danger Zones`, `## Critical Invariants`, `## State Machine Rules`, `## Cross-File Consistency`, and `## Auto-detected (new)`. Archived rules are automatically excluded by the loader.
45	- Each entry follows the `WHAT / WHERE / WHY` contract from `invariants-template.md`.
46	- Treat `INVARIANTS.md` as the primary source of cross-file rules — the JSON manifest covers component-level signatures; INVARIANTS.md covers rules that span files (shared constants, state transitions, mirrored schemas).
47	- If the file is absent, log WARN: "INVARIANTS.md not found — run `rune onboard` to seed baseline rules." Do not block.
48	- Cache parsed rules keyed by glob so Phase 2 can match the edit target in O(rules × globs) time.
49
50	### Phase 1 — Validate Manifest Against Codebase
51
52	Ensure the manifest matches the actual code (detect drift):
53
54	1. For each component in the manifest:
55	- Use `Read` on the component's `file_path`
56	- Verify each listed function exists (by name + signature match)
57	- Check if any NEW functions exist in the file that aren't in the manifest
58	2. Report:
59	- `SYNCED` — manifest matches code perfectly
60	- `DRIFT_DETECTED` — list specific discrepancies (missing functions, new unlisted functions, changed signatures)
61	3. If drift detected: ask user whether to update manifest or investigate changes
62
63	### Phase 2 — Pre-Edit Gate (called by fix/surgeon/cook)
64
65	Before ANY edit to a manifested file:
66
67	1. Load the manifest (Phase 0)
68	2. Display the affected component's current spec:
69	```
70	COMPONENT: [name]
71	STATUS: ACTIVE \| TESTING \| DEPRECATED
72	FUNCTIONS: [list with one-line descriptions]
73	PARAMETERS: [configurable values with current settings]
74	DEPENDENCIES: [what other components depend on this]
75	LAST_MODIFIED: [date]
76	```
77	3. Require the agent to explicitly state:
78	- What it intends to change
79	- What it will NOT change
80	- Which

People who liked this also viewed

6 picks

Type