Input
Enter Analyze this repository in Neural Link while the seeded review workspace is selected.
The demo storyboard maps this intent to a deterministic four-step plan, so the review starts with inspectable work rather than an opaque prompt.
One code review, from intent to evidence
This walkthrough follows the reproducible Analyze this repository path in MachinaOS. The input becomes a structured plan, each step crosses policy before execution, and the result is assembled from tool output that remains visible in the timeline.
The workflow below is grounded in the local MachinaOS runtime and its online-demo storyboard. It documents expected behavior and the seeded demo path; it does not claim a production deployment or a test result from this page.
1. Input and plan
Plan
filesystem.treemaps the repository.filesystem.read_filereadsREADME.md.git.statuschecks working-tree state.git.logreads the five most recent commits.
Each card exposes the tool, arguments, risk level, and step index before execution.
2. Policy and approval
Every step is evaluated
MachinaOS separates planning from execution. The policy engine evaluates capability, explicit blocks, risk, and whether a step requires approval before the executor dispatches a tool.
LOW and MEDIUM steps can run according to policy; HIGH steps require approval; CRITICAL steps are blocked.
What changes the path
This review uses read-only repository tools. A proposed shell command, destructive filesystem operation, network action, credential use, or process kill crosses a different boundary: it can pause for an explicit human decision or be blocked by policy.
The public demo keeps its shared workspace safe with read-only demo tooling. It does not prove that a live demo session can mutate a repository.
3. Tools and execution evidence
The timeline makes the execution legible: plan creation, tool start, tool finish, and task completion. Each step records status transitions such as PENDING → RUNNING → SUCCEEDED, together with arguments and output.
Evidence to inspect: the repository tree, the actual README content, the Git working-tree status, recent commit entries, timestamps, source component, severity, and payload preview.
If a step fails, the executor stops or recovers according to its configured failure path. A missing file, unavailable tool, policy block, or failed command is a boundary in the evidence; it is not a reason to infer a result.
4. Output and review boundary
Output
The final review summary can point back to the collected tree, README, Git state, and commit history. The useful result is a traceable repository snapshot with visible provenance for each finding.
What this does not claim
This walkthrough does not claim that the public demo reviewed an arbitrary repository, ran unrestricted shell commands, changed files, authenticated to GitHub, or used a customer’s cloud account. Those conditions require the relevant local runtime, workspace, provider, and permissions.
Local versus cloud conditions
The MachinaOS core is local-first: orchestration, state, policy, tools, and audit records can run on the host. A local model such as Ollama can keep model traffic local, subject to the tools and workflow selected. Cloud providers, hosted demos, network tools, and remote integrations introduce external requests and their own credentials.
The public demo is a shared, seeded, safety-bounded environment. It demonstrates the observable workflow shape and read-only tool evidence. It is not evidence that the private local runtime and hosted demo have identical capabilities or data.
Method and evidence notes
Prepared from the MachinaOS runtime policy and executor modules, filesystem and shell tool definitions, and the public demo guide plus the local online-demo storyboard. The public entry point is demo.machinaos.ai/demo/start. Reviewed date: 2026-09-05.
For the public product boundary, see Features, Demo Guide, and llms.txt.