|
| 1 | +# CLI Harness Design |
| 2 | + |
| 3 | +`context-profiler` is a trace-source agnostic context analysis harness for LLM agents. |
| 4 | + |
| 5 | +The CLI is designed for two users at once: |
| 6 | + |
| 7 | +- humans who want a readable report |
| 8 | +- coding agents that need discoverable commands, JSON contracts, and actionable validation errors |
| 9 | + |
| 10 | +## Product Boundary |
| 11 | + |
| 12 | +`context-profiler` analyzes traces. It does not fetch them. |
| 13 | + |
| 14 | +Good upstream sources include: |
| 15 | + |
| 16 | +- Langfuse CLI or API exports |
| 17 | +- OpenTelemetry / OpenInference span exports |
| 18 | +- raw OpenAI or Anthropic request logs |
| 19 | +- Cursor or Claude Code local transcripts |
| 20 | +- academic trajectory datasets |
| 21 | + |
| 22 | +The agent or user brings the data. `context-profiler` validates, normalizes, diagnoses, and reports. |
| 23 | + |
| 24 | +## Command Model |
| 25 | + |
| 26 | +The CLI follows a discover/validate/analyze flow: |
| 27 | + |
| 28 | +```bash |
| 29 | +context-profiler formats list --json |
| 30 | +context-profiler formats describe <format> --json |
| 31 | + |
| 32 | +context-profiler schema trace --json |
| 33 | +context-profiler schema diagnosis --json |
| 34 | + |
| 35 | +context-profiler validate <file|-> --format auto --json |
| 36 | +context-profiler normalize <file|-> --from auto --json |
| 37 | + |
| 38 | +context-profiler diagnose <file|-> --format auto --json |
| 39 | +context-profiler analyze <file|-> --format auto --html report.html |
| 40 | +``` |
| 41 | + |
| 42 | +The style is inspired by mature agent-friendly CLIs: |
| 43 | + |
| 44 | +- Langfuse CLI: schema-driven API access |
| 45 | +- kubectl: resource discovery and explainability |
| 46 | +- Terraform: validate/plan-style machine output |
| 47 | +- GitHub CLI: human commands plus machine-readable JSON |
| 48 | +- Repomix: AI-context oriented CLI and MCP distribution |
| 49 | + |
| 50 | +## Input Kinds |
| 51 | + |
| 52 | +Every format is classified by input kind and confidence. |
| 53 | + |
| 54 | +| Input kind | Examples | Confidence | |
| 55 | +| --- | --- | --- | |
| 56 | +| `provider-request` | OpenAI, Anthropic | exact | |
| 57 | +| `observability-trace` | Langfuse, OTel/OpenInference | high | |
| 58 | +| `agent-transcript` | Cursor JSONL, Claude Code JSONL | partial | |
| 59 | +| `benchmark-trajectory` | agent-trace, agent_trajectories, SWE-agent | dataset-dependent | |
| 60 | + |
| 61 | +`agent-transcript` inputs are useful for visible loop analysis but are not exact raw provider requests. They may omit hidden prompts, tool definitions, rules, MCP schemas, and provider-side compaction. |
| 62 | + |
| 63 | +## Validation Contract |
| 64 | + |
| 65 | +Validation should be strict but helpful. |
| 66 | + |
| 67 | +Unknown input should not be silently guessed. Instead, `validate --json` returns: |
| 68 | + |
| 69 | +- `valid: false` |
| 70 | +- stable error code |
| 71 | +- expected shape |
| 72 | +- `agent_action` |
| 73 | +- `next_steps` |
| 74 | + |
| 75 | +This lets Cursor, Claude Code, or another agent inspect `schema trace --json`, adapt the input into `ContextTrace`, and retry without asking the user to manually reshape data. |
| 76 | + |
| 77 | +## Diagnosis Contract |
| 78 | + |
| 79 | +`diagnose --json` is the primary agent-facing output. |
| 80 | + |
| 81 | +It returns: |
| 82 | + |
| 83 | +- `analysis_scope`: input kind, confidence, limitations |
| 84 | +- `issues`: stable issue codes with evidence and recommendations |
| 85 | +- `diff_summary`: turn-to-turn added/removed/retained token facts |
| 86 | +- `diff_hints`: conservative hints such as large additions, high tool-use additions, and possible artifact churn |
| 87 | + |
| 88 | +Issue codes should be evidence-first. Heuristic findings should use `possible_*` naming and include confidence. |
| 89 | + |
| 90 | +## HTML Report |
| 91 | + |
| 92 | +The HTML report is the human-facing view. |
| 93 | + |
| 94 | +It should keep the existing visual language: |
| 95 | + |
| 96 | +- dark, compact, monospace interface |
| 97 | +- timeline + icicle as the main layout |
| 98 | +- detail panel reused for selected nodes or turns |
| 99 | +- no heavy diagnosis dashboard unless the UI direction changes intentionally |
| 100 | + |
| 101 | +Timeline markers should reflect evidence from `context_diff`, such as large additions and high tool-use turns. Clicking a marked turn should show the diff facts in the existing detail panel. |
| 102 | + |
| 103 | +## Future Graph Layer |
| 104 | + |
| 105 | +The long-term model is a Context Event Graph: |
| 106 | + |
| 107 | +- `Run` |
| 108 | +- `Turn` |
| 109 | +- `Span` |
| 110 | +- `Message` |
| 111 | +- `Artifact` |
| 112 | +- `ContentBlock` |
| 113 | +- `Edge` |
| 114 | + |
| 115 | +Initial graph-like evidence should remain deterministic: |
| 116 | + |
| 117 | +- content hash |
| 118 | +- role and block type |
| 119 | +- tool name |
| 120 | +- tool call id |
| 121 | +- artifact key |
| 122 | +- request index |
| 123 | + |
| 124 | +Avoid semantic stale-content claims until there is enough evidence. Prefer diff evidence plus conservative hints. |
0 commit comments