bingocode 1.1.171 → 1.1.173
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.
|
@@ -1,17 +1,36 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: leanchy
|
|
3
|
-
description:
|
|
3
|
+
description: |
|
|
4
|
+
Engineering-focused AI behavior protocol for programming, architecture, and debugging tasks.
|
|
5
|
+
Enforces understanding-first execution, diagnostic rigor, decision hygiene, and architecture discipline.
|
|
4
6
|
---
|
|
5
7
|
|
|
6
8
|
# Leanchy Protocol
|
|
7
9
|
|
|
10
|
+
## Understanding First (Core Principle)
|
|
11
|
+
- **Clarify ambiguous requirements first**: When instructions are semantically ambiguous, explicitly
|
|
12
|
+
articulate your understanding before proceeding. This directly impacts completion quality.
|
|
13
|
+
- **Adopt AI-first mindset**:
|
|
14
|
+
- Proactively surface hidden constraints, edge cases, and downstream impacts
|
|
15
|
+
- Propose alternatives when the stated approach has known tradeoffs
|
|
16
|
+
- Flag assumptions explicitly rather than silently embedding them
|
|
17
|
+
- **Think before acting**: Adopt a systematic approach to problem understanding before implementation
|
|
18
|
+
- **Seek clarity over assumptions**: When uncertain, apply the following decision rule:
|
|
19
|
+
- If the answer is **observable in code, logs, or context** → explore first, do not ask
|
|
20
|
+
- If the answer requires **intent, business logic, or external context** → ask before proceeding
|
|
21
|
+
- **Embrace the full context**: Consider the broader system impact and underlying motivations behind tasks
|
|
22
|
+
|
|
8
23
|
## Execution
|
|
9
24
|
- Confirm the Definition of Done before starting. Lead with conclusions; append reasoning only if asked.
|
|
10
25
|
- No filler, no transition sentences, no restatement of what was just said.
|
|
11
26
|
|
|
12
27
|
## Diagnosis
|
|
13
28
|
- No evidence → no change. The error site is not the fault site; trace to the control-flow root.
|
|
14
|
-
- Three failed fixes at the same logic point: stop, switch to forensic mode
|
|
29
|
+
- Three failed fixes at the same logic point: stop, switch to forensic mode:
|
|
30
|
+
1. Add instrumentation at every assumption boundary (logging, assertions, type checks)
|
|
31
|
+
2. Collect and document observed vs. expected values at each boundary
|
|
32
|
+
3. Construct a minimal reproducible case that isolates the fault
|
|
33
|
+
4. Only resume fixing after the root cause is confirmed by evidence
|
|
15
34
|
|
|
16
35
|
## Decisions
|
|
17
36
|
- When in doubt, explore the codebase or logs first. Don't ask what the code can answer.
|
|
@@ -19,4 +38,12 @@ description: Activate the Leanchy protocol: execution discipline, diagnostic rig
|
|
|
19
38
|
|
|
20
39
|
## Architecture
|
|
21
40
|
- Two duplications → abstract. Search the full codebase before modifying; reuse over reinvention.
|
|
22
|
-
- Module boundaries require explicit contracts. Semantic naming is the documentation.
|
|
41
|
+
- Module boundaries require explicit contracts. Semantic naming is the documentation.
|
|
42
|
+
- **Context-aware design**: Understand existing patterns and constraints before introducing new abstractions
|
|
43
|
+
- **Do not abstract when**:
|
|
44
|
+
- The duplication spans fewer than two confirmed call sites
|
|
45
|
+
- The abstraction would couple previously independent modules
|
|
46
|
+
- The existing pattern is scheduled for deprecation or replacement
|
|
47
|
+
- **Legacy boundary discipline**: When modifying legacy code, identify and document the boundary
|
|
48
|
+
of intended change before editing. Do not expand scope without explicit confirmation.
|
|
49
|
+
```
|
package/package.json
CHANGED
|
@@ -9,6 +9,7 @@ import path from 'path';
|
|
|
9
9
|
import fs from 'fs';
|
|
10
10
|
import os from 'os';
|
|
11
11
|
import http from 'http';
|
|
12
|
+
import { execSync } from 'child_process';
|
|
12
13
|
import { fileURLToPath } from 'url';
|
|
13
14
|
|
|
14
15
|
const __filename = fileURLToPath(import.meta.url);
|
|
@@ -20,6 +21,65 @@ const HOST = process.env.BINGO_SERVER_HOST || '127.0.0.1';
|
|
|
20
21
|
|
|
21
22
|
let serverHandle: any = null;
|
|
22
23
|
|
|
24
|
+
// ── Autostart helpers (Windows Startup folder, fallback to registry) ────────
|
|
25
|
+
const STARTUP_DIR = path.join(os.homedir(), 'AppData', 'Roaming', 'Microsoft', 'Windows', 'Start Menu', 'Programs', 'Startup');
|
|
26
|
+
const STARTUP_CMD = path.join(STARTUP_DIR, 'Bingo.cmd');
|
|
27
|
+
const REG_KEY = 'HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run';
|
|
28
|
+
const REG_NAME = 'Bingo';
|
|
29
|
+
|
|
30
|
+
function isAutostartEnabled(): boolean {
|
|
31
|
+
if (process.platform !== 'win32') return false;
|
|
32
|
+
if (fs.existsSync(STARTUP_CMD)) return true;
|
|
33
|
+
try {
|
|
34
|
+
execSync(`reg query "${REG_KEY}" /v ${REG_NAME}`, { stdio: 'ignore' });
|
|
35
|
+
return true;
|
|
36
|
+
} catch { return false; }
|
|
37
|
+
}
|
|
38
|
+
|
|
39
|
+
function findBunExe(): string {
|
|
40
|
+
const appData = process.env.APPDATA || '';
|
|
41
|
+
const home = os.homedir();
|
|
42
|
+
const candidates = [
|
|
43
|
+
path.join(appData, 'npm', 'node_modules', 'bun', 'bin', 'bun.exe'),
|
|
44
|
+
path.join(home, '.bun', 'bin', 'bun.exe'),
|
|
45
|
+
];
|
|
46
|
+
// also search PATH
|
|
47
|
+
for (const dir of (process.env.PATH || '').split(';')) {
|
|
48
|
+
candidates.push(path.join(dir.trim(), 'bun.exe'));
|
|
49
|
+
}
|
|
50
|
+
return candidates.find(p => { try { return fs.existsSync(p); } catch { return false; } }) || 'bun';
|
|
51
|
+
}
|
|
52
|
+
|
|
53
|
+
function enableAutostart(): void {
|
|
54
|
+
if (process.platform !== 'win32') return;
|
|
55
|
+
const bunExe = findBunExe();
|
|
56
|
+
const preload = path.join(ROOT_DIR, 'preload.ts');
|
|
57
|
+
const trayEntry = path.join(ROOT_DIR, 'src', 'entrypoints', 'tray-only.ts');
|
|
58
|
+
// Startup .cmd: launch tray daemon only (no CLI window)
|
|
59
|
+
try {
|
|
60
|
+
const cmd = [
|
|
61
|
+
'@echo off',
|
|
62
|
+
`start "" /B "${bunExe}" "--preload=${preload}" "${trayEntry}"`,
|
|
63
|
+
'',
|
|
64
|
+
].join('\r\n');
|
|
65
|
+
fs.writeFileSync(STARTUP_CMD, cmd, { encoding: 'utf8' });
|
|
66
|
+
return;
|
|
67
|
+
} catch {}
|
|
68
|
+
// fallback: registry
|
|
69
|
+
try {
|
|
70
|
+
const val = `"${bunExe}" "--preload=${preload}" "${trayEntry}"`;
|
|
71
|
+
execSync(`reg add "${REG_KEY}" /v ${REG_NAME} /t REG_SZ /d "${val}" /f`);
|
|
72
|
+
} catch (e) {
|
|
73
|
+
console.error('[tray] Failed to enable autostart:', e);
|
|
74
|
+
}
|
|
75
|
+
}
|
|
76
|
+
|
|
77
|
+
function disableAutostart(): void {
|
|
78
|
+
if (process.platform !== 'win32') return;
|
|
79
|
+
try { fs.unlinkSync(STARTUP_CMD); } catch {}
|
|
80
|
+
try { execSync(`reg delete "${REG_KEY}" /v ${REG_NAME} /f`, { stdio: 'ignore' }); } catch {}
|
|
81
|
+
}
|
|
82
|
+
|
|
23
83
|
// ── Daemon PID lock ──────────────────────────────────────────────────────
|
|
24
84
|
const DAEMON_LOCK_FILE = path.join(os.homedir(), '.claude-cli', 'runtime', 'daemon.lock');
|
|
25
85
|
try { fs.mkdirSync(path.dirname(DAEMON_LOCK_FILE), { recursive: true }); } catch {}
|
|
@@ -37,6 +97,13 @@ const iconB64 = fs.existsSync(_iconFile)
|
|
|
37
97
|
: _iconFallback;
|
|
38
98
|
|
|
39
99
|
try {
|
|
100
|
+
const autostartItem = {
|
|
101
|
+
title: (isAutostartEnabled() ? '✓ ' : '') + 'Run on ststem startup',
|
|
102
|
+
tooltip: 'Toggle auto-start Bingo on Windows login',
|
|
103
|
+
checked: false,
|
|
104
|
+
enabled: true,
|
|
105
|
+
};
|
|
106
|
+
|
|
40
107
|
const systray = new SysTray({
|
|
41
108
|
menu: {
|
|
42
109
|
icon: iconB64,
|
|
@@ -49,6 +116,7 @@ try {
|
|
|
49
116
|
checked: false,
|
|
50
117
|
enabled: false,
|
|
51
118
|
},
|
|
119
|
+
autostartItem,
|
|
52
120
|
{
|
|
53
121
|
title: 'Exit Bingo',
|
|
54
122
|
tooltip: 'Stop all bingo services',
|
|
@@ -62,18 +130,32 @@ try {
|
|
|
62
130
|
});
|
|
63
131
|
|
|
64
132
|
systray.onClick((action: any) => {
|
|
65
|
-
|
|
66
|
-
|
|
133
|
+
if (action.item?.title?.includes('Start on Login')) {
|
|
134
|
+
if (isAutostartEnabled()) {
|
|
135
|
+
disableAutostart();
|
|
136
|
+
autostartItem.title = 'Start on Login';
|
|
137
|
+
} else {
|
|
138
|
+
enableAutostart();
|
|
139
|
+
autostartItem.title = '✓ Start on Login';
|
|
140
|
+
}
|
|
141
|
+
systray.sendAction({ type: 'update-item', item: autostartItem });
|
|
142
|
+
return;
|
|
143
|
+
}
|
|
144
|
+
if (action.item?.title === 'Exit Bingo') {
|
|
67
145
|
console.log('[tray] Exiting via tray menu');
|
|
146
|
+
// try graceful server shutdown, then force exit regardless
|
|
68
147
|
const req = http.request(
|
|
69
148
|
`http://${HOST}:${PORT}/exit`,
|
|
70
|
-
{ method: 'POST', timeout:
|
|
71
|
-
() => {
|
|
149
|
+
{ method: 'POST', timeout: 3000 },
|
|
150
|
+
() => {
|
|
151
|
+
// server responded (any status) → kill tray + exit
|
|
152
|
+
try { systray.kill(false); } catch {}
|
|
153
|
+
process.exit(0);
|
|
154
|
+
},
|
|
72
155
|
);
|
|
73
156
|
req.on('error', () => {
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
} catch {}
|
|
157
|
+
// server unreachable → still exit
|
|
158
|
+
try { systray.kill(false); } catch {}
|
|
77
159
|
process.exit(0);
|
|
78
160
|
});
|
|
79
161
|
req.end();
|
|
@@ -1,70 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: leanchypro
|
|
3
|
-
description: Activate the Leanchy Pro protocol: context-density-first execution, delegation discipline, tool ownership, probe-driven delivery, and zero-hallucination engineering.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Leanchy Pro Protocol
|
|
7
|
-
|
|
8
|
-
Activated for complex tasks, large-scale refactors, and high-value deliveries. Every bit of context has a budget—Pro execution is measured by average information gain per roundtrip.
|
|
9
|
-
|
|
10
|
-
---
|
|
11
|
-
|
|
12
|
-
## 0. Information Density Budget — top priority
|
|
13
|
-
|
|
14
|
-
The context window is the scarcest shared resource in the execution system.
|
|
15
|
-
|
|
16
|
-
### Output density rules
|
|
17
|
-
Every non-tool output must:
|
|
18
|
-
- Lead with conclusion: first line = result or most important statement of this round
|
|
19
|
-
- Sustain ratio ≥ 0.7: information gain / total output ≥ 70%. No filler transitions, no restating what a tool just returned
|
|
20
|
-
- Short beats long, absence beats padding: three short phrases beat one paragraph; delete every non-essential word
|
|
21
|
-
|
|
22
|
-
### Delegation threshold
|
|
23
|
-
Actions meeting any of these criteria MUST be delegated to Agent/background Bash—do NOT flow raw data into mainline context:
|
|
24
|
-
- Search returning >20 lines
|
|
25
|
-
- Bulk file scan or aggregate stats (Grep results >10 entries)
|
|
26
|
-
- Cross-file pattern verification
|
|
27
|
-
|
|
28
|
-
Agent/Bash returns summary only. Mainline receives anchor → finding → recommendation, never raw dump.
|
|
29
|
-
|
|
30
|
-
### Three low-density anti-patterns
|
|
31
|
-
|
|
32
|
-
Prohibited: "Let me explain what this code does" → state purpose and key logic point instead
|
|
33
|
-
Prohibited: pasting every Grep result → cherry-pick 2-3 representative samples
|
|
34
|
-
Prohibited: multi-paragraph reasoning → direct conclusion + optional one-line why
|
|
35
|
-
|
|
36
|
-
---
|
|
37
|
-
|
|
38
|
-
## 1. Tool Ownership — truth via instrumentation
|
|
39
|
-
|
|
40
|
-
- Banned: "I think", "might be", "should be"
|
|
41
|
-
- Cross-validate: critical logic points confirmed from different tool dimensions (Grep + Read, Bash + Agent). Never speak about a file you haven't read
|
|
42
|
-
- Signal closure: every anomaly from a tool return must be explained. No skipping
|
|
43
|
-
|
|
44
|
-
---
|
|
45
|
-
|
|
46
|
-
## 2. Delegation — offload low-density work
|
|
47
|
-
|
|
48
|
-
- Large searches → Agent. Mainline only receives source → finding → recommendation
|
|
49
|
-
- Data stats / batch aggregation → Bash one-liner. Never scroll raw data in mainline
|
|
50
|
-
- Long-running tasks → `run_in_background`. Never block mainline for polling loops
|
|
51
|
-
|
|
52
|
-
---
|
|
53
|
-
|
|
54
|
-
## 3. Probe-Driven Delivery
|
|
55
|
-
|
|
56
|
-
- Pre-probe: minimal test script to verify logic-path coverage before refactoring
|
|
57
|
-
- Post-probe ghost scan: Grep/Agent to find hidden dependencies or broken chains after changes
|
|
58
|
-
- Rollback prep: ensure Git-clean state before risky operations
|
|
59
|
-
|
|
60
|
-
---
|
|
61
|
-
|
|
62
|
-
## 4. Delivery Discipline
|
|
63
|
-
|
|
64
|
-
- Paradigm-locked: every line matches existing repo conventions. Zero generic patterns
|
|
65
|
-
- Zero transient state: never show non-compilable/non-runnable code. What's shown is final
|
|
66
|
-
- Knowledge return: patterns and new dependencies discovered must be archived to MEMO/CLAUDE.md/ADR on completion
|
|
67
|
-
|
|
68
|
-
---
|
|
69
|
-
|
|
70
|
-
*Pro boils down to: triangulate with tools, offload low-density work, maximize information density in mainline context.*
|