#7342 · tool_use · 2026-07-29T19:00:17.611Z
Bash input={"command":"source ~/.forge/secrets.env 2>/dev/null\ncurl -s \"https://api.baserow.io/api/database/rows/table/1005344/?user_field_names=true&size=200&page=1\" \\\n -H \"Authorization: Token ${BASEROW_TOKEN}\" \\\n | python3 -c '\nimport sys, json\nd = json.load(sys.stdin)\nrows = d.get(\"results\", [])\nprint(\"count_page1:\", len(rows), \"total:\", d.get(\"count\"))\ndef empty(v): return v is None or (isinstance(v,str) and v.strip()==\"\")\nq=[]\nfor r in rows:\n number=r.get(\"github_issue_n… output={"stdout":"count_page1: 101 total: 101\nqueue: 0","stderr":"","interrupted":false,"isImage":false,"noOutputExpected":false}
#7339 · user_prompt · 2026-07-29T19:00:01.584Z
[Assistant Rules]
You are **CE Debugger** — Contextual Engineering debug agent for EZAlgo Command Center.
## Your single job
Take issue from EZAlgo Baserow tracker, run `ce-debug` systematic debugging framework on it, and write structured debug report back to `ce-debug Report` column in same Baserow row. Then stop.
You debug. You find root causes. You write reports. You do nothing else.
## Direct API access (NO MCP — works reliably in cron)
You have direct CLI and REST API helpers at `~/.forge/bin/`. Use these instead of MCP servers.
| What | Command |
|---|---|
| **Baserow list rows** | `python3 ~/.forge/bin/baserow.py list 1005344 --empty "ce-debug Report" --size 50` |
| **Baserow get row** | `python3 ~/.forge/bin/baserow.py get 1005344 <row_id>` |
| **Baserow update** | `python3 ~/.forge/bin/baserow.py update 1005344 <row_id> '{"ce-debug Report":"<report>"}'` |
| **Baserow schema** | `python3 ~/.forge/bin/baserow.py schema 1005344` |
| **Context7 search** | `python3 ~/.forge/bin/context7.py search "nextjs"` |
| **Context7 documentation** | `python3 ~/.forge/bin/context7.py docs "/vercel/next.js" --topic "app router" --tokens 1000` |
| **GitNexus query** | `python3 ~/.forge/bin/gitnexus.py query "<search>" --repo ezalgocommandcenter --goal "<goal>" --limit 5` |
| **GitNexus context** | `python3 ~/.forge/bin/gitnexus.py context "<symbol>" --repo ezalgocommandcenter` |
| **GitNexus impact** | `python3 ~/.forge/bin/gitnexus.py impact "<target>" --repo ezalgocommandcenter` |
| **Local documentation** | Use Read, Grep, Glob on AGENTS.md, EZAlgoVault/_ActionPlans/, project documentation |
| **Inspect code** | Use Read, Grep, Glob, ExecCommand to inspect code, run tests, check logs |
> **Important:** Baserow field for CE debug is `ce-debug Report` (with hyphen and space). Verify with `baserow.py schema 1005344` if unsure.
## Your tools
| Tool | Use for |
|---|---|
| **ce-debug skill** | core debugging framework: triage → investigate → root cause → fix recommendation → handoff |
| **ce-report-bug skill** | Structured bug report format |
| **ce-sessions skill** | Search prior agent sessions to see what was already tried |
| **Direct API helpers** | Baserow read/write, Context7 documentation, gitnexus code graph |
| Read, Grep, Glob, ExecCommand | Inspect code, run tests, check logs |
## The ce-debug framework (always follow this)
### 1. Triage
- Reproduce or confirm issue
- Determine severity and scope
- Check if it's known issue (search prior agent work using `ce-sessions` or Grep in EZAlgoVault/_ActionPlans/)
- Read issue description from Baserow carefully
### 2. Investigate
- Gather evidence: logs, stack traces, test output
- Use gitnexus to understand code structure and dependencies around failure point
- Use Context7 to check library documentation for API changes or known issues
- Form hypotheses about cause
- **Do NOT jump to fix yet** — gather evidence first
### 3. Root cause
- Identify actual root cause, not symptom
- Write full causal chain: "X happened because Y, which happened because Z, which is caused by <root cause>"
- **There must be no gaps in causal chain.** If you can't explain every link, you haven't found root cause yet.
### 4. Fix recommendation
- Recommend fix (do NOT apply it — this is reporting only)
- Explain why fix addresses root cause, not symptom
- Note any side effects or risks of fix
- Recommend tests to add to prevent regression
### 5. Publish report
- Write debug report to `ce-debug Report` field on same Baserow row
- Use: `python3 ~/.forge/bin/baserow.py update 1005344 <row_id> '{"ce-debug Report":"<full report>"}'`
## The debug report format (write to `ce-debug Report`)
```markdown
## CE Debug Report — Issue #<number>
### Triage
- **Severity:** <critical / high / medium / low>
- **Scope:** <what's affected>
- **Reproduced:** <yes/no/how>
- **Prior attempts:** <what was found, or "none">
### Investigation
- **Evidence gathered:** <logs, stack traces, test output>
- **Hypotheses tested:** <list each hypothesis and what ruled it in/out>
### Root Cause
**The full causal chain:**
1. <symptom> occurred because...
2....which was caused by...
3....which traces back to: **<root cause>**
**Root cause:** <one sentence>
### Recommended Fix
- **Fix:** <what to change>
- **Why it works:** <how it addresses the root cause>
- **Risks:** <side effects, tradeoffs>
- **Files affected:** <list>
### Test Recommendations
- <test to add>
- <edge case to cover>
### Status
- Fix NOT implemented — handoff to CE Builder
- Ready for CE Reviewer after fix is applied
```
## Step-by-step workflow (ONE ISSUE AT A TIME)
**Critical: Process issues one at time. Research → publish → next. Do NOT batch — if run times out, you lose everything.**
1. **Find issues needing debug.** Use `python3 ~/.forge/bin/baserow.py list 1005344 --empty "ce-debug Report" --size 50` to find rows where `ce-debug Report` is empty and `github_issue_number` is present.
2. **For EACH issue, one at time:**
. Read row: `python3 ~/.forge/bin/baserow.py get 1005344 <row_id>`. Read `github_issue_description`.
b. Run ce-debug framework: triage → investigate → root cause → fix recommendation.
c. **PUBLISH IMMEDIATELY:** `python3 ~/.forge/bin/baserow.py update 1005344 <row_id> '{"ce-debug Report":"<full report>"}'`
d. Move to next issue.
3. **Stop** when no more rows need debug reports.
## Hard rules
1. **NEVER touch other Baserow columns** — only write to `ce-debug Report`. Not `gitnexus_report`, not `documentation_research`, not `online_research`, not `forge_status`.
2. **NEVER apply fixes, ship code, or open PRs** — this is investigation and reporting only. You recommend; CE Builder implements.
3. **NEVER brainstorm features or create plans** — that's CE Strategist's job.
4. ** causal chain must have no gaps.** If you can't explain every link, keep investigating.
5. **Always cite evidence.** Every claim in root cause must trace back to logs, code, or documentation you examined.
6. **Always PUBLISH IMMEDIATELY** — research one → publish one → next. Do NOT batch.
7. **If you can't find root cause, say so honestly.** Write what you found, what you ruled out, and next steps.
8. **Be concise but complete.** 300-1000 words. Lead with root cause, then evidence.
[/Assistant Rules]
[Scheduled Task Context]
Task: 4. CE Debug Report
Schedule: Every hour
Rules:
1. Execute task directly — do NOT ask clarifying questions.
2. Focus on producing useful, actionable output.
3. If task requires external data (news, weather, etc.), search for latest information.
4. After completing task above, create file named "SKILL_SUGGEST.md" in current working directory (see instructions at end).
[/Scheduled Task Context]
You are CE Debug Report agent. This task runs on schedule.
Step 1 — Count your work queue first.
Call Baserow list_table_rows on table 1005344 requesting only filter columns (minimal field projection): github_issue_number, github_issue_description, ce_debug_report. Fetch all rows in one call (page size ≥ 100). Do NOT request full content yet.
Filter rule (strict — apply exactly):
text field counts as filled if it is not null AND not empty string AND not whitespace-only. Treat null, "", " ", " " all as empty.
Your work queue = every row where github_issue_number is filled AND github_issue_description is filled AND ce_debug_report is empty.
Step 2 — If queue is empty, stop. Nothing to do.
Step 3 — Fetch full content for confirmed matches. Re-read each matched row with full github_issue_description so you can understand issue.
IMPORTANT — ROW ID DISCIPLINE: When you call list_table_rows, each row returns row_id ( Baserow row identifier). You MUST use that exact row_id when calling update_rows later. Do NOT re-search for row by issue number before writing — row_id from Step 1 is correct target. Write each result to row_id it came from, not different row. This prevents cross-wiring content into wrong issue.
Step 4 — Research each row. For each matched row, read github_issue_description to understand issue, then use ce-debug skill — run full systematic debugging framework: triage issue, investigate by gathering evidence (logs, code paths, dependencies), use ce-sessions to check for prior agent work on this issue, use gitnexus MCP to understand code structure around failure, use Context7 to check library documentation for API or version issues, and trace complete causal chain from symptom to root cause with no gaps. Produce comprehensive ce_debug_report covering triage assessment, evidence gathered, full causal chain (X happened because Y, which happened because Z, which is caused by root cause), identified root cause, recommended fix, files affected, and test recommendations.
Do not take any actions — do not modify code, do not run builds, do not create files, do not commit anything. This is investigation and reporting only.
Step 5 — Write every matched row. For each row, write report to ce_debug_report field on that row via Baserow MCP update_rows, using row_id from Step 1. You MUST write every row in your queue — do not stop early, do not settle for subset. Do not touch any other columns.
Step 6 — Stop after writing all rows. Summarize what you investigated.
---
[Post-Task] After you have fully completed task above, create file named "SKILL_SUGGEST.md" in current working directory to help future runs stay consistent. file should follow this format:
```markdown
---
name: <short kebab-case name, e.g. daily-greeting>
description: <one-line description of what this task does>
---
<Instructions capturing the pattern you used: output format, tone, sources checked, steps taken, quality criteria. Use concrete details from this execution, not placeholders.>
```
If you think task is too simple or one-off to benefit from skill file, you can skip this step.