103 Agent Concurrent Processing Report (2026-08-09)

103/103

Proposal completion rate

PR actions

CLOSE actions

COMMENT actions

Closed (14+6+3)

260M

Subagent input tokens

1. Task Background: Jason 2194 Instructions

Jason (Telegram main:6859932159:2194) instructed: for the Lingtai-AI/lingtai (37) and Lingtai-AI/lingtai-kernel (66) repositories, run all open issues (103 total) with one daemon emanation per issue, all in parallel, producing for each issue a proposal for one of three actions: PR / CLOSE / COMMENT; when an issue is small with clear boundaries and can be correctly implemented and tested locally, use deepseek (the current default model) to write the PR directly; Fable audits the resulting PRs at a cadence of 5 PRs per batch.

Each sub-daemon independently analyzes the full issue text and comments, verifies against current main (HEAD df2b523d) whether it is “already fixed / still reproducible”, and applies owner/overlap-lane protection (issues already handled by someone else's PR always get a COMMENT pointing to it, never a duplicate PR).
CLOSE is preferred for “already fixed on main / superseded”; COMMENT is preferred for “needs more information, product decision, or is a large design item”; PR only when the fix is small, unambiguous, locally testable, and matches a real defect on current main.
103 daemons were dispatched in 3 groups: lingtai 37 (dg-20260809-021029-bb27eb), kernel-1 33 (dg-20260809-021146-f9ccbb), kernel-2 33 (dg-20260809-021152-4cb99e), starting around 2026-08-09 02:10Z; Task Card tc_1 tracked progress throughout and aggregated the token usage of subagents (not the parent agent).

2. Completion Status and Action Distribution

Final verification: all 103 / 103 issue directories have proposal.md on disk (37 lingtai + 66 lingtai-kernel); classification summary below (sources: PROPOSAL_INDEX.md / PR_CLASSIFICATION.md):

Action	Count	Description
PR	50	Each PR maps one-to-one to an issue; includes 4 lingtai repo PRs (#821–#824) and 46 lingtai-kernel PRs (#1253–#1299); #1269/#1279/#1283/#1298 are cross-repo PRs “filed on lingtai, implemented in kernel”.
COMMENT	39	17 kernel + 22 lingtai; mostly wrong-repo filings (route-to-kernel), owner decisions needed, already covered by an active lane (overlap-tracker), or fixed awaiting confirmation (fixed-confirm).
CLOSE	14	7 kernel + 7 lingtai; all are “already fixed on main / superseded / owner adjudicated”.

2.1 50 PR Proposals (grouped by 11 theme buckets)

Bucket	PR	Issue	One-line topic
1 · AED/recovery/lifecycle (10)	#1270	kernel-713	AED zero-progress compaction caused a zombie state (11 days / 1,458 overflows / 34.9M tokens); adds a zero-progress guard.
1 · AED/recovery/lifecycle (10)	#1293	kernel-653	Overflow recovery permanently deletes history on terminal-state failure; adds a prompt / no-delete guard.
1 · AED/recovery/lifecycle (10)	#1295	kernel-655	AED loop error handling for `_save_chat_history`/`_run_inquiry` is asymmetric; wraps the turn tail.
1 · AED/recovery/lifecycle (10)	#1259	kernel-738	llm_utils watchdog misjudges worker TimeoutError as “future not done” → false alarm + log storm.
1 · AED/recovery/lifecycle (10)	#1294	kernel-660	Heartbeat loop lacks a top-level exception guard; transient I/O errors silently kill live threads (split-brain).
1 · AED/recovery/lifecycle (10)	#1291	kernel-730	kernel_version nudge synchronously fetches PyPI/GitHub, blocking the 1s heartbeat past the liveness threshold.
1 · AED/recovery/lifecycle (10)	#1262	kernel-661	`_stop` teardown is not robust; unwrapped steps can permanently deadlock `.agent.lock`.
1 · AED/recovery/lifecycle (10)	#1299	kernel-593	LLM 429 has no backoff / Retry-After retry, 400 retried as-is; transient-error classification + backoff.
1 · AED/recovery/lifecycle (10)	#1264	kernel-1013	Stateless Responses replay can overflow after /clear — context estimation misses metadata.
1 · AED/recovery/lifecycle (10)	#1269	lingtai-624 → kernel	Concurrent refresh spawns duplicate relaunch watchers that deadlock each other and exhaust recovery.
2 · notification sync/taskcard (4)	#1253	kernel-657	Notification sync errors are silently swallowed by `except Exception: pass`; adds observability.
2 · notification sync/taskcard (4)	#1287	kernel-659	`_sync_notifications` TOCTOU race — missing `_system_notification_lock` between the run loop and heartbeat.
2 · notification sync/taskcard (4)	#1278	kernel-742	Agent and refresh watcher race reading/writing `.notification/system.json` across processes.
2 · notification sync/taskcard (4)	#1273	kernel-987	Telegram Task Card self-healing requires loaded-runtime drift diagnosis first.
3 · LLM adapter layer (6)	#1254	kernel-1238	ClaudeCodeChatSession crashes with `tools=None`; fixes 3 contract tests.
3 · LLM adapter layer (6)	#1277	kernel-724	`_GatedSession` proxy swallows attribute writes — pre_request_hook/metadata never reach the inner session.
3 · LLM adapter layer (6)	#1272	kernel-739	`get_adapter` fast path iterates the adapter cache without a lock → dict changed-size race.
3 · LLM adapter layer (6)	#1279	lingtai-750 → kernel	Detached daemon loses nested provider defaults; Responses provider is misrouted to Chat Completions.
3 · LLM adapter layer (6)	#1261	kernel-746	`SystemPromptManager.set_order()` is a silent no-op — the rendering path ignores `self._order`.
3 · LLM adapter layer (6)	#1263	kernel-744	Templates with literal braces plus kwargs make `t()` raise ValueError (format_map leak).
4 · MCP/tool family shell (3)	#1292	kernel-1251	`ToolFamily.handle()` rejects whole calls because action-specific fields (e.g. file.edit's replace_all) sit at the envelope root.
4 · MCP/tool family shell (3)	#1296	kernel-1237	Telegram send/edit rejects the model's own null values; `_reasoning` leaks into third-party MCP tools.
4 · MCP/tool family shell (3)	#1265	kernel-740	HTTPMCPClient lacks the stale-session recovery and blank-error formatting that MCPClient already has.
5 · messaging plugins/filesystem mail (7)	#1266	kernel-715	Unread counts never clear — Telegram counts the bot's own replies as unread; both plugins lack mark_read/watermark.
5 · messaging plugins/filesystem mail (7)	#1271	kernel-733	WhatsApp `ingest_webhook` has no replay/dedup guard → Meta retries create duplicate inbox entries.
5 · messaging plugins/filesystem mail (7)	#1258	kernel-675	`MailService.listen()` is not idempotent — a second call starts a second polling thread; the RuntimeError guard in lifecycle.py is dead code.
5 · messaging plugins/filesystem mail (7)	#1280	kernel-1063	A corrupt outbox file crashes the polling loop; persistence sleeps automatically after recovering the corruption.
5 · messaging plugins/filesystem mail (7)	#1281	kernel-732	The FS mail poller permanently and silently drops messages whose message.json fails to read/parse.
5 · messaging plugins/filesystem mail (7)	#1286	kernel-731	`FilesystemMailService.send()` attachment failures leave orphaned partial inbox directories.
5 · messaging plugins/filesystem mail (7)	#1274	kernel-766	FS mail `_seen` grows unbounded; the polling loop re-scans all history entries every 0.5s.
6 · security/redaction/token hygiene (5)	#1260	kernel-626	Overflow artifacts store unredacted tool results in `<workdir>/tmp/tool-results/` — a redaction gap.
6 · security/redaction/token hygiene (5)	#1289	kernel-631	MCP outbound attachments/media can leak arbitrary local files (no workdir constraint).
6 · security/redaction/token hygiene (5)	#1298	lingtai-680 → kernel	The Telegram plugin logs unredacted Bot API tokens in httpx request URLs.
6 · security/redaction/token hygiene (5)	#1283	lingtai-812 → kernel	Telegram Bot API tokens leak into MCP stderr and refresh event logs.
6 · security/redaction/token hygiene (5)	#823	lingtai-568 → lingtai PR	Channel example configs are open by default, contradicting the README security statement (docs/examples only).
7 · config/schema/data format (8)	#1284	kernel-736	schema/hydration drift: `build_agent_config` accepts manifest fields but `validate_init` reports them unknown and never type-checks.
7 · config/schema/data format (8)	#1282	kernel-737	`_check_type` accepts bool for tuple-typed int fields — `context_limit: true` becomes a 1-token window.
7 · config/schema/data format (8)	#1290	kernel-725	`load_jsonc` trailing-comma stripping corrupts string values containing `", ]"`/`", }"`.
7 · config/schema/data format (8)	#1276	kernel-759	Hardens `load_env_file`/`resolve_env`: export prefix, quote stripping, silently missing api_key_env.
7 · config/schema/data format (8)	#1256	kernel-741	When a preset's base_url lacks a URL scheme, `check_connectivity` silently probes localhost.
7 · config/schema/data format (8)	#1285	kernel-763	Consolidates the scattered 2.0/3.0/10.0 heartbeat liveness thresholds into kernel constants.
7 · config/schema/data format (8)	#1255	kernel-750	`AgentSession.started_at` format varies with the rebuild layer (ISO-8601 vs bare epoch strings).
7 · config/schema/data format (8)	#1257	kernel-729	Retention reports treat UTC “Z” timestamps as local time; daemon ages skew by the host timezone.
8 · atomic writes/fsutil persistence (2)	#1288	kernel-756	Completes the `_fsutil` migration for remaining fixed-tempname atomic writers (manifest, soul init.json, mail writes).
8 · atomic writes/fsutil persistence (2)	#822	lingtai-482 → lingtai PR	Go TUI writes init.json/.agent.json non-atomically; config corruption risk on crash.
9 · provisioning/logging/ops (2)	#1267	kernel-758	`venv_resolve` auto-provisioning installs an unpinned `pip install lingtai` → version skew.
9 · provisioning/logging/ops (2)	#1275	kernel-765	File logging is dead code — `setup_logging()` is never called; diagnostic logs are lost.
10 · docs/manual (1)	#1268	kernel-344	Improves discoverability of the log.sqlite query manual (docs only).
11 · TUI/portal (lingtai repo) (2)	#821	lingtai-487 → lingtai PR	TUI agent startup leaks the parent-side agent.log file descriptor.
11 · TUI/portal (lingtai repo) (2)	#824	lingtai-671 → lingtai PR	Curated stdio MCP loses parent-agent variables; the 10s startup watchdog misreports slow startups.

2.2 14 CLOSE Proposals

Issue	Close reason (one line)
kernel-613	TC-wake path 400/429 fully fixed on main (unpaired tool_calls / same-role run resolved).
kernel-710	Provider 429 cascades superseded by owner decision — a five-point contract was adjudicated in-thread; PR #701 closed unmerged.
kernel-712	Tool result byte limits: both load-bearing suggestions already implemented on current main.
kernel-714	Symptom report against a superseded kernel — soul fire on main no longer drives the wake/injection path.
kernel-718	Part 1 fixed by the persisted tool-result replay mechanism (PR #297, f02dd0dd) and wired into every ChatInterface.
kernel-728	Write-path defect fixed by PR #966 (init.jsonc normalization, commit 92eeaaff).
kernel-754	Race unreachable — `run_agent_migrations` removed from the boot/refresh path (92eeaaff).
lingtai-223	All five suggested mitigations landed on the code-owning lingtai-kernel main.
lingtai-565	Tape rebuild/reconstruction no longer rewrites .portal files without TopologyMu (current main).
lingtai-619	Core fixed on main (max/ultra accepted with clear errors; omitted Codex thinking normalized to xhigh).
lingtai-643	MallocStackLogging warning flood fixed on main (root cause located by TZZheng).
lingtai-725	Official kernel update path is live — the confirm-gated `/update` checks the managed venv.
lingtai-771	Dangling native references left by GUI-created presets fixed on current main.
lingtai-784	Both deterministic preconditions (oversized palette frame, Bubbles virtual cursor) fixed on main.

2.3 39 COMMENT Proposals (classified summary)

COMMENT-ROUTE (7, wrong-repo filings to route to kernel): lingtai#419, #434, #672, #674, #767, #789, #792
COMMENT-FIXED (1, implemented in kernel, awaiting re-verification): lingtai#756 (empty-response recovery implemented in kernel with regression tests; re-verify after upgrading to ≥0.19.x)
COMMENT-OVERLAP (5, active owner lanes already exist): lingtai#641 (merged into #783), lingtai#694 (kernel#1096), lingtai#791 (kernel#1194), kernel#1197 (author has 5 PRs), kernel#727 (rewrite PR #1178)
COMMENT-OWNER (16, owner/product decisions needed): lingtai#363/#471/#666/#702/#783/#802; kernel#1060/#1170/#258/#269/#632/#716/#734/#749/#767/#794
COMMENT-OTHER (1): kernel#664 — a real race defect with the fix ready, but this run's shell tool failure blocked the PR path; awaiting a follow-up PR (Fixes #664)
The remaining 10 are lingtai repo COMMENT items (144/363/429/431 etc., fixed awaiting confirmation or needing reporter info).

3. Subagent Token Usage (taskcard data)

Per Jason 2208's requirement, Task Card shows the token usage of subagents (daemons), not the parent agent. Taskcard aggregate for this round of 103 concurrent daemons:

≈260M

Input tokens (in)

≈254M

Cache hits (cached)

≈3.9M

Output tokens (out)

Independent cross-check (token ledger + each daemon's token metadata): this batch of 106 daemon runs (103 issues + 3 catch-up/re-dispatches) totals ≈283M input, ≈276M cached, ≈4.1M output + ≈1.9M thinking — same order of magnitude as the taskcard snapshot; the parent-session snapshot (02:14Z) shows 14.4M in / 13.8M cached. Cache hit rate is about 97–98%; batch parallelism yields significant context-cache savings.

4. Failure Analysis (4 failures, all recovered)

Of the 103+ daemon runs, 4 did not close out per contract; each was verified individually (each daemon's run logs):

Issue	Original daemon	Failure type	Elapsed	Recovery
lingtai#672	em-e708	max_turns exhausted (`max_turns exhausted before the daemon completed its tool chain`)	1019s (02:27Z)	proposal.md was written before the failure (COMMENT-ROUTE action); deliverables complete.
kernel#655	em-5faf	max_turns exhausted	1232s (02:32Z)	Re-dispatched em-c93c to complete: pushed branch `fix/issue-655-dev4-20260809`, opened PR #1295 (50 tests passing).
kernel#1237	em-b86d	max_turns exhausted	1742s (02:40Z)	Re-dispatched em-0ee9 to complete: pushed the existing branch `fix/issue-1237-dev4-20260809` (04b79c47), opened PR #1296.
kernel#713	em-6417	missing finish signal (`missing completion MCP finish signal`; terminal text: “test suite still running, waiting for wake”)	493s (02:20Z)	proposal.md + pr_body.md were written before the contract failure; deliverables complete.

Conclusion: all 4 failures were daemon lifecycle/contract issues (3× max_turns, 1× finish contract); none was a model-capability or data issue; all were recovered via “re-dispatched daemon” or “already on disk before failure”, ending at 103/103 proposals complete, with 2 failed issues closed out as PRs (#1295/#1296).

5. 429 / Rate-Limit Evidence Audit

A dedicated audit was run on whether the 103 concurrent daemons triggered heavy rate limiting:

11 daemon directories show rate-limit-related text in their event logs (keywords like retry_after / RateLimitError / usage_limit_reached / “rate limit”), but none failed because of it — all 4 failures were max_turns / finish contract issues, unrelated to rate limiting.
In the main run logs: 91 HTTP 429-related entries and 1,947 retry_after occurrences (cumulative history including long-running operation since July; many retry_after entries come from Telegram Bot API rate-limit handling code discussion/implementation records, not a live 429 flood from this batch of 103 daemons).

Note: the main-log counts are cumulative historical figures (all daemons since 7-16), with no direct causal link to this batch; no rate-limit-caused failures were seen during this batch's 103 daemons' live runs. A few hard issues (e.g. kernel#664's PR path) were blocked by shell tool failures and are recorded in COMMENT for follow-up.

6. The 23 Closed Issues (as of report time)

Executed under Jason's authorization (Telegram 2248 / 2258) and verified one by one (actor=huangzesen, state=open before closing, fresh GET re-checked closed after):

CLOSE proposals executed

fixed-unconfirmed closed

closed with repro evidence

Total closed

6.1 CLOSE execution (14/14 successful, close-execution-receipt.md)

lingtai: #223, #565, #619, #643, #725, #771, #784; kernel: #613, #710, #712, #714, #718, #728, #754. Each has a closing-reason comment attached (e.g. issuecomment-5229807013).

6.2 fixed-but-unconfirmed closed (6/6 successful, fixed-close-execution-receipt.md)

lingtai: #144, #429; kernel: #193, #195, #422, #717. Each first posts a status comment (proposal-suggested comment + reporter confirmation/closing note), then closes.

6.3 closed with repro evidence (3/3 successful, repro-close-execution-receipt.md)

lingtai: #431 (Codex login state), #753 (ASLEEP won't wake), #754 (stale recovery prompt replay). All COMMENT + CLOSE, verified state_reason=completed.

7. Fable Audit Progress

Per Jason 2194's “5 PRs per batch” instruction, Fable audits were dispatched (lingtai #821–#824 + kernel #1253–#1291 etc., 41 PRs split into batches 1–9, report path fable-audit-batch-<N>.md). As of this report:

Batch	PRs audited	Verdict
Batch 1	First 5 PRs	1 APPROVE + 4 REQUEST CHANGES
Batch 2	#1254 #1255 #1256 #1257 #1258	1 APPROVE (#1254, 223 tests passing, closes #1238) + 4 REQUEST CHANGES (#1255 sqlite bad ts not handled; #1256 malformed IPv6 aborts the whole table + unsupported scheme still probes port 80; #1257 timezone tests leak libc TZ state; #1258 listen concurrency check non-atomic + contract not synced), P0 0 / P1 2 / P2 4

Progress: batches 1–2 done (2 APPROVE + 8 REQUEST CHANGES, 10/50 audited); batch 2's full audit report is archived in the Fable audit batch 2 attachments (identity/source check: authors and committers of all audited PRs are Huang Zesen <hzsbazinga@outlook.com>, GitHub-side actors are all huangzesen, no identity mismatch; the audit was read-only, no GitHub changes made). REQUEST CHANGES items will be handled via follow-up patches/tracking.

8. Squash-first Merge Strategy

The 50 PRs are grouped into 11 buckets by theme (PR_CLASSIFICATION.md); the core strategy is “plan merge batches by file-conflict surface first, then merge batch by batch”. Key points:

Bucket 1 (AED/recovery/lifecycle, 10): highest same-file density in the batch (#1270/#1295/#1299 all touch base_agent/turn.py; #1294/#1291/#1262 all touch base_agent/lifecycle.py). Do not merge into one giant PR; land in 3 sub-clusters: (a) turn.py AED: #1299 → #1270 → #1295; (b) overflow/replay: #1264 → #1293; (c) lifecycle.py: #1294 → #1291 → #1262 (guard first, then de-risk threads, then teardown); #1269 rides with (c) or lands independently.
Bucket 2 (notification sync, 4): #1253/#1287/#1278 are the same “notification sync hardening” sub-system cluster, safe to stack/squash (#1287 → #1278 → #1253); #1273 is independent.
Bucket 3 (LLM adapter layer, 6): #1254/#1277/#1272 can be squashed into “LLM session/adapter correctness” (note #1272/#1277 both near llm/); #1261/#1263 are small and independent, mergeable; #1279 is independent.
Bucket 4 (MCP/tool family, 3): three independent files, safe to squash or land separately; #1296 and bucket 5's #1266 both touch telegram/manager.py — merge #1266 first or create on the same base.
Bucket 5 (messaging/FS mail, 7): #1258/#1280/#1281/#1286/#1274 are all in the same file (posix/mail.py); do not blindly squash — run serially as one review batch: #1258 → #1274 → #1281 → #1280 → #1286; #1266/#1271 are different plugin files and can go independently.
Bucket 6 (security/redaction, 5): #1298/#1283 are nearly identical Telegram token redaction surfaces; treat as one change (source redaction first, then log pipeline) or combine into one “telegram token redaction” PR; #1260/#1289 can be merged; #823 is a lingtai repo docs PR and must stay away from kernel squash.
Bucket 7 (config/schema, 8): #1284/#1282 merge into “manifest validation/hydration alignment”; #1290/#1276/#1256 merge into “config parsing hardening”; #1257 before #1285 (both touch maintenance/retention.py); #1255 is fully independent.
Bucket 8 (atomic writes, 2): #1288 is a kernel-wide migration overlapping bucket 5's mail.py — keep independent and land late; #822 is a lingtai (Go) repo PR that cannot merge with kernel.
Bucket 9 (ops/logs, 2): #1267/#1275 are independent files; merge into “ops hardening” or land separately.
Bucket 10 (docs, 1): #1268 is docs-only with zero runtime risk; can merge anytime.
Bucket 11 (TUI/portal, 2): #821/#824 both touch Go TUI startup internals; merge or land in order (#821 first); must be fully separated from all kernel squash.

9. Methodology

Model: deepseek (Jason 2194 designated “current default model”, recorded in the daemon ledger as deepseek-v4-flash @ opencode.ai/zen/go/v1), used for writing PRs and all triage analysis

Canonical identity: GitHub actor = huangzesen (verified via gh api user --jq .login before every gh operation); git author+committer = Huang Zesen <hzsbazinga@outlook.com>

Isolated gh context: all gh/git operations run with export GH_CONFIG_DIR="$HOME/.config/gh-huangzesen"; never gh auth switch, never touches shared/global git/auth config

Isolated checkout: each issue gets an independent fresh clone at issue-<N>/kernel; never touches shared worktrees

Current-main verification: every proposal is verified against origin/main HEAD (df2b523d) for fixed/reproducible, with evidence down to file/line

Owner/overlap protection: when an active PR/lane exists, COMMENT points to the owner; never opens duplicate PRs

Audit cadence: Fable does read-only audits of 5 PRs per batch; close/comment/merge authority belongs to parent/Jason; sub-daemons only open their own PRs

Data sources: per-issue proposal records (PR_LIST · PROPOSAL_INDEX · PR_CLASSIFICATION · comment-decision-list · close execution receipts) · daemon run records · token ledger · Fable audit reports.
This report is published by huangzesen.github.io (added subdirectory 103-agent-parallel-20260809/; only added files, no existing repo content modified). Generated: 2026-08-09 UTC.