Skip to content

Latest commit

 

History

History
99 lines (77 loc) · 6.33 KB

File metadata and controls

99 lines (77 loc) · 6.33 KB

Telegram-Native Recursive Agent

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


Phase 0 - Boot ritual + tracking [GREEN 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.md committed (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

Phase 1 - Urgent defects [GREEN 2026-04-23]

  • 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_escalation in capability_router/service.py try/except - any failure (timeout, URLError, None api_url) degrades to swarm_decision(mode="unavailable", escalate=False) instead of killing the turn
  • Green signal: Live Telegram tests pass. P9 routes to user_instruction_shortcircuit with ack. P7 routes to provider_fallback_chat+manual_recommended without bridge_error.

Phase 2 - /chip create from Telegram [GREEN 2026-04-23]

  • 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 ... produced domain-chip-brand-sentiment-tracking at 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)

Phase 3A - Autoloops (recursive self-improving loops) [GREEN 2026-04-23]

Plumbing: Telegram /loop -> builder CLI -> run_chip_hook (suggest then evaluate per round) -> status JSON -> Telegram reply.

  • spark-researcher autoloop CLI 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 2 returned "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

Phase 3B - Scheduler (cron-style recurring triggers) [GREEN 2026-04-23]

  • spawner-ui: persistent schedule store in .spawner/schedules.json
  • spawner-ui: GET/POST/DELETE /api/scheduled endpoints
  • 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

Phase 4 - Stretch (only if time remains)

  • chips can declare recursion_contract, missions reference chip via chip_ref
  • Telegram /loop <goal> --iterations N sugar on top of /run
  • Plain-text mission-intent auto-route (builder suggests /run when user describes a recursive task conversationally)

Track C - Self-observability chip (real-world run) [GREEN 2026-04-23]

  • /chip create scaffolded domain-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

Test discipline (every green signal)

  1. One live Telegram send/receive test via sendMessage + bot reply
  2. One direct REST probe of the underlying API
  3. A committed change with descriptive message