| Page | What it covers |
|---|---|
| Getting started | Installers, platforms, prerequisites, the manual path, first task, multi-repository tasks |
| Terminal interface | bcode chat (direct and bounded modes), first-run setup, views and keys |
| Verification | Result states, behavioural evidence, cross-repository compatibility, known limits |
| Configuration | config.yaml, model providers, budgets, sandbox, repository verification presets |
| Languages | What works for any language, the capability model, statuses, the validation matrix, adding a language |
| Direct-mode command sandbox | What commands can reach on each platform, the network proxy, the fallback when containment is weaker, mechanisms evaluated, residual risks |
| Direct-mode security policy | Trust boundaries, sensitive operations and how they are authorized, the verification fallback, MCP trust and pinning, residual risks |
| Inference protocol | What the gateway does with each request and answer, per provider: capabilities, reasoning in the history, structured output, failures it handles, what each call records, llama.cpp cache settings |
| Context and session state | How long sessions stay within the model's working set: command output pruning, setting results aside, the session state that replaces older history (record and model notes), trust, persistence, stale context |
| Retrieval | What travels with each message and each retry: strategies, when each runs, ranking, language servers, provenance and staleness, compaction and recall, budgets, limits |
| Serena | Optional LSP-backed symbol navigation |
| Harness laboratory | bcode lab: failure patterns in recorded runs, hypotheses, isolated experiments decided on held-out tasks across languages, proposals, approval and promotion, workload overrides, and what a candidate may never touch |
| Page | What it covers |
|---|---|
| System architecture | Processes, interfaces, control loop, context planning, package map |
| Tool capabilities | Direct and bounded mode compared (tools, permissions, context, sessions, execution, verification, errors, events, traces, accounting); what they share and keep apart; direct mode's tool pipeline, concurrent calls, editing, MCP discovery |
| Everyday development: direct mode | The two-mode product shape, the competitive gap, phases 17–23 and what phase 17 built |
| Tool coverage | Every Pi, Qwen Code and Claude Code tool and capability, and its BoundedCode equivalent |
| Sandbox design | Threat model, controls, adversarial tests, residual risks |
| Cross-repository compatibility | The experimental gRPC/protobuf/OpenAPI gate |
| Cross-service analysis | Contract detection across repositories |
| Upstream components | Pinned versions and update policy |
| ADRs | Architecture decisions |
| Product spec | Goals and scope |
| Page | What it covers |
|---|---|
| Evaluation overview | What was measured, how to read it, and its limits |
| Comparative evaluation (2026-10) | BoundedCode vs. the same agent and model without it: protocol, results, deviations |
| Baseline (2026-10-27) | Architecture inventory, language-support matrix, three runs per mode with pinned environment, where time, tokens and memory go, run-to-run noise, and how to compare a change with it |
| Verification benchmark (2026-10) | False acceptance and false rejection of the verification pipeline, before and after test integrity and mutation, in Go, Python, JavaScript, TypeScript, Rust, Java and a mixed repository |
| Retrieval benchmark (2026-10) | Retrieval measured apart from patch correctness on 267 real issues in ten languages (development and held-out repositories), then in the agent loop: recall, precision, context, latency, tool calls, redundant reads, completion |
| Inference benchmark (2026-10) | Reasoning in the history, the offload threshold and structured output, each measured before and after: task results, prompt tokens the server evaluated, prompt time, time to the first token, parseable replies |
| Context benchmark (2026-10) | Command-output pruning on 42 real outputs (development and held out), the session state against the free-text summary in the agent loop, the cache-aligned notes request, and pruning by a model (rejected): evidence kept, tokens, pass rate, summary latency, cache |
| Evaluating a change | The suites, groups and splits, clean-snapshot grading, tamper detection, security grading, scorecards with uncertainty and the noise-aware regression gate CI runs |
| Evaluation coverage | Every task by language, group and capability, what runs here, contamination against the default model, integrity problems (generated by bench catalog) |
| Cross-language evaluation (2026-10) | The suites across ten languages: direct, bounded, verification and security results with trials and intervals, and what each language's verification misses |
| Harness laboratory (2026-10) | Methods studied, failure patterns in 1,500 recorded runs, past decisions re-read with a paired test, and the first prospective experiment |
| Adaptive execution benchmark (2026-10) | Model capabilities probed with BoundedCode's own requests, four model sizes on the same tasks, speculative decoding (n-gram, draft model, MTP) in isolation and in the agent loop, thinking routed per call, model choice, escalation policies replayed on recorded runs, and what escalation packets carry |
| Orchestration benchmark (2026-10) | Calls of one reply run together, MCP tools found on demand, and both modes' suites before and after the shared tool architecture: tool latency, tool calls, tokens, time, determinism and policy consistency |
| Direct-mode suite (2026-10) | The everyday agent on 13 tasks and 2 sessions with the local model: pass rate, tool calls, cache hits, time, per change |
| Project detection | Projects found in any language on 12 public repositories, with what was missed and fixed |
| Lease study · trail study | Whether a request's text, or a repository's history, predicts what a change touches; measured on real commits before building on it |
| Evidence demo | The README demo: reproducible scenario, recordings, what it does and does not show |
| Second (held-out) validation | 6 screened public tasks, 5 of 6 TASK_VERIFIED |
| Initial validation | 8 public tasks, 0/8 then 1/8, with the failures |
| Failure-driven engineering and targeted pass | Development evidence, including false verification passes |
| Raw reports | Per-run JSON, logs and manifests |
| Submitting an evaluation result | How an external result must be run, reported and submitted |
| Page | What it covers |
|---|---|
| Release notes and CHANGELOG | What changed, per release |
| Implementation status | What is implemented, experimental or planned |
| Readiness audit (2026-10) · README review | Evidence-checked findings, fixes and open risks; first-visitor review of the README |
| Onboarding validation | Installation and first-task tests: environments, commands, results, platform matrix |
| Licensing | Upstream license matrix |
| Security policy · Contributing | Reporting vulnerabilities, development setup, tool versions, what CI checks |
| Contributor onboarding | From a fresh clone to a pull request; first-contribution opportunities |
| Engineering case study | The problem, architecture, trade-offs, evaluation results and limitations, with references to code and evidence |
| Repository readiness (2026-10) | GitHub configuration audit, metadata recommendations, changes that need the maintainer |
| Adoption metrics · feedback process · 14-day launch checklist | What counts as external adoption and where it is measured (no telemetry); how reports are reproduced, prioritized and turned into work |