Agree the outcome
Describe the change, its limits and the checks that will establish completion.
Example: handle a blocker ↗A delivery system around your coding agents
Get useful work
from your agents.
Keep what you learn.
VIBE-OS connects goals, project work and delivery evidence around Codex and Claude Code. Define the outcome, let a supported coding agent carry out the work, then inspect the checks and the result. Keep useful decisions and examples available for the next project.
For people building software with Codex and Claude Code.
VIBE–OSTHE WORK → THE KNOWLEDGE
- Your goalOutcome + constraints01
- Agreed work02
- Readiness03
- Codex / Claude CodePlan · edit · test · revise04
- Delivery checks05
- Durable records06
- Checked resultProject evidence → Curated learning07
Illustration of the local delivery model.
See responsibilities & limits ↗
Define the outcomeInspect the resultCarry the lesson forward
01 / Workflow
A result you can inspect.
A lesson you can reuse.
Begin with the job to be done. Keep the decisions, checks and evidence close to the work. These examples explain the local delivery policy.
Let the agent work
The supported coding agent plans, implements, checks and revises. The kernel connects the work to its delivery records.
Inspect the division of work ↗Keep the evidence
Read what happened, what was checked and what remains unknown. Select a useful lesson for later work.
Example: preserve the cutoff ↗Demonstrated local policy · Editorial adaptation · Evidence 2026-09-29 · Reviewed 2026-09-30. Evidence and limits.
02 / Architecture
Agents do the work.
The kernel connects it.
An internal developer platform for AI agents: a shared workflow and record of delivery across projects. Current evidence concerns a local system used by one operator.
Your projects
Goals, code, constraints and existing evidence.
VIBE-OS kernel
Agreed work → readiness → coding agent → delivery checks → project evidence.
Reusable learning
Retained evidence and curated examples.
Research → relevant learning
Sources explain a mechanism and where it may help. Planned: systematic lesson extraction and relevance-led scouting.
Learning status ↗Selected evidence → publication
Review public material, build a checked snapshot, then let visitors read that artifact.
Local publication evidence ↗Solid paths describe retained evidence and editorial examples. The planned learning path is shown with a dashed border. Visitors receive a public artifact; operational records stay private. Workflow checks do not guarantee correct software or provide a security sandbox.
Inspect the illustrated workflow and its evidence
Local evidence, 2026-09-29; reviewed 2026-09-30: Delivery policy: an editorial lesson from project evidence · Local release checks: dated public evidence. Agent roles are provider documented: OpenAI: a documented coding and verification loop · Claude Code: planning, code, tools and project context.
03 / Learn
Three ideas.
Grounded in real work.
Start with the problem you recognize. Each lesson includes a mechanism, a concrete example and a boundary. These are curated adaptations of dated project evidence.
Keep a result tied to its evidence
A delivery report turns recorded work into a dated evidence view.
- When this helps
- Deciding what shipped and what the available measurements can support.
- How it works
- Read one committed source snapshot and preserve the evidence cutoff.
- In practice
- A monthly report keeps missing resource measurements unreported.
- Trade-offs
- Incomplete historical records limit conclusions even when a report builds successfully.
- Limits
- Delivery counts alone do not measure productivity or business value.
Demonstrated Editorial adaptation
Evidence 2026-09-29 · Reviewed 2026-09-30
Continue useful work around a genuine blocker
A bounded delivery policy distinguishes optional preferences from required decisions.
- When this helps
- Avoiding unnecessary waiting while preserving unfinished work.
- How it works
- Keep blocked work and its evidence; inspect whether other work is independent.
- In practice
- An optional preference can use a reversible default while a required decision retains its hold.
- Trade-offs
- Independence and file ownership require actual checks.
- Limits
- This explains a tested local policy; no measured throughput gain is claimed.
Demonstrated Editorial adaptation
Evidence 2026-09-29 · Reviewed 2026-09-30
Separate a request from an observation
Requested settings and observed runtime or usage are recorded separately.
- When this helps
- Interpreting resource measurements and configuration claims.
- How it works
- Keep the request, observation and missing-data state distinct.
- In practice
- A requested model setting remains a request when the running environment cannot confirm it.
- Trade-offs
- Unavailable measurements reduce the conclusions that can be drawn.
- Limits
- No inferred savings or universal agent compatibility is claimed.
Demonstrated Editorial adaptation
Evidence 2026-09-29 · Reviewed 2026-09-30
04 / Concepts & comparisons
Different roles.
Useful overlap.
Agents already plan, run tools, keep context and verify work. The distinction here is the particular connection between project delivery, retained evidence and publication.
Project delivery + evidence
VIBE-OS
Delivery policy: an editorial lesson from project evidence · Local release checks: dated public evidence
Coding agent
Codex
Coding agent
Claude Code
Agent workflow toolkit
Spec Kit
Concept map · Tags describe roles, not exclusive capabilities. Documentation assessment checked 2026-09-30; VIBE-OS observations retain their original dates.
| Feature | VIBE-OS | Codex | Claude Code | Spec Kit |
|---|---|---|---|---|
| Execute and verify | Kinda | Yes | Yes | Kinda |
| Keep reusable context | Yes | Yes | Yes | Yes |
| Publish selected evidence | Yes | Not assessed | Not assessed | Not assessed |
Yes = supported within the stated boundary · Kinda = conditional or narrower · Not assessed = evidence does not establish the definition. There is no overall winner score or provider runtime trial here.
Read all comparison explanations
VIBE-OS · Execute and verify — Kinda
VIBE-OS · Execute and verify
- Feature definition
- A supported workflow can change code, run checks and use the result to revise the work.
- Why this rating
- Coordinates agreed work and required checks; code execution belongs to the selected coding agent.
- Limits
- Demonstrated local policy, not a guarantee of correct output.
Demonstrated Editorial adaptation
Evidence 2026-09-29 · Reviewed 2026-09-30
Codex · Execute and verify — Yes
Codex · Execute and verify
- Feature definition
- A supported workflow can change code, run checks and use the result to revise the work.
- Why this rating
- The provider describes a plan, edit, run, observe and repair loop.
- Limits
- The cited long-running build is one experiment, not a duration or success guarantee.
Provider documented Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
Claude Code · Execute and verify — Yes
Claude Code · Execute and verify
- Feature definition
- A supported workflow can change code, run checks and use the result to revise the work.
- Why this rating
- The overview describes planning changes, editing files, running commands and verifying results.
- Limits
- Tool availability and permissions vary by setup; no runtime trial is reported here.
Provider documented Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
Spec Kit · Execute and verify — Kinda
Spec Kit · Execute and verify
- Feature definition
- A supported workflow can change code, run checks and use the result to revise the work.
- Why this rating
- A specification progresses through tasks, implementation and convergence using a supported agent.
- Limits
- The toolkit supplies workflow; the connected agent performs the coding work.
Provider documented Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
VIBE-OS · Keep reusable context — Yes
VIBE-OS · Keep reusable context
- Feature definition
- Project artifacts or persistent context carry instructions, decisions or results into later work.
- Why this rating
- Project decisions and delivery evidence are retained for later inspection and curated lessons.
- Limits
- Automatic cross-project lesson extraction remains planned.
Demonstrated Editorial adaptation
Evidence 2026-09-29 · Reviewed 2026-09-30
Codex · Keep reusable context — Yes
Codex · Keep reusable context
- Feature definition
- Project artifacts or persistent context carry instructions, decisions or results into later work.
- Why this rating
- The provider describes working state held in project files, documentation and outputs.
- Limits
- Persistence alone does not establish that every retained fact is correct or useful.
Provider documented Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
Claude Code · Keep reusable context — Yes
Claude Code · Keep reusable context
- Feature definition
- Project artifacts or persistent context carry instructions, decisions or results into later work.
- Why this rating
- Project instructions and memory support repeated work.
- Limits
- Context influences a run; it does not guarantee compliance or correctness.
Provider documented Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
Spec Kit · Keep reusable context — Yes
Spec Kit · Keep reusable context
- Feature definition
- Project artifacts or persistent context carry instructions, decisions or results into later work.
- Why this rating
- Specifications, plans and tasks remain as artifacts used during implementation.
- Limits
- Artifact quality depends on how the workflow is used and reviewed.
Provider documented Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
VIBE-OS · Publish selected evidence — Yes
VIBE-OS · Publish selected evidence
- Feature definition
- The assessed workflow selects approved project evidence and validates an immutable public artifact with rollback.
- Why this rating
- Local evidence exercised complete snapshots, unchanged refresh, failure protection and rollback.
- Limits
- Local publication evidence does not establish public hosting or service availability.
Demonstrated Local verification
Evidence 2026-09-29 · Reviewed 2026-09-30
Codex · Publish selected evidence — Not assessed
Codex · Publish selected evidence
- Feature definition
- The assessed workflow selects approved project evidence and validates an immutable public artifact with rollback.
- Why this rating
- The cited source does not establish the complete defined publication workflow.
- Limits
- This is not a claim that Codex cannot build or support such a workflow.
Not assessed Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
Claude Code · Publish selected evidence — Not assessed
Claude Code · Publish selected evidence
- Feature definition
- The assessed workflow selects approved project evidence and validates an immutable public artifact with rollback.
- Why this rating
- The cited source does not establish the complete defined publication workflow.
- Limits
- This is not a claim that Claude Code cannot build or support such a workflow.
Not assessed Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
Spec Kit · Publish selected evidence — Not assessed
Spec Kit · Publish selected evidence
- Feature definition
- The assessed workflow selects approved project evidence and validates an immutable public artifact with rollback.
- Why this rating
- The cited source does not establish the complete defined publication workflow.
- Limits
- This is not a claim that the toolkit cannot be extended for publication.
Not assessed Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
05 / Connections
Know what a
connection actually does.
Reading a website, reaching a private network, controlling a computer and authorizing an account are separate capabilities. Each needs its own evidence.
Provider documented Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
Codex + Claude Code
The execution layer plans, edits code and runs tools and checks. VIBE-OS adds the surrounding work and evidence workflow.
Evidence & limits
Provider documentation describes the agents. Project settings, tools and permissions still determine a particular run.
OpenAI: a documented coding and verification loop · Claude Code: planning, code, tools and project context · Delivery policy: an editorial lesson from project evidence
Not assessed Accepted direction
Evidence 2026-09-30 · Reviewed 2026-09-30
Read on your phone
The public edition is designed for a phone browser. Real iOS access to a deployed site still needs device and hosting acceptance.
Evidence & limits
A phone-sized browser test is not a test on a real iPhone. Reading this site does not control a work session.
Provider documented Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
Private access with Tailscale
Tailscale documents connecting iOS to a private network. VIBE-OS access through that route has not been accepted in this edition.
Evidence & limits
Network reachability, service authorization and remote computer control each need their own checks.
Provider documented Provider documentation
Evidence 2026-09-30 · Reviewed 2026-09-30
Remote session or remote computer?
Claude Code documents continuing a local session remotely. A VIBE-OS remote-computer workflow has not been assessed here.
Evidence & limits
A coding session connection does not establish whole-desktop control. No VIBE-OS remote-control acceptance is claimed.
Planned Accepted direction
Evidence 2026-09-30 · Reviewed 2026-09-30
Account authorization with OAuth
OAuth supports delegated access to a service. A reusable VIBE-OS account authorization integration is planned.
Evidence & limits
The protocol definition is documented; provider setup, permissions, revocation and end-to-end acceptance remain to be delivered.
IETF: OAuth 2.0 authorization framework · Accepted direction and current limits
Planned Accepted direction
Evidence 2026-09-30 · Reviewed 2026-09-30
SMS + WhatsApp
Message delivery and authenticated replies are planned integrations.
Evidence & limits
No live delivery, recipient acceptance or reply-triggered work is demonstrated by this website.
Planned Accepted direction
Evidence 2026-09-30 · Reviewed 2026-09-30
Reusable lessons + scouting
Curated lessons are available below. Systematic extraction and relevance-led scouting are planned.
Evidence & limits
Published examples are editorial selections. They do not establish automatic learning or model retraining.
Evidence and missing measurements: an editorial lesson · Accepted direction and current limits
Planned Accepted direction
Evidence 2026-09-30 · Reviewed 2026-09-30
Event-driven publication
Checked static snapshots are supported. Automatically refreshing the website from events is planned.
Evidence & limits
An accepted integration needs its own trigger, failure and publication checks.
Local release checks: dated public evidence · Accepted direction and current limits
06 / Case studies
Built for a real job.
Checked within clear limits.
Anonymised examples from in-house products. Explore what was built, why the platform fit and what carried into another project.
3 demonstrated locally · 1 evidence gap
Windows desktop
Demonstrated locally
Keep sound knowledge beside the working tools
- Problem
- A musician needs structured notes about a sound while working in an existing Windows application.
- Implemented result
- A document pane loads a local sound knowledge file and renders its headings, technique tables and effects notes. A source hint shows which document was opened.
- Why this platform fits
- The demonstrated job already uses a Windows application and local knowledge files. A native document pane keeps those files in the established desktop workflow without requiring a hosted account.
- What was reused
- The existing sound records supply a fallback when a document is absent. The pane uses the application theme and docking surface instead of introducing another viewer.
- Costs and maintenance
- A Windows machine, local document storage, application and component maintenance, and any applicable component licences remain.
Verification 2026-09-24 · Source review 2026-09-30
Read evidence and limitsWeb product
Demonstrated locally
Publish useful evidence without exposing the workspace
- Problem
- Product visitors need readable delivery evidence while operational source records stay private.
- Implemented result
- A static product site presents a workflow, practical lessons, scoped comparisons and a dated evidence ledger. Approved releases can be revisited and the selected edition can be rolled back.
- Why this platform fits
- A browser fits read-only distribution across desktop and phone-sized screens. A static artifact can be inspected without granting a visitor access to the operational system.
- What was reused
- Three earlier delivery stories were adapted into lessons about dated evidence, independent work and requested versus observed settings. The publication keeps the existing immutable-release and rollback mechanism.
- Costs and maintenance
- Hosting, domain management, editorial review, retained-release storage and ongoing accessibility and dependency checks remain; their costs are not measured here.
Verification 2026-09-30 · Source review 2026-09-30
Read evidence and limitsNetwork documentation / monitoring
Demonstrated locally
Read the infrastructure through its recorded evidence
- Problem
- An operator needs to move from a system map to machine inventory and understand stale or missing documentation.
- Implemented result
- A Windows topology browser reads collected infrastructure records and shows inventory, queued work and documentation-coverage badges. Application diagrams add host grouping and drill-through with a breadcrumb.
- Why this platform fits
- The job uses local collected files and an established Windows administration workflow. The viewer can read those records without publishing the private network to a website; this case does not establish live device access.
- What was reused
- The infrastructure browser applied a diagram lesson from the music application: generate connectors from the data model and explicitly position runtime nodes when automatic layout does not apply. A theme-colour build check was also adapted from a separate local analysis application.
- Costs and maintenance
- Collectors, data freshness, storage, access control, Windows and UI-component maintenance remain. Private network inventory and screenshots are excluded.
Verification 2026-07-14 · Source review 2026-09-30
Read evidence and limitsSubscription replacement
Evidence gap
A replacement needs proof of the job it replaces
- Problem
- A local tool may cover a paid service task, but replacing a subscription requires evidence of the exact work and acceptable quality.
- Implemented result
- No subscription replacement is established by the reviewed portfolio. An earlier local audio candidate was retired before its required review on representative recordings.
- Why this platform fits
- A local Windows tool could fit files already on the machine. That is a platform rationale only; it does not establish that the paid service job has been replaced.
- What was reused
- The portfolio reuses the rule that a requested result and an observed result stay separate. Retired or unchecked candidates do not become current product successes.
- Costs and maintenance
- A future comparison must include compute, electricity, storage, setup, quality review, maintenance, licences and any remaining paid service; all amounts and net savings are unmeasured.
Verification 2026-09-24 · Source review 2026-09-30
Read evidence and limitsVerification dates describe the recorded checks. Source review dates describe the later editorial inspection. Private source revisions and claim mappings are retained; only these reviewed summaries are published. No customer deployment or productivity gain is implied.
07 / Evidence
A dated record.
With the gaps left visible.
These selected public summaries preserve the scope and limits of the original observations. Source mappings and approval records are retained privately.
A checked release can be revisited
A dated local verification exercised immutable releases, unchanged-input refresh, failure protection and rollback.
Method. Build a complete snapshot, verify it, then switch the active entry.
Observation. The original local publication retained previous assets while changing the selected release.
Limit. Historical local validation does not establish public hosting, availability or security guarantees.
Demonstrated Local verification
Evidence 2026-09-29 · Reviewed 2026-09-30
| Record | Status | Evidence date | Review date | Basis |
|---|---|---|---|---|
| A checked release can be revisited | Demonstrated | 2026-09-29 | 2026-09-30 | Local verification |
| Keep a result tied to its evidence | Demonstrated | 2026-09-29 | 2026-09-30 | Editorial adaptation |
| Continue useful work around a genuine blocker | Demonstrated | 2026-09-29 | 2026-09-30 | Editorial adaptation |
| Separate a request from an observation | Demonstrated | 2026-09-29 | 2026-09-30 | Editorial adaptation |
Sources & reading list
- OpenAI: a documented coding and verification loopProvider documentation · Checked 2026-09-30
- Claude Code: planning, code, tools and project contextProvider documentation · Checked 2026-09-30
- GitHub Spec Kit: specifications through implementationProvider documentation · Checked 2026-09-30
- Tailscale: connect an iOS deviceProvider documentation · Checked 2026-09-30
- Claude Code: continue a local session remotelyProvider documentation · Checked 2026-09-30
- IETF: OAuth 2.0 authorization frameworkProvider documentation · Checked 2026-09-30
- Local release checks: dated public evidenceLocal verification · Checked 2026-09-30
- Delivery policy: an editorial lesson from project evidenceEditorial adaptation · Checked 2026-09-30
- Evidence and missing measurements: an editorial lessonEditorial adaptation · Checked 2026-09-30
- Accepted direction and current limitsAccepted direction · Checked 2026-09-30
08 / This edition
Read it now.
Return to the same evidence.
A release is a fixed snapshot. Its generation time describes the build; evidence and review dates describe the claims. Older approved releases remain available at their original addresses.
Public edition: workflow, architecture, three curated lessons, scoped comparisons and connection status. Static reading is available without access to the operational kernel.