@runweave/server-linux-x64 0.1.7 → 0.1.9

package/payload/plugins/toolkit/skills/debugging-strategies/resources/implementation-playbook.md

@@ -0,0 +1,520 @@
+# Debugging Strategies Implementation Playbook
+
+This file contains detailed patterns, checklists, and code samples referenced by the skill.
+
+## Core Principles
+
+### 1. The Scientific Method
+
+**1. Observe**: What's the actual behavior?
+**2. Hypothesize**: What could be causing it?
+**3. Experiment**: Test your hypothesis
+**4. Analyze**: Did it prove/disprove your theory?
+**5. Repeat**: Until you find the root cause
+
+### 2. Debugging Mindset
+
+**Don't Assume:**
+
+- "It can't be X" - Yes it can
+- "I didn't change Y" - Check anyway
+- "It works on my machine" - Find out why
+
+**Do:**
+
+- Reproduce consistently
+- Isolate the problem
+- Keep detailed notes
+- Question everything
+- Take breaks when stuck
+
+### 3. Rubber Duck Debugging
+
+Explain your code and problem out loud (to a rubber duck, colleague, or yourself). Often reveals the issue.
+
+## Systematic Debugging Process
+
+### Phase 1: Reproduce
+
+```markdown
+## Reproduction Checklist
+
+1. **Can you reproduce it?**
+   - Always? Sometimes? Randomly?
+   - Specific conditions needed?
+   - Can others reproduce it?
+
+2. **Create minimal reproduction**
+   - Simplify to smallest example
+   - Remove unrelated code
+   - Isolate the problem
+
+3. **Document steps**
+   - Write down exact steps
+   - Note environment details
+   - Capture error messages
+```
+
+### Phase 2: Gather Information
+
+```markdown
+## Information Collection
+
+1. **Error Messages**
+   - Full stack trace
+   - Error codes
+   - Console/log output
+
+2. **Environment**
+   - OS version
+   - Language/runtime version
+   - Dependencies versions
+   - Environment variables
+
+3. **Recent Changes**
+   - Git history
+   - Deployment timeline
+   - Configuration changes
+
+4. **Scope**
+   - Affects all users or specific ones?
+   - All browsers or specific ones?
+   - Production only or also dev?
+```
+
+### Phase 3: Form Hypothesis
+
+```markdown
+## Hypothesis Formation
+
+Based on gathered info, ask:
+
+1. **What changed?**
+   - Recent code changes
+   - Dependency updates
+   - Infrastructure changes
+
+2. **What's different?**
+   - Working vs broken environment
+   - Working vs broken user
+   - Before vs after
+
+3. **Where could this fail?**
+   - Input validation
+   - Business logic
+   - Data layer
+   - External services
+```
+
+### Phase 4: Test & Verify
+
+```markdown
+## Testing Strategies
+
+1. **Binary Search**
+   - Comment out half the code
+   - Narrow down problematic section
+   - Repeat until found
+
+2. **Add Logging**
+   - Strategic console.log/print
+   - Track variable values
+   - Trace execution flow
+
+3. **Isolate Components**
+   - Test each piece separately
+   - Mock dependencies
+   - Remove complexity
+
+4. **Compare Working vs Broken**
+   - Diff configurations
+   - Diff environments
+   - Diff data
+```
+
+## Debugging Tools
+
+### JavaScript/TypeScript Debugging
+
+```typescript
+// Chrome DevTools Debugger
+function processOrder(order: Order) {
+  debugger; // Execution pauses here
+
+  const total = calculateTotal(order);
+  console.log("Total:", total);
+
+  // Conditional breakpoint
+  if (order.items.length > 10) {
+    debugger; // Only breaks if condition true
+  }
+
+  return total;
+}
+
+// Console debugging techniques
+console.log("Value:", value); // Basic
+console.table(arrayOfObjects); // Table format
+console.time("operation");
+/* code */ console.timeEnd("operation"); // Timing
+console.trace(); // Stack trace
+console.assert(value > 0, "Value must be positive"); // Assertion
+
+// Performance profiling
+performance.mark("start-operation");
+// ... operation code
+performance.mark("end-operation");
+performance.measure("operation", "start-operation", "end-operation");
+console.log(performance.getEntriesByType("measure"));
+```
+
+**VS Code Debugger Configuration:**
+
+```json
+// .vscode/launch.json
+{
+  "version": "0.2.0",
+  "configurations": [
+    {
+      "type": "node",
+      "request": "launch",
+      "name": "Debug Program",
+      "program": "${workspaceFolder}/src/index.ts",
+      "preLaunchTask": "tsc: build - tsconfig.json",
+      "outFiles": ["${workspaceFolder}/dist/**/*.js"],
+      "skipFiles": ["<node_internals>/**"]
+    },
+    {
+      "type": "node",
+      "request": "launch",
+      "name": "Debug Tests",
+      "program": "${workspaceFolder}/node_modules/jest/bin/jest",
+      "args": ["--runInBand", "--no-cache"],
+      "console": "integratedTerminal"
+    }
+  ]
+}
+```
+
+### Python Debugging
+
+```python
+# Built-in debugger (pdb)
+import pdb
+
+def calculate_total(items):
+    total = 0
+    pdb.set_trace()  # Debugger starts here
+
+    for item in items:
+        total += item.price * item.quantity
+
+    return total
+
+# Breakpoint (Python 3.7+)
+def process_order(order):
+    breakpoint()  # More convenient than pdb.set_trace()
+    # ... code
+
+# Post-mortem debugging
+try:
+    risky_operation()
+except Exception:
+    import pdb
+    pdb.post_mortem()  # Debug at exception point
+
+# IPython debugging (ipdb)
+from ipdb import set_trace
+set_trace()  # Better interface than pdb
+
+# Logging for debugging
+import logging
+logging.basicConfig(level=logging.DEBUG)
+logger = logging.getLogger(__name__)
+
+def fetch_user(user_id):
+    logger.debug(f'Fetching user: {user_id}')
+    user = db.query(User).get(user_id)
+    logger.debug(f'Found user: {user}')
+    return user
+
+# Profile performance
+import cProfile
+import pstats
+
+cProfile.run('slow_function()', 'profile_stats')
+stats = pstats.Stats('profile_stats')
+stats.sort_stats('cumulative')
+stats.print_stats(10)  # Top 10 slowest
+```
+
+### Go Debugging
+
+```go
+// Delve debugger
+// Install: go install github.com/go-delve/delve/cmd/dlv@latest
+// Run: dlv debug main.go
+
+import (
+    "fmt"
+    "runtime"
+    "runtime/debug"
+)
+
+// Print stack trace
+func debugStack() {
+    debug.PrintStack()
+}
+
+// Panic recovery with debugging
+func processRequest() {
+    defer func() {
+        if r := recover(); r != nil {
+            fmt.Println("Panic:", r)
+            debug.PrintStack()
+        }
+    }()
+
+    // ... code that might panic
+}
+
+// Memory profiling
+import _ "net/http/pprof"
+// Visit http://localhost:6060/debug/pprof/
+
+// CPU profiling
+import (
+    "os"
+    "runtime/pprof"
+)
+
+f, _ := os.Create("cpu.prof")
+pprof.StartCPUProfile(f)
+defer pprof.StopCPUProfile()
+// ... code to profile
+```
+
+## Advanced Debugging Techniques
+
+### Technique 1: Binary Search Debugging
+
+```bash
+# Git bisect for finding regression
+git bisect start
+git bisect bad                    # Current commit is bad
+git bisect good v1.0.0            # v1.0.0 was good
+
+# Git checks out middle commit
+# Test it, then:
+git bisect good   # if it works
+git bisect bad    # if it's broken
+
+# Continue until bug found
+git bisect reset  # when done
+```
+
+### Technique 2: Differential Debugging
+
+Compare working vs broken:
+
+```markdown
+## What's Different?
+
+| Aspect       | Working     | Broken         |
+| ------------ | ----------- | -------------- |
+| Environment  | Development | Production     |
+| Node version | 18.16.0     | 18.15.0        |
+| Data         | Empty DB    | 1M records     |
+| User         | Admin       | Regular user   |
+| Browser      | Chrome      | Safari         |
+| Time         | During day  | After midnight |
+
+Hypothesis: Time-based issue? Check timezone handling.
+```
+
+### Technique 3: Trace Debugging
+
+```typescript
+// Function call tracing
+function trace(
+  target: any,
+  propertyKey: string,
+  descriptor: PropertyDescriptor,
+) {
+  const originalMethod = descriptor.value;
+
+  descriptor.value = function (...args: any[]) {
+    console.log(`Calling ${propertyKey} with args:`, args);
+    const result = originalMethod.apply(this, args);
+    console.log(`${propertyKey} returned:`, result);
+    return result;
+  };
+
+  return descriptor;
+}
+
+class OrderService {
+  @trace
+  calculateTotal(items: Item[]): number {
+    return items.reduce((sum, item) => sum + item.price, 0);
+  }
+}
+```
+
+### Technique 4: Memory Leak Detection
+
+```typescript
+// Chrome DevTools Memory Profiler
+// 1. Take heap snapshot
+// 2. Perform action
+// 3. Take another snapshot
+// 4. Compare snapshots
+
+// Node.js memory debugging
+if (process.memoryUsage().heapUsed > 500 * 1024 * 1024) {
+  console.warn("High memory usage:", process.memoryUsage());
+
+  // Generate heap dump
+  require("v8").writeHeapSnapshot();
+}
+
+// Find memory leaks in tests
+let beforeMemory: number;
+
+beforeEach(() => {
+  beforeMemory = process.memoryUsage().heapUsed;
+});
+
+afterEach(() => {
+  const afterMemory = process.memoryUsage().heapUsed;
+  const diff = afterMemory - beforeMemory;
+
+  if (diff > 10 * 1024 * 1024) {
+    // 10MB threshold
+    console.warn(`Possible memory leak: ${diff / 1024 / 1024}MB`);
+  }
+});
+```
+
+## Debugging Patterns by Issue Type
+
+### Pattern 1: Intermittent Bugs
+
+```markdown
+## Strategies for Flaky Bugs
+
+1. **Add extensive logging**
+   - Log timing information
+   - Log all state transitions
+   - Log external interactions
+
+2. **Look for race conditions**
+   - Concurrent access to shared state
+   - Async operations completing out of order
+   - Missing synchronization
+
+3. **Check timing dependencies**
+   - setTimeout/setInterval
+   - Promise resolution order
+   - Animation frame timing
+
+4. **Stress test**
+   - Run many times
+   - Vary timing
+   - Simulate load
+```
+
+### Pattern 2: Performance Issues
+
+```markdown
+## Performance Debugging
+
+1. **Profile first**
+   - Don't optimize blindly
+   - Measure before and after
+   - Find bottlenecks
+
+2. **Common culprits**
+   - N+1 queries
+   - Unnecessary re-renders
+   - Large data processing
+   - Synchronous I/O
+
+3. **Tools**
+   - Browser DevTools Performance tab
+   - Lighthouse
+   - Python: cProfile, line_profiler
+   - Node: clinic.js, 0x
+```
+
+### Pattern 3: Production Bugs
+
+```markdown
+## Production Debugging
+
+1. **Gather evidence**
+   - Error tracking (Sentry, Bugsnag)
+   - Application logs
+   - User reports
+   - Metrics/monitoring
+
+2. **Reproduce locally**
+   - Use production data (anonymized)
+   - Match environment
+   - Follow exact steps
+
+3. **Safe investigation**
+   - Don't change production
+   - Use feature flags
+   - Add monitoring/logging
+   - Test fixes in staging
+```
+
+## Best Practices
+
+1. **Reproduce First**: Can't fix what you can't reproduce
+2. **Isolate the Problem**: Remove complexity until minimal case
+3. **Read Error Messages**: They're usually helpful
+4. **Check Recent Changes**: Most bugs are recent
+5. **Use Version Control**: Git bisect, blame, history
+6. **Take Breaks**: Fresh eyes see better
+7. **Document Findings**: Help future you
+8. **Fix Root Cause**: Not just symptoms
+
+## Common Debugging Mistakes
+
+- **Making Multiple Changes**: Change one thing at a time
+- **Not Reading Error Messages**: Read the full stack trace
+- **Assuming It's Complex**: Often it's simple
+- **Debug Logging in Prod**: Remove before shipping
+- **Not Using Debugger**: console.log isn't always best
+- **Giving Up Too Soon**: Persistence pays off
+- **Not Testing the Fix**: Verify it actually works
+
+## Quick Debugging Checklist
+
+```markdown
+## When Stuck, Check:
+
+- [ ] Spelling errors (typos in variable names)
+- [ ] Case sensitivity (fileName vs filename)
+- [ ] Null/undefined values
+- [ ] Array index off-by-one
+- [ ] Async timing (race conditions)
+- [ ] Scope issues (closure, hoisting)
+- [ ] Type mismatches
+- [ ] Missing dependencies
+- [ ] Environment variables
+- [ ] File paths (absolute vs relative)
+- [ ] Cache issues (clear cache)
+- [ ] Stale data (refresh database)
+```
+
+## Resources
+
+- **references/debugging-tools-guide.md**: Comprehensive tool documentation
+- **references/performance-profiling.md**: Performance debugging guide
+- **references/production-debugging.md**: Debugging live systems
+- **assets/debugging-checklist.md**: Quick reference checklist
+- **assets/common-bugs.md**: Common bug patterns
+- **scripts/debug-helper.ts**: Debugging utility functions

