Track: feature work toward making the Telegram bot the full control plane for recursive sessions, chip creation, and autoloops. Items move Next -> In Progress -> Green-lit only after live Telegram testing.
Companion to task.md (memory methodology plan). Different scope - do not merge.
Started: 2026-04-23
-
scripts/boot-spark.sh- detect port conflicts, launch spawner-ui (:4174), telegram-bot (polling). Health-gated. -
scripts/kill-spark.sh- clean teardown -
task-telegram-agent.mdcommitted (0f516b5) - Green signal: spawner-ui REST verified, mission ran end-to-end Z.AI+MiniMax in <25s, Telegram round-trip confirmed (msg 680 sent, user reply received on bot side)
- KNOWN GAP: Spark Builder gateway not in boot script yet - will add before Phase 1 text tests
- P9 fix: short-circuit in
adapters/telegram/runtime.py- detect_instruction_intent runs BEFORE bridge; matched messages skip chip routing, produce instruction ack directly - P7 fix: wrap
evaluate_swarm_escalationincapability_router/service.pytry/except - any failure (timeout, URLError, None api_url) degrades toswarm_decision(mode="unavailable", escalate=False)instead of killing the turn - Green signal: Live Telegram tests pass. P9 routes to
user_instruction_shortcircuitwith ack. P7 routes toprovider_fallback_chat+manual_recommendedwithoutbridge_error.
- Builder CLI:
spark-intelligence chips create --prompt ...(commit 19008ec) - Brief parser: LLM (Z.AI GLM 5.1) turns prompt -> strict JSON brief with router fields
- Scaffolder delegation: chip_labs.chip_factory.scaffold_chip
- Manifest patched with chip_name + task_topics + task_keywords + combine_with
- add_attachment_root -> snapshot -> pin_chip -> snapshot -> router_invokable verified
- spark-telegram-bot /chip create handler (commit 4030ee2) shells out to builder CLI
- Green signal: live Telegram
/chip create a chip for brand-sentiment-tracking ...produceddomain-chip-brand-sentiment-trackingat Desktop, router_invokable=yes, in ~45s - DEFERRED: spawner-ui REST endpoint (bot shells Python directly; simpler and works)
- DEFERRED: H70-C+ validator integration (chip contract is different from skills contract; not blocking)
- DEFERRED: mission-relay progress events for chip-creation (single-shot is fine for now)
Plumbing: Telegram /loop -> builder CLI -> run_chip_hook (suggest then evaluate per round) -> status JSON -> Telegram reply.
- spark-researcher
autoloopCLI investigated - broken against its own committed chips (schema drift); pivoted to lightweight in-builder runner. - Builder loops/ module with run_chip_autoloop()
-
spark-intelligence loops run --chip <key> --rounds N - spark-telegram-bot
/loop <chip_key> [rounds]command - Green signal: live Telegram
/loop startup-yc 2returned "Rounds 2/2" with per-round summary; status file written. - POLISH: scaffolded-chip lab_hooks import fixed via
_patch_generated_cli(rewrites relative -> absolute import and prepends sys.path shim for chip_labs/src) - POLISH: extractor generalized to mine real metrics from any chip's evaluate output (lab_research_quality_score, portfolio_health, or first scalar); pulls status from verdict/comparison_class/etc
- POLISH: Telegraf 90s handler timeout bypassed - /loop detaches, bot acks immediately, posts summary when done
- Final polish verification: /loop domain-chip-brand-sentiment-tracking 2 returned "candidates=3 best_verdict=benchmark_grounded best_metric=0.773" on both rounds
- spawner-ui: persistent schedule store in
.spawner/schedules.json - spawner-ui:
GET/POST/DELETE /api/scheduledendpoints - Scheduler worker (30s tick via croner) fires mission (POST /api/spark/run) or loop (builder CLI)
- Telegram relay: direct Bot API sendMessage on each fire; reads token via
$env/dynamic/private - spark-telegram-bot:
/schedule "<cron>" mission <goal>//schedule "<cron>" loop <chip> [rounds]//schedules//schedules delete <id> - Green signal: live fire sent msg_id 714 from Spark AGI to user with
[sched sched-f359fe87] loop ok - DEFERRED: Kanban Scheduled tab UI - still placeholder, but backend is live; UI can come later
- LESSONS LEARNED:
- Test schedule at large intervals only (≥60m) unless you want to burn tokens; mission action fires real /api/spark/run
- Clean up test schedules immediately after verification
- chips can declare
recursion_contract, missions reference chip viachip_ref - Telegram
/loop <goal> --iterations Nsugar on top of/run - Plain-text mission-intent auto-route (builder suggests
/runwhen user describes a recursive task conversationally)
-
/chip createscaffoldeddomain-chip-spark-ops-critic(commit 33006e2 fixed scaffolder .cli suffix bug surfaced by this track) - First /loop run: generic scaffolded hooks returned portfolio-audit metric, not real self-critic signal
- Replaced cli.py with hand-written evaluate/suggest that read schedules.json, loop status files, mission-control.json, bot log (commit 0892c0e)
- /loop domain-chip-spark-ops-critic: verdict=critical, defect_rate=0.687, surfaced real findings including the already-tracked startup-yc cold-start bug
- B remediation: loop runner now bootstraps a probe candidate when suggest returns empty on cold state (commit ffcfefa)
- /loop startup-yc post-fix: candidates 0 -> 1, null_metric -> 1.000
- Compound loop closed: /loop domain-chip-spark-ops-critic post-fix returned verdict=healthy, defect_rate=0.020 (was 0.687)
- A scheduling: nightly 03:00 local cron DMs the defect brief to the configured operator chat
- One live Telegram send/receive test via
sendMessage+ bot reply - One direct REST probe of the underlying API
- A committed change with descriptive message