feat(utp): implement Universal Transpilation Protocol as callable-agent pipeline#39
feat(utp): implement Universal Transpilation Protocol as callable-agent pipeline#39
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: db67a9f11d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const result = await this.options.llm.generate([ | ||
| { role: 'system', content: injectedPrompt }, | ||
| { role: 'user', content: input }, |
There was a problem hiding this comment.
Include per-agent instructions in the system prompt
BaseAgentOptions.instructions is never used when building the LLM prompt, so any agent-specific behavior/config passed at construction time is silently ignored. In run, the system message only contains injectMemoryContext(), which means all agents effectively run with the same generic prompt and can miss required constraints/tool policies; this will surface whenever two agents are expected to behave differently via their instructions.
Useful? React with 👍 / 👎.
| return; | ||
| } | ||
|
|
||
| const sourceIds = snapshot.shortTerm.map((message) => message.id); | ||
| await this.memory.observe(sourceIds); |
There was a problem hiding this comment.
Avoid re-observing unchanged context on every poll
After the short-term token budget first crosses OBSERVER_TOKEN_THRESHOLD, every subsequent poll triggers memory.observe again with the same message window because there is no "last observed" cursor or dedup check. In an idle conversation that remains above threshold, this causes repeated LLM calls every OBSERVER_POLL_MS (default 2s), creating duplicate observations and unnecessary cost/load.
Useful? React with 👍 / 👎.
| const output = await context.with(trace.setSpan(context.active(), span), () => fn(span)); | ||
| span.setStatus({ code: SpanStatusCode.OK }); | ||
| return output; |
There was a problem hiding this comment.
Set span status from Result failures, not only thrown errors
withSpan unconditionally marks spans as OK whenever fn resolves, but many call sites resolve to Result.err rather than throwing (e.g., LLM/tool wrappers). That means failed operations are exported as successful spans, which undermines telemetry-based debugging/alerts in exactly the scenarios where the operation failed without an exception.
Useful? React with 👍 / 👎.
Motivation
Description
src/utp/with phasesStructural_Analyst,Abstract_Specifier,Domain_Specialist,Variance_Detector, aCallableAgenttype, andUtpOrchestratorthat composes them and returns the five required sections.src/utp/types.ts, an entrypoint that runs the orchestrator (src/main.ts), and README documentation describing the contract and run commands.prd.json,progress.txt,loop/log.txt) to markDECIDE-003complete and committed the changes.Testing
bash scripts/ralph/loop.sh, which reported success (passed).bash scripts/ralph/radius.sh loop/log.txt 50 && bash scripts/ralph/loop.sh, which reported success (passed).[OK] pre-commit passedentries inloop/log.txt).pnpm install/pnpm devto run TypeScript build and runtime, butpnpm installcould not be completed due to an environment network/proxy restriction (network failure), so runtime execution and full typecheck were not completed in this environment.Codex Task