package/payload/plugins/toolkit/skills/diagnostic-log-debugging/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: diagnostic-log-debugging
+description: Use when 用户明确点名这个 skill，或明确要求通过日志、诊断日志、日志记录、logs、diagnostic logs、log recording 来诊断、复现、debug 或定位问题。不要用于普通调试、常规开发、代码评审或一般 bug 修复。
+---
+
+# 诊断日志调试
+
+## 默认规则
+
+默认不要启用或展示 AI 诊断日志。这个 skill 只能显式启用：
+
+- 用户明确点名这个 skill 时，才使用。
+- 用户明确要求通过日志或诊断日志记录来定位、诊断、复现问题时，才使用。
+- 如果用户只是要求普通调试，但没有要求通过日志定位问题，不要使用这个 skill。
+
+本技能负责新增、录制和分析 AI 诊断日志，不负责制定“未复现就不修复”的决策门槛。用户显式要求先做真实复现、再决定是否修复时，使用 `$toolkit:reproduce-before-fix`；同时需要诊断日志时组合使用两个技能。只有沿真实产品入口采集的日志才能作为真实复现证据，模拟路径或伪造状态产生的日志不能替代复现。
+
+## 怎么记录日志
+
+诊断日志不会自动收集普通 `console.log`、stdout、stderr、子进程输出、运行时错误或已有日志文件。只有显式调用 AI 诊断日志工具函数写入的内容，才会进入本轮诊断结果。
+
+前端记录方式：
+
+```ts
+import { aiDiagnosticLog } from "../features/diagnostic-logs/recorder";
+
+aiDiagnosticLog("viewer connection state changed", {
+  sessionId,
+  previousState,
+  nextState,
+});
+```
+
+后端记录方式：
+
+```ts
+import { aiDiagnosticLog } from "../diagnostic-logs/recorder";
+
+aiDiagnosticLog("terminal session restore requested", {
+  terminalSessionId,
+  runtimeKind,
+});
+```
+
+埋点原则：
+
+- 只在可疑路径、关键状态流转、请求开始/完成/失败、分支判断处加少量日志。
+- `message` 写稳定事件名；`details` 放结构化字段，例如 id、状态、计数、错误类型和必要错误信息。
+- 不记录 token、cookie、authorization、密码、完整敏感 URL、本地文件内容或大段日志正文。
+- 不要为了收集日志去包裹全局 `console.*`、`process.stdout`、`process.stderr`、子进程输出或错误监听。
+- 工具函数始终会打印到控制台；只有处于“记录中”窗口时，才会额外写入诊断日志收集器。
+- 如果结果里没有预期日志，先确认记录窗口已经开始、用户路径确实执行到了该代码、调用使用的是 `aiDiagnosticLog(...)` 而不是普通 `console.log(...)`。
+
+## 工作流程
+
+1. 确认触发条件有效。
+   如果请求只是普通调试，没有要求基于日志诊断，不要使用这个 skill。
+
+2. 添加聚焦的 AI 诊断日志。
+   按“怎么记录日志”里的方式，在前端或后端可疑路径中调用 `aiDiagnosticLog(...)`。只添加能解释可疑用户路径或状态流转的日志。不要宽泛包裹 console 输出、stdout、stderr、子进程输出、运行时错误或本地文件内容。
+
+3. 通过 UI 录制复现过程。
+   在 Web 终端工作区右上角点击 `More actions`，选择 `日志上报`，点击 `开始记录`，执行能复现问题的用户操作，然后点击 `结束并上报`。优先使用 UI 控件，不要优先使用裸 HTTP 调用，这样才能捕获浏览器侧日志。
+
+4. 检查诊断结果。
+   使用结果弹窗、下载日志，或 `GET /api/diagnostic-logs/result` 查看时间线。在改代码之前，先定位第一个异常状态、请求、响应或状态流转。
+
+5. 最小化修复。
+   用最小代码改动解决根因，并遵循项目已有模式。对 React `.tsx` 和 UI hooks，不要新增单测；使用诊断日志记录和聚焦的集成检查。对纯 `.ts` 逻辑，必要时新增或更新有针对性的测试。
+
+6. 验证修复。
+   再次复现同一路径，确认用户可见行为已经修复，并确认诊断结果中包含预期的前端和后端证据。
+
+## Runweave 注意事项
+
+- 开始新一轮记录会清空上一轮内存中的诊断结果。
+- 不存在 `/api/diagnostic-logs/clear` 接口。不要新增，也不要调用。
+- 如果结束记录失败，先检查浏览器 console 和 Network。连接被拒绝通常意味着 dev server 或后端没有运行。
+- 面向用户的状态消息要足够具体，能说明失败来自后端、网络，还是日志记录状态问题。

