Command-triggered research: orchestrator researches and updates its own knowledge before working

Open
  • Is something wrong?
#39 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 6 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
8/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, sqlite
Domain
ai-infra-agents

Research direction

This is a design-level feature touching the planner agent in bundle/agents/orchestra-planner.md, the prompt hook bundle/hooks/orchestra-prompt.js (memory injection around lines 279-280), and the memory modules under bundle/hooks/lib/. Start by reading the planner's step 3b and how buildMemoryContext is called, then decide the trigger and cache design with maintainers. Done would mean a ## Research block with cited sources in the plan, cache hits on repeat runs, and enforced budget limits, all covered by tests.

Written by the indexing model from the issue text.

Description

enhancement good first issue research

Summary

Add an opt-in/opt-out research step so that, when the user triggers it (a command such as /orchestra research ..., or a flag on the normal prompt), the orchestrator researches current best practices, tools and approaches before planning, records what it learned with citations, and reuses it later through the existing memory layer.

Motivation

Agents plan from training data. Today the planner only does web lookups in one narrow case ("3b" in bundle/agents/orchestra-planner.md: confirm latest stable version of a new library). There is no general "update your own knowledge first" step, no citation trail, and no reuse of what was found.

Current code this builds on

  • bundle/agents/orchestra-planner.md — step 3b (conditional websearch/webfetch for versions); planner has WebFetch, WebSearch tools.
  • bundle/hooks/orchestra-prompt.js:279-280 — memory context is already injected before planning (buildMemoryContext(ltm, { query: goal || prompt })).
  • bundle/hooks/lib/memory-manager.js, memory-index.js, memory-fts.js, semantic-memory.js — long-term memory / recall (FTS5 when Node ≥ 22.5).
  • bundle/hooks/lib/prompt-classifier.js — prompt classification and opt-out detection ("no orchestra …").
  • bundle/hooks/lib/token-tracker.js — per-phase budgets (planner 10k, cycle 63k) the research step must respect.
  • bundle/hooks/lib/plan-artifact.js — plan artifact where citations can be recorded before PLAN_READY.

Proposed design

  1. Trigger: command/flag (e.g. /orchestra research <goal> or --research) plus an optional config default in project.yaml (orchestra.research: off|on|auto). Opt-out: no research phrase / orchestra.research: off / env PCORE_RESEARCH=0.
  2. Where: a research sub-step inside the planner stage, before PLAN_READY. It may run as a short read-only research phase using the existing WebSearch/WebFetch tools.
  3. Output: a ## Research block in the plan with: question, findings (3–7 bullets), sources/citations (URL + retrieval date), decisions it changed ("chose X over Y because …"), and confidence.
  4. Caching: store findings in the existing memory layer (keyed by topic + date + source URLs) so repeated runs recall instead of re-search; add TTL (e.g. 14 days) and a --refresh override.
  5. Limits: wall-clock and token budget (e.g. max N searches / M fetches / K tokens, configurable); on budget exhaustion, plan continues and notes "research truncated".
  6. Safety: treat fetched content as untrusted data (no instructions followed from pages); allow-list or deny-list of domains in config.
  7. Host feasibility: Cursor/Claude Code/Qoder — hook-driven; OpenCode and Codex — conductor-driven (agent instruction only, no hook). Host without web tools → skip with a clear message.

Must-have baseline

When the project type is recognised, the planner must generate a checklist of baseline features and the verifier must check items off (or record why they are N/A). Research should refine this checklist with current best practices (e.g. current payment/auth recommendations).

Online shop
  • Basic auth: sign up, login, logout, password reset
  • Product listing and product detail view
  • Search and filter
  • Cart: add/remove items, item check-in (quantity/stock check)
  • Checkout and payment
  • Order confirmation and order history
  • Admin to manage items (create/edit/delete products, stock)
General website
  • Header with navigation; footer
  • Hero section and call-to-action (CTA)
  • Roadmap section
  • About page; contact page (form)
  • Terms and conditions; privacy policy
  • 404 page
  • Responsive / mobile layout
  • SEO meta tags + sitemap; favicon
  • Accessibility basics (landmarks, alt text, contrast, keyboard focus)
  • Cookie notice where relevant
  • Analytics hook

(Existing related pieces: bundle/hooks/lib/greenfield-intake.js / greenfield-scaffold.js and the project-type classifier agent bundle/agents/00-workflow/project-type-classifier.md can supply the project type.)

Acceptance criteria

  • Research can be triggered by a command/flag and disabled by an opt-out (documented in README + docs/).
  • Plan contains a ## Research section with citations (URL + date) and the decisions it influenced.
  • Findings are cached via the memory layer and re-used; TTL and --refresh work.
  • Time/search/token limits are enforced and tested (including truncation message).
  • Planner generates a per-project-type baseline checklist (online shop, general website at minimum) and the verifier checks items off or marks N/A; unchecked required items → VERIFY_FAIL.
  • Behaviour per host documented (Cursor, OpenCode, Qoder, Claude Code, Codex), including hosts without web tools.
  • Tests cover trigger parsing, opt-out, cache hit/miss, budget cutoff, and the checklist generator.

Related

Part of the "Conversational orchestrator" epic (linked below once created).

Raised from the v3.8.0 audit (commit 22d2146).

Part of epic #44 (Conversational orchestrator).

Dominant language
JavaScript
Stars
0
Forks
0
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from P-Core-System/pcore-orchestra

All issues in P-Core-System/pcore-orchestra

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.