Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/qwerfunch/cladding

Ending vibe coding. The integrity layer for AI-coded software — spec-driven, drift-aware, iron-clad. Reference implementation of the Ironclad standard, with a plugin and MCP server for Claude Code, Codex CLI, Gemini CLI, and Cursor.
https://github.com/qwerfunch/cladding

ai-coding claude-code claude-code-plugin codex-cli cursor-ide drift-detection gemini-cli gemini-cli-extension harness harness-engineering ironclad mcp-server spec-driven-development typescript vibe-coding

Last synced: 5 days ago
JSON representation

Ending vibe coding. The integrity layer for AI-coded software — spec-driven, drift-aware, iron-clad. Reference implementation of the Ironclad standard, with a plugin and MCP server for Claude Code, Codex CLI, Gemini CLI, and Cursor.

Awesome Lists containing this project

README 

          



cladding — the verification layer around your host LLM



  * { box-sizing: border-box; }

  html, body { margin: 0; padding: 0; }

  body {

    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Pretendard, "Apple SD Gothic Neo", "Noto Sans KR", sans-serif;

    font-size: 16px;

    line-height: 1.7;

    color: #1e293b;

    background: #ffffff;

  }

  .container {

    max-width: 920px;

    margin: 0 auto;

    padding: 48px 24px 96px;

  }

  h1 {

    font-size: 56px;

    font-weight: 800;

    letter-spacing: -1.5px;

    text-align: center;

    margin: 24px 0 12px;

    color: #1e293b;

  }

  h2 {

    font-size: 28px;

    font-weight: 700;

    margin: 64px 0 16px;

    padding-bottom: 10px;

    border-bottom: 1px solid #e2e8f0;

    color: #0f172a;

  }

  h3 {

    font-size: 20px;

    font-weight: 700;

    margin: 40px 0 12px;

    color: #1e293b;

  }

  p { margin: 14px 0; }

  strong { font-weight: 700; color: #0f172a; }

  em { font-style: italic; color: #475569; }

  a { color: #2563eb; text-decoration: none; }

  a:hover { text-decoration: underline; }

  code {

    font-family: "SF Mono", Menlo, Consolas, "Liberation Mono", monospace;

    font-size: 0.88em;

    background: #f1f5f9;

    padding: 2px 6px;

    border-radius: 4px;

    color: #0f172a;

  }

  pre {

    background: #0f172a;

    color: #e2e8f0;

    padding: 20px 24px;

    border-radius: 8px;

    overflow-x: auto;

    margin: 20px 0;

    font-size: 14px;

    line-height: 1.6;

  }

  pre code {

    background: transparent;

    color: inherit;

    padding: 0;

    font-size: inherit;

  }

  ul, ol { margin: 14px 0 14px 28px; padding: 0; }

  li { margin: 8px 0; }

  img.diagram-img { max-width: 100%; height: auto; }

  hr { border: 0; border-top: 1px solid #e2e8f0; margin: 48px 0; }



  /* Tagline */

  .tagline {

    text-align: center;

    color: #475569;

    font-size: 18px;

    margin: 0 0 24px;

  }

  .tagline strong {

    font-size: 19px;

    color: #1e293b;

  }



  /* Badges */

  .badges {

    text-align: center;

    margin: 20px 0 28px;

  }

  .badges img {

    margin: 2px 4px;

    vertical-align: middle;

  }



  /* Lead description */

  .lead {

    text-align: center;

    color: #475569;

    font-size: 16px;

    margin: 0 0 32px;

    line-height: 1.6;

  }



  /* Goal statement under the hero diagram */

  .goal {

    text-align: center;

    margin: 28px auto 8px;

    max-width: 760px;

  }

  .goal .what {

    font-size: 20px;

    font-weight: 700;

    color: #0f172a;

    line-height: 1.55;

  }

  .goal .what em { font-style: normal; color: #1d4ed8; }

  .goal .why {

    font-size: 15px;

    color: #475569;

    margin-top: 10px;

  }



  /* before · after · record 3-card */

  .flow-cards {

    display: grid;

    grid-template-columns: repeat(3, 1fr);

    gap: 16px;

    margin: 24px 0;

  }

  .flow-card {

    border-radius: 12px;

    padding: 20px 22px;

    background: #ffffff;

    border: 1px solid #e2e8f0;

  }

  .flow-card .badge {

    display: inline-block;

    font-size: 11px;

    font-weight: 700;

    letter-spacing: 1.2px;

    padding: 3px 10px;

    border-radius: 99px;

    margin-bottom: 10px;

    color: #ffffff;

  }

  .flow-card.before .badge { background: #3b82f6; }

  .flow-card.after  .badge { background: #1d4ed8; }

  .flow-card.record .badge { background: #64748b; }

  .flow-card .title { font-size: 15px; font-weight: 700; color: #0f172a; margin-bottom: 8px; }

  .flow-card p { margin: 8px 0; font-size: 14px; line-height: 1.65; color: #475569; }

  .flow-card ul { margin: 8px 0 0 18px; }

  .flow-card li { font-size: 13.5px; color: #475569; margin: 5px 0; }



  /* Earn callout */

  .earn {

    background: #f8fafc;

    border: 1px solid #e2e8f0;

    border-radius: 10px;

    padding: 20px 24px;

    margin: 20px 0;

  }

  .earn .line { font-size: 15px; color: #334155; margin: 6px 0; }

  .earn code { background: #eff6ff; }



  /* Tables */

  table {

    width: 100%;

    border-collapse: collapse;

    margin: 20px 0;

    font-size: 14px;

  }

  th, td {

    border: 1px solid #e2e8f0;

    padding: 12px 16px;

    text-align: left;

  }

  th {

    background: #f8fafc;

    font-weight: 700;

    color: #0f172a;

  }

  td.center { text-align: center; }

  td.vanilla-cell { color: #64748b; text-align: center; }

  td.cladding-cell { color: #1d4ed8; font-weight: 700; text-align: center; }



  /* Diagram container */

  .diagram {

    margin: 24px 0;

    text-align: center;

  }



  /* Section spacing under h2 */

  h2 + p, h2 + div { margin-top: 8px; }



  /* Footer */

  footer {

    margin-top: 80px;

    padding-top: 32px;

    border-top: 1px solid #e2e8f0;

    text-align: center;

    color: #64748b;

    font-size: 13px;

  }



  /* Responsive */

  @media (max-width: 720px) {

    .container { padding: 32px 16px 64px; }

    h1 { font-size: 40px; }

    h2 { font-size: 24px; margin-top: 48px; }

    .flow-cards { grid-template-columns: 1fr; }

    table { font-size: 13px; }

    th, td { padding: 10px 12px; }

  }






  
cladding — Unified Governance for AI-Coupled Engineering



  
English · 한국어



  
cladding



  


    To trust AI with coding, an organization needs three things —
that the code can be trusted, that it's traced, and that it holds up as you scale. cladding builds those three.


    True to its name (cladding = the outer layer), it wraps the host LLM and verifies what comes before and after.

  



  


    ironclad

    spec

    tests

    detectors

    license

  



  


    The official reference implementation of the Ironclad standard.


    It feeds the project's intent to the host LLM (Claude Code · Codex · Gemini · Cursor) before work begins,


    and verifies the result with 41 detectors and a 15-stage gate after the work is done.

  



  

  


    


      
Only verified code ships as 'done'


      
Even when the AI says "it's done", it has to pass the checks — so code that wasn't verified is never accepted as 'done'.


    


    


      
What shipped is on the record


      
What was verified is stamped into committed content, who and when land in the local session ledger, and why lives in the spec — so handoff and review can trace decisions without archaeology.


    


    


      
It holds up as the team grows and you add more AIs


      
Because the spec is the shared standard, conflicts and drift are blocked automatically.


    


  



  

  


    Host LLM before (inject intent) · after (verify) · record (feedback loop) — how cladding wraps the LLM in a collaborative structure

  



  


    


      This loop aims at one thing —


      turning the AI's "it's done" from a claim into a proof.

    


    


      So you can ship AI-written code trusting it as much as code a human wrote.

    


    


      cladding builds itself with cladding too — 242 of its 245 features passed the same gate, and it's the first L4 implementation of the Ironclad standard.

    


  



  

  
How cladding works with your host LLM



  


    


      BEFORE — INJECT INTENT

      
So the LLM starts with the right context


      
    

            
  • 

    Project map injection — at the start of every session, the features, what's in progress, and the last verification result are handed over automatically (now you can see it with your eyes too ↓)

    • 

            
  • 

    Extract only the intent that matters — just the why, the related features, and the acceptance criteria for the feature you're working on (it does not dump the whole spec)
    • 

            
  • 

    Apply project rules — the team's forbidden and preferred patterns go in as standing instructions every time
    • 

          


    


  



  
After — verify: the 15-stage gate, 41 drift detectors, and an implementation-blind grader (below).


  


    Real-time intervention (map injection · instant block · stop block) works fully in Claude Code.

    On Codex · Gemini · Cursor the same verification runs through in-conversation tool calls and git · CI gates.

  



  

  
done is not declared, it's earned


  


    The chronic disease of AI coding is that "it's done" gets declared without verification. In cladding, a feature's

    status: done is not a value you write but a value you earn.

  


  


    One scene — a hook blocks the LLM's done declaration, a RED gate feeds back as a repair card, and done is earned only when GREEN

  


  


    
① If the AI tries to write the completion flag itself → it is blocked on the spot ("earn completion through verification")


    
② If the AI requests completion → it runs all 9 decisive stages and records done only when they all pass, auto-reverting if even one fails — the E2E · evidence stages are handled by CI's full 15 stages


    
③ The moment it passes, a verification signature is left behind — committable proof that "this code was verified at this point"


    
④ If you try to end a conversation while a failure remains → it stops you once (if you end again on the same failure, it records rather than letting it through) and carries the repair card into the next conversation


  


  


    The limits are disclosed openly too: bypass paths exist that the instant block can't see, and those are caught by after-the-fact verification (the gate · drift checks).

    The instant block is the first line of defense, after-the-fact verification the second — and neither is a guarantee on its own.

  



  

  
What changes


  
How behavior differs between a typical AI coding environment and a cladding environment in the same situation.


  

    

      SituationTypical AI codingcladding

    

    

      When code drifts from the specFixed if caught in reviewAuto-detected right after editing (alert) · "done" can't pass while drifted

      When the AI says "it's done"No choice but to trust its worddone earned only when the gate is GREEN

      When you end a session in a failed stateEnds as-is, forgotten next timeStops the exit once and hands off a repair card

      Two people add a feature at oncemerge conflicthash-8 ID · separate files → 0 conflicts

      Who verifies AI-written code?The AI that wrote it self-verifies (risky)An implementation-blind grader + mechanical gate

      When you switch AI toolsReconfigure per tool1 spec → auto-wired to 4 hosts

    

  



  

  
Project map — now you can see it and ask it NEW



  


    cladding always keeps a map inside it that links spec · code · tests · docs. Now you can see that map with your own eyes.

  



  


    
Why it's special — the explanation and the code don't drift apart.


    
Documentation lies as time passes — the code changes while the description stays put. cladding re-aligns that link every time the code is read, and blocks 'done' while they're out of sync.


  



  


    This is cladding's mental map of your project — blue = spec (center), orange = code, green = tests, pink = docs; more-connected nodes grow larger and pull to the center.

  


  


    cladding knowledge graph — spec · code · tests · docs color-coded and connected (animated view)



  



  


    


      SEE

      
Your whole project in one picture


      
Run clad graph serve and it opens in your browser, so you can see at a glance what connects to what.


    


    


      ASK

      
"What breaks if I change this?"


      
Ask the map and it tells you what's affected and which tests to run — no guessing.


    


    


      MEASURE

      
The larger the project, the brighter it shines


      
The amount you have to read to make a change drops sharply — on average 4× less than reading everything. (clad measure)


    


  



  
To launch it yourself — from your project folder:


  
clad graph serve                                  # live graph — localhost:3000, auto-reloads on save

clad graph export --format html --out graph.html  # or export to a single offline .html file


  
Both require cladding 0.7.0+.



  

  
How it works


  
Spec → Code → Tests circulates as one cycle — the spec records the why, the gate verifies, and detectors block drift.



  


    Spec → Code → Tests cycle — a 15-stage verification and 41 drift detectors guard the cycle

  



  
1. Spec — the standard for everything (SSoT)


  
The spec records the why (what is being built and why). A 4-tier single source of truth — intent on top, artifacts below, and the code follows the spec.



  

    

      TierRoleDefined · authored byAuthority

    

    

      A — SpecIntent (what · why)Humans define intent → the LLM writes it in EARS formDoesn't change without human approval · top priority

      B — DesignDesign (how)Humans steer the direction → the LLM writes itChecked for consistency with A

      C — DerivedArtifacts (code · tests) + attestation (verification signature)The LLM writes itAuto-regenerated from the code

      D — AuditAudit record (what happened)Auto-recorded (append-only)Local

    

  



  
A takes precedence over every tier below — if the spec (A) and the code (C) differ, the wrong one is the code.



  
Sharding · multi-dev safe — like spec/features/<slug>-<hash8>.yaml, with a separate file per feature + an 8-character hash ID (e.g. F-d86375d8). Even if two people create a new feature at the same time, they get different files · different IDs, so merge conflicts are 0. Details in Hash-based feature IDs.



  


    4-tier SSoT — A(Spec) → B(Design) → C(Derived + attestation) → D(Audit), A takes precedence over B

  



  
2. Gate — the 15-stage Iron Law


  
One check engine, bundled by cost — 3 stages at commit, 9 at push · completion, all 15 in CI. Only the depth differs.


  


    15-stage Iron Law gate — static(6) · tests·conformance(4) · E2E(3) · evidence(2), attestation signed when GREEN

  



  

    

      StageWhat it checks

    

    

      1.1 Type · 1.2 LintType errors · code style

      1.3 Driftspec ↔ code drift across 41 detectors

      1.4 Commit · 1.5 Arch · 1.6 SecretClean working tree · architecture invariant · API key exposure

      2.1 Unit · 2.2 CoverageUnit tests pass · coverage drop blocked

      2.3 Spec conformance · 2.4 Deliverable smokeThe implementation-blind grader's tests pass · whether the declared deliverable actually runs (blocks the "tests pass but the deliverable won't run" vacuous green)

      3.1 Smoke · 3.2 Perf · 3.3 Visuale2e core behavior · performance budget · UI visual regression

      4.1 Audit · 4.2 UATAt least 1 piece of evidence per AC (acceptance criterion) · at least 1 piece of evidence per done feature

    

  



  
3. Detector — 41 drift detectors


  
Automatically detects drift in every direction among spec · code · test. Full catalog: detector catalog.


  

    

      DirectionWhat it catchesCountRepresentative detectors

    

    

      spec ↔ codeIn the spec but not the code, or code straying from the spec10MISSING_IMPLEMENTATION, AC_DRIFT, DELIVERABLE_INTEGRITY

      code ↔ testCode exists but no tests · coverage drop · secrets6MISSING_TESTS, COVERAGE_DROP, HARDCODED_SECRET

      spec ↔ testSpec ACs not verified by tests · false status5UNTESTED_AC, STATUS_DRIFT, SPEC_CONFORMANCE

      spec hygieneIntegrity of the spec itself (ID collision · dependency cycle)8ID_COLLISION, SLUG_CONFLICT, DEPENDENCY_CYCLE

      environment integrityBuild environment · meta files3HARNESS_INTEGRITY, META_INTEGRITY

      verification freshnessWhether code changed after the verification signature1STALE_ATTESTATION (new)

      governance · docsPolicy violations · documentation drift · README claims beyond the evidence4ABSENCE_OF_GOVERNANCE, PROJECT_CONTEXT_DRIFT, HOST_CLAIM_DRIFT (new)

      graph · doc linksBroken doc ↔ spec links · missing dependency edges4DOC_LINK_INTEGRITY, REFERENCE_INTEGRITY, INFERABLE_DEPENDS_ON (new)

    

  



  
4. Cycle — the lifecycle of one feature


  
Define → sync → implement → earn. You earn "done" only by passing every check.


  


    Lifecycle of one feature — define → sync → implement → earn, completion earned when all checks pass / auto-reverted on failure

  



  

  
Using cladding as your agent loop's verifier


  


    You own the loop — whatever harness or orchestrator drives your agent. cladding is the

    verifier and state layer inside it: it doesn't run your loop, it tells the loop what's still wrong and when it's allowed to stop.

  


  
    

        
  • 

    Feedback signal — run clad check --json each iteration. The verdict is machine-readable: a top-level anyFailed and a worst severity, plus per-stage findings[] where each entry carries its detector, severity, and message. Feed that straight back as the loop's error signal — no scraping console text.
    • 

        
  • 

    Honest stop — gate the loop on clad done, not on the agent's say-so. It flips a feature to done only when the strict pre-push gate is GREEN, and reverts otherwise. "The loop says it's finished" becomes "the gate let it stand."
    • 

        
  • 

    Loop memory — the local event log (.cladding/events.log.jsonl, gitignored) carries what happened across iterations: gate runs (deduped per HEAD), done attempts, drift firings, value serves. The next iteration reads it as local working memory — not a durable or authoritative record, and it rotates at 5 MB (a single generation), so the oldest entries fall away.
    • 

      


  


    The honest boundary: this hardens the loop's stop condition and feedback signal, not the model's code quality. cladding's own A/B record is the receipt — governance is orthogonal to correctness.

  



  

  
Multi-Agent — separating the maker from the verifier


  


    The making agent and the verifying agent are separated, so no agent can approve its own work

    by itself. blind-author goes one step further — the agent that writes the tests

    has no tool to read the implementation at all (no Read/Grep granted). "Written without seeing the implementation" becomes a structural fact, not a promise.

    This separation aligns with the segregation-of-duties principle that regulatory · audit frameworks (EU AI Act · SOX) call for — it maps onto the spirit of those frameworks, not a certification.

  


  


    Agent separation of duties — orchestrator distributes, planner/developer/reviewer work, blind-author writes tests without seeing the implementation, observability observes

  



  

  
Ecosystem


  
cladding sits at the junction of three existing categories.


  


    Ecosystem Venn — cladding at the junction of three categories: SDD · runners · multi-agent governance

  



  
Differences from adjacent tools


  
    

        
  • 

    Spec Kit · OpenSpec · Tessl · Kiro — tools that help you write specs well. On top of that, cladding keeps automatically cross-checking that the spec and the actual code don't drift, inside the development loop.
    • 

        
  • 

    BMAD · ChatDev · Claude Code Agent Teams — systems for dividing roles among multiple AI agents. cladding's agent division of labor operates on top of that, combined with spec · gate · audit record.
    • 

        
  • 

    tdd-guard — a tool that forces the AI to write tests first. cladding's Unit · Coverage · oracle stages among the 15 do the same thing more structurally.
    • 

        
  • 

    OpenHands · Cline · Aider · Goose — runners that make the AI write code. cladding is the upper layer that verifies and controls the code those runners write.
    • 

      


  
cladding's distinction is the combination — tying the core of the above categories into one verification loop.



  

  
Install


  
Two steps — install the infrastructure → create the project spec.



  
Step 1 — Install the infrastructure (npm)


  
npm install -g cladding   # install the cladding CLI

cd <project>                # move into your project

clad setup                  # auto-wire AI tools (Claude / Codex / Gemini / Cursor)



  

    Where clad setup wires (4 hosts · 5 connection points)

    

      Host (when detected)Wire locationAuto-activation

      

        Claude Code (~/.claude/)~/.claude/plugins/claddingclaude plugin marketplace add + install

        Codex CLI skills (~/.agents/)~/.agents/skills/cladding-*(automatic on Codex restart)

        Codex CLI MCP server (~/.codex/)[mcp_servers.cladding] in ~/.codex/config.toml(the TOML entry itself)

        Gemini CLI (~/.gemini/)~/.gemini/extensions/claddinggemini extensions link

        Cursor (~/.cursor/)mcpServers.cladding in ~/.cursor/mcp.json(the JSON entry itself)

      

    

    
clad setup auto-invokes each host's activation command when the claude / gemini binary is on PATH. It's safe to re-run after an upgrade or after installing a new AI tool.


    
Verification level (honest disclosure): Claude Code is verified across all features through real-usage campaigns (including real-time intervention). Codex · Gemini CLI have their wiring automated + basic behavior confirmed. Cursor wires automatically but is not yet real-usage verified — to be updated as verification lands.


    


About the MCP server. All 4 hosts wire cladding as an MCP server — only the wire location differs. MCP is not something the user calls directly — there's no /mcp slash, no manual connection step. Each host's AI calls cladding's features on its own in response to natural-language requests, while the user types just one /cladding:init and ordinary conversation.


  



  
Step 2 — Init (create the project spec)


  
In the project directory, called once from inside the AI tool:


  
[inside the AI tool] /cladding:init "B2B payments SaaS"


  
The project's spec.yaml and related docs are created — once per project.


  
To raise enforcement: clad init --with-hook (installs pre-commit + pre-push git hooks) · clad init --with-ci (scaffolds the CI gate — real enforcement lives in CI).



  
Three init scenarios


  

    

      Starting situationCommandWhat happens

    

    

      When you only have an idea/cladding:init "I'm going to build a B2B payments SaaS"LLM analyzes the domain → auto-generates spec · docs · policy + 2–3 follow-up questions

      When you have a planning doc/cladding:init docs/plan.mdRecognizes the file path → auto-loads its content and uses it as intent

      Adopting into an existing project/cladding:init "apply cladding to this project"Auto-scans the existing code → combines observed patterns + intent

    

  



  
One init and you're done


  
Init once and that's it — after that you develop as usual. cladding runs the before/after loop in the background, so there are no commands to memorize.



  
Upgrade


  
npm update -g cladding     # 1. install the new version

cd <your project>          # 2. once per project

clad update                # 3. tidy up for the new version


  
Your code · spec.yaml · docs are left untouched, so it's safe; and if a stricter new version has something to point out, it only tells you (it won't block or fix).



  

  
Status



  

    

      

        
version


        
v0.8.2


        
2026-07


      

      

        
conformance


        
L4


        
highest of L0–L4 · self-declared


      

      

        
tests


        
2392/2392



        
all pass


      

      

        
gate


        
15 stages



        
41 detectors


      

      

        
features


        
245


        
242 done · self-spec


      

    

  



  
226 test files · coverage drop blocked by the COVERAGE_DROP detector



  


The road to Ironclad 1.0 — 1.0 locks only when two independent implementations pass the L4 verification set (GOVERNANCE § 1). cladding is the first.



  

  
Docs


  



  

  
License


  
MIT. LICENSE · related: Ironclad (the standard being implemented) · harness-boot (seed).



  

    cladding · MIT License