Agent-first developer platform for specs, coding-agent routing, isolated work, verification, GitHub delivery, releases, and managed rollout.
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: 开源项目. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository lehard/dev-platform;first catalogued 2026-10-10;last seen 2026-10-10。There is no official certification or quality rating here — we record sources and dates only.
Dev Platform
以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →
**A developer platform for agent-first software development.**
Dev Platform coordinates specifications, coding agents, isolated work, verification, provider-adapted delivery, releases, and continuous process improvement across multiple repositories.
Once coding agents can generate code quickly, the bottleneck moves to **context, coordination, verification, integration, and lifecycle reliability**. Dev Platform turns those concerns into a versioned engineering lifecycle instead of leaving every repository to reconstruct them from prompts, conventions, and one-off scripts.
Idea / Task → Spec → Route → Implement → Verify → Publish → Learn
> [!NOTE]
> This repository is the platform source and Project Factory. Managed projects consume immutable platform releases; they do not execute mutable dev-platform@main lifecycle logic.
Why a platform instead of AGENTS.md + scripts?
AGENTS.md is necessary, but it is only one layer of the system. Dev Platform combines the agent contract with executable lifecycle primitives and cross-repository release management:
- **specification lifecycle** — OpenSpec turns accepted intent into a durable implementation contract;
- **model routing** — work can be routed to Codex or Claude Code with explicit execution provenance;
- **isolated execution** — feature branches, worktrees, scope ownership, and coordination keep parallel writers from sharing mutable state;
- **verification** — repository checks, semantic OpenSpec verification, and truthful verification receipts are completion gates;
- **provider-adapted delivery** — GitHub PR and bounded GitLab MR publication have explicit terminal states and recovery semantics;
- **versioned platform rollout** — Copier, immutable releases, and reviewed downstream upgrades distribute reusable process safely;
- **process learning** — structured friction becomes evidence for reusable platform improvements instead of disappearing in chat history.
The result is a control plane for the engineering lifecycle, not a replacement coding agent.
Core capabilities
- **Project Factory** for new repositories and conservative adoption of existing ones.
- **OpenSpec lifecycle** from proposal through implementation, verification, archive, and accepted specs.
- **Codex and Claude Code routing** behind one provider-neutral repository contract.
- **Workflow profiles** for single-agent, standard branch-based, and parallel multi-agent work.
- **Isolated workspaces** with worktree and scope coordination where the profile requires them.
- **Risk-proportional validation** plus protected full validation before publication.
- **provider-neutral publication** with exact GitHub PR safety and bounded GitLab MR delivery.
- **Immutable SemVer releases** and exact-version Copier upgrades.
- **Managed rollout** that opens reviewed upgrade PRs across adopted repositories.
- **Continuous process improvement** through sanitized friction capture and periodic review.
How it works
A normal change moves through one lifecycle:
1. **Intent becomes a contract.** A small task can stay lightweight; a non-trivial accepted change is described with OpenSpec so implementation does not depend on transient chat context.
2. **The task is routed.** The platform records a bounded routing decision and selects Codex or Claude Code at an appropriate tier.
3. **Implementation is isolated.** The selected workflow profile determines whether the task uses a direct checkout, a feature branch, or a dedicated worktree with coordination metadata.
4. **The result is verified.** Selected checks give fast feedback; required full checks and semantic OpenSpec verification establish completion evidence.
5. **Provider delivery reaches a terminal state.** A pushed branch, open review object, or green CI run is not treated as delivery until the configured publication lifecycle completes.