Home

JobeBOT Documentation

Start here

One platform, three connected layers

JobeBOT combines the web control plane, a local WorkSpace, and a governed model gateway.

JobeBOT Web

Accounts, catalogue, teams, credits, settings, and plan controls.

JobeBOT WorkSpace

Project files, preview, editor, terminal, agents, diagnostics, and verification.

Gateway and bridge

Local and configured providers with policy, routing, and certification gates.

JobeBOT secure AI development workspace

How it works

From request to verified result

A prompt is classified before action. The selected agent reads the project, plans the change, uses approved tools, and verifies the rendered result.

  • Context and intent come before action.
  • Native tool calls or verified recovery are required for writing.
  • Completion requires disk evidence, checks, and an honest final status.
JobeBOT agents coordinating a verified build

JobeBOT WorkSpace

The local surface for real project work

WorkSpace is the project-aware execution surface. It keeps the active folder, file tree, preview, browser diagnostics, terminal, agent activity, and completion contract visible together.

  • Project files: inspect and open the actual working tree.
  • Preview: load the local URL and verify the rendered result.
  • AI Focus: inspect the prompt, model route, activity, and contract.
  • Terminal: run approved commands in the project context.
JobeBOT WorkSpace bringing an existing project into a verified workflow

Agents and models

Capability is not the same as certification

Agents coordinate work. Models supply inference. A catalogue entry or successful chat response does not certify autonomous coding.

RoleBest forEvidence
PlannerBreaking down ambiguous workCurrent plan tied to the project
CoderWriting files and targeted fixesTool calls, read-back, syntax, browser proof
ReviewerFinding risks and missing testsFindings and line-level evidence
Vision reviewerInspecting layout and responsive behaviorRendered screenshots or browser evidence

Writing files and proving completion

Text in chat is not a saved deliverable

A model response becomes a completed implementation only after the requested behavior exists in the target project and the result is checked.

  1. The requested behavior appears in the actual target project.
  2. Only intended files are changed.
  3. Read-back evidence confirms the saved content.
  4. Syntax, tests, and browser checks pass where applicable.
  5. The audit record distinguishes completed, blocked, and unverified work.

Common troubleshooting

Use evidence to find the stalled layer

SymptomFirst check
Agent writes prose onlyConfirm Agent mode and run a minimal native tool-call probe.
Files reported absentCompare the absolute target path and read back the content.
Run stays WorkingInspect provider timeout, cancellation, approval, and transcript state.
Preview is staleCheck HTTP status, asset errors, console output, and cache-busting.
Model is blockedDiscovery is not certification; read the admission state and evidence.