package/payload/plugins/toolkit/skills/doc-coauthoring/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: doc-coauthoring
+description: "Co-author documentation, proposals, technical specs, and decision docs from available context, refining the draft with user feedback. Use for substantive writing or revision; simple wording edits do not need this workflow."
+metadata:
+  risk: unknown
+  source: community
+  date_added: "2026-02-27"
+---
+
+# Doc Co-Authoring
+
+Produce a document that its intended readers can understand and use. Adapt the collaboration to the task: draft directly when context is sufficient; explore decisions with the user when they ask for deeper co-authoring or the content depends on unresolved choices.
+
+## Establish the context
+
+- Infer the audience, purpose, desired outcome, format, and scope from the request and conversation. Read the existing document, supplied template, and relevant sources before asking for information already available.
+- For technical documents, check relevant code and current project documentation. Distinguish current behavior, proposed changes, and unresolved assumptions.
+- Use available tools to retrieve relevant sources within the task's scope. If a source is inaccessible, identify the specific missing information and continue work that does not depend on it.
+- Ask a focused question only when a missing fact or decision materially affects the document and cannot be resolved from context. Do not require an initial questionnaire or a fixed number of questions.
+- If the user is sharing background, accept rough notes and organize them. Do not ask for exhaustive context unrelated to the intended document.
+
+Begin drafting once the purpose and essential content are clear. There is no separate approval step for moving between writing activities.
+
+## Draft according to the task
+
+For a straightforward request, produce a coherent draft using the user's template or an appropriate structure. Choose section order and depth based on what readers need to understand or decide. Do not create an empty scaffold as a mandatory intermediate deliverable.
+
+For substantial co-authoring or an unsettled proposal:
+
+- Start with the decision or section whose uncertainty affects the rest of the document.
+- Present alternatives only when they represent meaningful choices; explain the recommended direction and trade-offs. Do not generate options to meet a quota.
+- Ask the user to choose only when the choice depends on their goals or preferences. Select routine organization and wording yourself.
+- Draft the settled content while dependent decisions remain open. Clearly identify unresolved points instead of inventing facts.
+
+For example, a request to document an existing API can start from its implementation and a draft. A proposal whose recommendation depends on an unknown rollout constraint needs that decision clarified, while its established background can still be written.
+
+## Refine with the user
+
+- Accept comments, freeform feedback, or direct user edits. Do not require numbered keep/remove/combine selections or ask the user to avoid editing the document.
+- Apply feedback to the relevant passages and carry established terminology and style into later sections. Preserve unrelated user changes.
+- Re-read the current document before editing when the user may have changed it.
+- Ask follow-up questions only when feedback leaves a consequential ambiguity. Do not require confirmation after each section or another review after a fixed number of iterations.
+- Follow requests to skip discussion, change the structure, or move directly to a finished draft without reconfirming the process.
+
+## Check the document as a reader
+
+Before delivery, check the whole document for:
+
+- A clear purpose, supported claims, and enough context for its intended audience.
+- Consistent terms, decisions, and technical details across sections.
+- Missing prerequisites or unexplained assumptions that could cause a wrong decision.
+- Repetition, contradictions, generic filler, and broken or unsupported references.
+
+For instructions and decision documents, consider whether a reader could carry out the intended action or explain the decision from the document alone. Use realistic reader questions where they reveal a gap; do not impose a question count.
+
+Independent reader review is optional when requested or when consequential ambiguity warrants it and delegation is permitted. Give the reviewer the document and intended audience without supplying hidden background or expected answers. Revise based on concrete misunderstandings; do not require one agent per question or repeated reviews without new findings. If independent review is unavailable, complete the available checks and state any material limitation instead of requiring the user to open another chat.
+
+Only claim independent reader review when it actually occurred. Checking prose does not establish that a described implementation works.
+
+## Deliver
+
+Use the user's requested destination and format. For repository files, follow the project's documentation placement and validation rules; for a conversational draft, return the text without creating extra files by default. Use the editing tools available in the environment.
+
+Deliver once the requested content is complete, relevant checks are done, and material open questions are resolved or explicitly identified. Provide the document or its link and briefly note any remaining decisions or verification gaps. Do not add an automatic final approval round, process appendix, or separate review report.

package/payload/plugins/toolkit/skills/eli5/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) Thariq Shihipar
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

package/payload/plugins/toolkit/skills/eli5/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: eli5
+description: Explain a topic like I'm a 5 year old. Use when the user types /eli5 followed by a topic or asks for a dead-simple picture explainer of how something works.
+license: MIT
+metadata:
+  author: Thariq Shihipar
+  source: https://github.com/anthropics/claude-plugins-community/blob/863e70dc7cff21a2facc749e40a7ecd1a5d19833/eli5/skills/eli5/SKILL.md
+  adapted_for: Runweave Toolkit
+  changes: Removed angle brackets from the discovery description and added a Codex topic fallback; original explanation instruction preserved.
+---
+
+# eli5
+
+Explain like I'm someone who knows nothing about this topic, using a HTML artifact with big pictures and few words.
+
+Topic: $ARGUMENTS
+
+In Codex, use the topic supplied with `$toolkit:eli5` when `$ARGUMENTS` is not substituted.