DECA for WorkBuddy (English)

Design and Engineering Are Collapsing Into One Act

Let every design tool plug in, instead of opening another front

Some thinking on the editing scenario that emerges once design and engineering merge — and on where this judgment comes from

billiezhang — creator and maintainer of the DECA paradigm 2026-08-31 · Internal discussion note, for the WorkBuddy direction Updated 2026-08-31 · Added the public Brilliant case and revised the carrier relationship among HTML, design DSLs and the DECA semantic layer Chinese version: deca-proposal-codebuddy.md (primary for delivery; this is the English counterpart)

One-page summary

WorkBuddy's position: the contest is moving from inside the IDE to how everything outside gets in

Three things happening at once.

1. Functional differentiation among AI IDEs is going to zero. Model capability is procured. Completion, multi-file editing, agent mode, terminal integration — whatever one vendor ships this quarter, everyone ships next quarter. The product-layer differentiation window is closing. This is not a forecast; it is the last 18 months.

2. And the handoff between design and engineering is disappearing. Two decades of tooling rest on one assumption: design produces a file, engineering implements it, and a handoff sits in between. AI is dismantling that assumption — once "describing it is changing it" holds, a change made on the design side and a change made on the engineering side become the same act, merely performed in different views. With the handoff gone, the two trades are no longer sequential; they share one editable object. This is not a forecast. It already happens to everyone who edits a page with AI.

3. Yet everyone is currently heading toward opening a new front. IDEs are adding canvases and visual editing; design tools are adding code modes and dev panels. Each is entering the other's home ground — competing at the most expensive point, where muscle memory, plugin ecosystems and years of collaboration history all have to be rebuilt. Meanwhile the cheaper move goes unmade: defining the seam itself.

In one sentence:

The next era does not need more fronts. It needs a confluence point. Once design and engineering merge, the editing surface converges to one — and it is more likely to be the one that runs.

The scenario to define: design-as-code, collaboratively edited

04.1 / The real bottleneck in AI coding is no longer generation quality

Generation quality is good enough. The actual failure point today is that AI does not remember why the last round decided what it did.

An engineer asks AI to modify a page. The AI sees the DOM. It does not see:

• that the entry is collapsed by default because last quarter's major-account complaints clustered on that path;
• that bulk actions require confirmation because risk control demanded an audit trail;
• that the filter is real-time because the dataset is small enough that debouncing made it worse.

So the AI re-derives, guesses, or silently reverts the previous decision. Every iteration pays again.

Design decisions are the highest-value context in this pipeline and the only one still unstructured. Tokens were standardized (W3C DTCG 2025.10). Components got connected (Code Connect). Structure became readable (Figma MCP 2025.9). "Why" did not. That is the open slot.

There are two ways to fill it: build a design tool capable of expressing "why," or define an interface through which any tool can express it. Only the second one pays, for the reasons below.

04.2 / Why the correct move is to let things in, not to build them

Three reasons, each harder than the last.

① Cost of the front. Building a canvas or a design tool means competing head-on with an incumbent: rebuilding designers' muscle memory, the plugin ecosystem, years of collaboration history and accumulated assets. It is the most expensive, longest and lowest-probability path — and even winning it yields only "one more design tool."

② Structural position. The editor is the one place every artifact must eventually land. An image can come from any tool, but it has to become something that runs. A terminus is a confluence point by construction — it need not compete for users, only decline no source.

③ Direction of the era. Once design and engineering merge into a single editing act, the editing surface converges to one. That convergence is not decided by whose canvas is better, but by which side holds the version of the truth that is runnable, checkable and versioned.

Opening a front (expensive, slow, low odds)
  canvas inside the IDE  ←→  code mode inside the design tool
  each entering the other's home ground, rebuilding habits and ecosystems

Being the confluence (cheap, fast, positionally given)
  any design tool / AI image gen / whiteboard / image editor / art plugin
        └──→ one semantic interface ──→ the editor (the mandatory landing point)
  not competing for users; simply being the end that declines no source

04.3 / Defining the scenario: design-as-code, collaboratively edited

This is not an improved "design-to-code." It is a different thing:

This scenario is beginning to be defined in segments, but it has not been closed end to end. Brilliant has productized design as source, an agent-native canvas, Git versioning and design-system constraints; design tools and IDEs are also converging from their respective sides. Yet no one owns the complete seam: how rationale travels from a design source through code mapping, attaches to the production object, and remains effective in the second AI edit. That narrower and more falsifiable gap is the position DECA should define.

04.4 / DECA is the protocol form of that scenario

DECA (Design · Engineering · Context · Architecture) is its standardized form, carrying two duties at once:

• Inward: making decisions inheritable by AI — a semantic intermediate representation (DECA-HTML for new pages, a sidecar next to source for existing codebases) carrying component identity, token references, interaction declarations, validation contracts and, most importantly, decision rationale, versioned across iterations;
• Outward: letting any tool hand its artifact in through the same semantics — that is the adapter mechanism.

Delivered as two entry points:

WorkBuddy (engineer entry)
├── code editing + AI capability      (exists)
└── native DECA capability            (built in, not a plugin)
    ├── DECA CLI                      org-preinstalled, zero config
    ├── DECA MCP Server               callable by AI automatically
    └── adapter layer                 any source plugs in
        ├── design-tool adapter       canvas artifacts
        ├── design-system adapter     component / token constraints (replaceable)
        ├── image & asset adapter     generated art, concept art, atlases (with semantics)
        └── (legacy-code adapter    phase two, see §6 Objection 3)

WorkBuddy (non-engineer entry)
└── the same capability, no-code wrapped
    PM / ops / design say "make me a page" → invoked automatically,
    never touching a command line

The adapter layer is the most easily underrated part of this design: it means WorkBuddy need not predict which design tool wins, nor compete with any of them. Each additional adapter makes the confluence position more secure — and the marginal cost of an adapter is far below the cost of another front.

The CLI is the shared base; the two entries are two postures. Full derivation is attached (1,500+ lines, 39 documented revision rounds). This document covers only the WorkBuddy-relevant part.

Carrier layering: a design DSL is the native source; HTML is the friendly universal form above it

This document no longer describes HTML as the only design source or the only fully expressive carrier. Brilliant's Blueprint is a valid counterexample: a design tool can have its own lossless, versioned native DSL that humans and agents read and write together.

HTML's value is not replacing those DSLs. It is being the friendly universal representation and interchange layer above them: browser-native and runnable, natively legible to AI IDEs, inspectable by people, and already surrounded by mature import, export and framework-mapping paths. It is a lingua franca, not a replacement for every tool's native file format.

DECA therefore does not claim that every design must become HTML. It claims that, whatever the native source, decision semantics must not disappear when that source enters engineering through HTML or an equivalent interchange form.

04.5 / Where phase one lands: AI already generates HTML — it just has no context

The above describes the end state. Phase one deliberately takes only the most tractable slice of it.

Agentic IDEs already generate HTML prototypes at volume — that behaviour does not need to be created; it is already happening. What is missing is not throughput but context: at generation time the model does not know which tokens or components to use; after generation nobody knows why a given decision was made; the next iteration starts from zero. HTML is the phase-one entry because it is the lowest-cost friendly universal form inside today's AI IDE, not because it must replace Blueprint or any other design DSL.

So phase one does exactly three things, each paired with an explicit refusal:

Why "how HTML maps onto each stack" is explicitly handed off. That layer already has competent owners: Figma Code Connect resolves which code component a design component corresponds to; the various D2C solutions resolve how to emit React, Vue or Mini Program code. The point is that the two layers are orthogonal:

Neither of them answers "why." Handing the mapping layer off is therefore division of labour rather than concession — and after the split, the stronger they are, the more the context layer is worth: higher conversion fidelity means less of the carried context is wasted.

This narrowing also dissolves two real organisational problems at once:

• Engineers need not go to the canvas. The assets they need are assembled in; switching to a design tool to read one spacing value is unnecessary;
• The IDE need not fund a design tool. This is not merely saved spend — it avoids the one unwinnable fight: rebuilding designers' muscle memory, the plugin ecosystem and years of accumulated material (see 2.2 ①).

The one constraint that must reach into the mapping layer

Mapping can be delegated. One thing cannot: whether the semantic attributes survive the conversion.

If AI-generated HTML carries data-deca-intent and some D2C tool drops it while emitting React, then traceability holds only inside the HTML and breaks the moment it leaves — and production code is precisely outside the HTML. So the protocol adds one requirement, and only one:

Adapter conformance: converted output must preserve data-deca-* attributes
                     (or provide an equivalent mapping record)

This is DECA's only reach into the mapping layer, and the one place it must reach: it does not perform conversion, it only defines what conversion must not lose. The cost to a third party is close to zero (one attribute name), so there is little reason to refuse — and it doubles as the hook for adapter conformance: with a non-conforming implementation, users discover the failure themselves when the second round of AI edits has forgotten everything again.

04.6 / Relationship to the design system: far smaller than usually assumed

One thing is easy to misread and worth stating plainly: the core of this is not the design system.

In this scenario a design system is one adapter and one default constraint source — it answers "which component, which token." It is useful, it is replaceable, and it is not the protagonist.

Why that is a precondition rather than a weakness:

So the correct use of the internal design system and D2C pipeline is not "this is the moat itself," but: they are the first adapter already proven to work, plus a set of real scenarios available immediately for validation. What they prove is that the path works — not where the value comes from.

This deserves emphasis because it sets the ceiling: betting on the design system yields a stronger design system; betting on the entry protocol yields a position every design tool has to pass through.

04.7 / Codesigner: where the next increment of the market is

The preceding section described the shape of the work. This one describes who it serves — which is what decides whether this is a feature or a market.

04.7.1 / Definition

Two common misreadings need clearing first:

Identifying one takes a single question: **in the same iteration, did this person make the visual judgment and the implementation?** If so, they are already working in this trade — whatever their title says.

04.7.2 / Why this is a market question, not a feature question

The size of a tooling market has always been set by trades, not by features.

The pattern is unambiguous: feature competition redistributes an existing pool; defining a trade creates a new one. Every step change in tooling market size came not from a better feature but from a redefined trade producing reasons to pay that did not previously exist.

04.7.3 / Why this is incremental rather than a reshuffle

This is the claim the section most needs to carry, so it is worth unpacking.

There are only two existing pools today: designer seats and engineer seats. Both are priced, both are divided up, and both are in a price war. If Codesigner were merely a reallocation between them, it would not deserve strategic attention — that is renaming a contest for the same chairs.

But the ceiling on this trade is neither of those numbers:

designers            ← usually a fraction of engineers in an org (~1:10 as a common rule of thumb)
engineers            ← the entire ceiling of the editor market today
people who must ship an interface
                     ← far larger than the engineer count: product, ops, marketing,
                       game design, business owners, indie developers, founders...

What matters is that the last group sits in neither pool today: they do not buy design-tool seats (too hard to learn) and they do not buy editor seats (they do not write code). Their interface needs are met today by queueing for engineering or making do with a template. The moment the Codesigner trade exists, they become serviceable for the first time — that is pure increment, not transfer.

One consequential shift in the business model deserves noting: **the unit of pricing may move from seats to editable objects / iterations.** A single Codesigner works across many objects, and each object keeps producing semantics and revisions. Moving from per-seat to per-activity is an improvement in revenue structure, not merely in user count.

04.7.4 / Why this trade structurally requires DECA

This is where the section joins the previous one, and it is the load-bearing point of the whole argument.

Under the traditional division of labour, a lost judgment is recoverable: an engineer can ask the designer "why is this like this," and the designer can ask product. The handoff is expensive, but it doubles as a queryable human index.

In the Codesigner mode the handoff is gone — and that human index goes with it. The person to ask is oneself, and people forget.

Which yields a conclusion that is counter-intuitive but hard:

Merging the two trades incidentally deletes the only decision-memory mechanism the organization had. Whoever drives that merge has to restore the memory at the same time.

That is precisely what DECA does. Its positioning therefore needs one correction:

The difference is practical. Absent infrastructure, a trade appears only as scattered exceptional individuals — those people are already visible today, held together by personal memory and self-built scaffolding (the signal recorded in §5b is exactly a Codesigner building a memory layer because no tool provided one). Only once the infrastructure exists does the trade turn from "a few capable people" into "a serviceable population" — which is what a market is.

04.7.5 / Honest boundary, and how to observe it

The claim must be narrowed hard, or it becomes attractive and untestable.

Codesigner is not a job posting today, not a level, not a headcount line anywhere. Any claim that the trade already exists overstates.

What is observable is only the behaviour: one person making the visual judgment and the implementation within one iteration. So the claim here is not "this trade exists" but something narrower:

The behaviour is already happening, and tools are beginning to acknowledge it; no tool yet gives it decision memory that survives carriers and iterations.

Accordingly it needs a falsifiable readout rather than a narrative. Section 7 therefore gains metric 7:

If that share is low, the merge has not actually happened, and the Codesigner argument should be downgraded — not renarrated to fit.

04.7.6 / What this means for WorkBuddy specifically

The market for AI IDEs today is developer seats, and that pool is being compressed by a price war: features converge, models are procured, per-seat price trends down. Executing better inside that pool has a bounded return.

Codesigner is the only direction that expands this market structurally, because it turns "people who must ship an interface but do not write code" into editor users — not by lowering the bar until they learn to code, but by making the editable object operable through non-code views.

WorkBuddy is already an early form of this. But its current positioning carries one decisive skew:

That skew decides whether this is a feature or a business line. With the same capability: read the first way, it is absorbed into the IDE's feature list; read the second way, it earns its own market definition, its own metrics and its own growth curve.

This is consistent with being the confluence point: the plug-in position is how the Codesigner trade is captured. Every design tool that plugs in adds a group of people who can close the loop from judgment to implementation inside the editor — adapters are the supply side, Codesigner is the demand side, and they are two ends of one thing.

Why the first version must grow here: the first mover defines the schema

05.1 / This has not been completed because it is an organizational problem, not a technical one

Every prerequisite just became available: token standard 2025.10, AI reading structured design context 2025.9, generation quality 2025, intent expression standards 2026. The window opened less than a year ago.

But timing is not the real reason. The real reason is that the work crosses three organizations measured differently.

Each team is rewarded for its own segment. No team is rewarded for the seam. Blueprint-like design sources, D2C mapping layers and AI IDE production entries can therefore succeed independently, while the seam that keeps decision rationale inheritable across all three remains empty — and DECA lives in that more precise seam.

05.2 / One of very few organizations that controls the full chain

Becoming the first implementer requires four conditions simultaneously:

Almost no other organization has all four. Figma lacks ③ (and has a structural gap reaching engineers), Vercel lacks ①, Google lacks ①③④.

05.3 / On Figma: not competition — sequencing and division of labor

Stating this plainly matters, because it determines the pacing.

Figma is the appropriate party to eventually scale this protocol globally — global distribution, the canvas, enterprise trust. But the first version of the protocol will not emerge there, for structural reasons:

So the correct sequencing is:

First protocol version  →  emerges inside an org that controls the full chain (us)
                           prove the workflow, settle the schema, accumulate
                           real cases and semantic data
Global scale-out        →  after open-sourcing, amplified by a global vendor
                           what we retain: protocol definition rights,
                           the reference implementation, first-mover cases

First mover defines the schema. Protocol contests are never won on "whose technology is better" — they are won on "whose schema became the de facto standard." We have a window advantage, and that window is measured in quarters.

05.4 / An easily overlooked strategic hook

This is a rare opportunity for a domestic toolchain to export a standard.

Our habitual position is "follow and adapt to international standards." What makes DECA different: the prerequisites just matured, no one has built it whole, and we happen to hold all four conditions. If the first version emerges here and is accepted as open source, WorkBuddy's identity shifts from "a domestic AI IDE" to "the definer of the design-collaboration protocol for the AI era."

That identity is worth far more than a feature module.

05.5 / Where the moat is: three classes of asset

Any proposal that opens a protocol has to answer one question directly: if everything is public, why does the first mover win?

The answer is to separate the assets — what should be copied and what cannot be copied are not the same things at all:

The relationship between the first two rows is the whole model: attributes are the container, the corpus is the content. Copying an attribute name takes five minutes, but the copier's hands are empty — without real projects having filled it in, there is no way to know what people actually write there, or which phrasings the AI genuinely uses.

Row ④ is the most underrated:

The first mover's largest advantage is not knowing what to do; it is knowing what not to do.

A follower receiving v1 will dutifully implement all three attributes. Whoever ran the validation may instead have learned that one of them decayed to zero and should be deleted, while another needs splitting in two. "Which path is dead" cannot be read out of any document; it can only be earned by running real projects — the one time advantage that cannot be compressed.

An existing precedent: data-testid was never owned by anyone, yet it became the default. A convention does not need exclusivity to hold a position.

05.6 / Sequencing: validate first, open second

The timing of open-sourcing is not a secrecy question; it is a question of lock-in cost:

Once a protocol has an installed base it can no longer be changed. Open-sourcing before metric 1 is validated risks being permanently locked into a wrong schema — one propagated by its own author — if it later turns out the AI never used the prior round's rationale.

This is the same principle as Section 7's "if metric 1 fails, the direction should stop": what has not been validated should not be standardised.

Validation    Private validation · 3 AI-generated new projects · metric 1 only
              Externally: the shape only, not value syntax or extraction rules
              ↓ metric 1 ≥ 85%
Once it holds Open-source DECA-lite: format + attribute names + CLI validator
              The goal is not protection; it is claiming the de-facto-standard slot
              ↓
Later         Reference implementation and adapter SDK opened progressively,
              with active outreach. Extraction pipeline, corpus and Registry
              stay on the enterprise side

In this sequence, open-sourcing is an offensive move, not a defensive one. The moment metric 1 clears, the problem changes from "afraid of being known" to "afraid of not being known."

Why this analysis comes from where it does

Which raises a fair question about this document itself: the window has been open for a year — why is this analysis coming from me rather than from the design, engineering or AI team?

The answer is not insight. It is position.

Each team sees its own segment clearly and has every reason to optimise it. What none of them routinely sees is the seam — because the seam sits in no one's KPI, and nothing about a well-run organization surfaces a problem that belongs to no one. A design system owner does not feel the cost of AI re-deriving intent. An AI toolchain author does not feel the cost of a designer's rationale evaporating. Both costs are real; neither lands on a desk.

I happened to sit at all three desks at once — maintaining the design system, writing the D2C pipeline beneath it, building the AI toolchain that consumes it. Not by design, and not as a credential; it is simply the vantage point from which the seam is unavoidable. Standing there, "design decisions are never inherited" is not a strategic insight. It is a daily annoyance. This document is what that annoyance became after a year of being written down.

And the signal in §5b shows that other teams are hitting the same seam independently and patching it themselves. They see the pain in their own segment, not that it is the same seam others hit — a second illustration of position determining visibility.

So the honest framing here is not "the organization needs a boundary-crosser." It is narrower and more verifiable:

This class of problem tends to be articulated by whoever happens to stand at the intersection — and articulating it is cheaper than negotiating it. A cross-functional program must first agree the seam exists; someone already standing in it starts from that assumption. On a window measured in quarters, that head start is roughly the length of the window itself.

What follows is not a case for assigning this to me. It is the record that produced the analysis — offered so the reasoning above can be checked rather than trusted:

Evidence: ~55% of DECA is already running code

Measured results from what already exists: a representative build path went from ~48 hours to ~0.5 hours; fidelity holds above 90% with a best case of 99.9; approximately ¥10.74M in labour cost avoided over a two-month window, with a Token ROI of roughly 761×; training and documentation reached 1,015 attendances at an average dwell time of 36 minutes; skills downloaded 1,500–2,000+ times by other teams — meaning adoption happened without me in the room.

What this table means: DECA is not a vision that takes years before its shape becomes visible. It is a partially-shipped system with a scoped remainder. Those two differ by an order of magnitude of risk.

On the "visual direct-edit" row. It was an individual exploratory build: it demonstrated that the path works, but it has not been used by multiple people across multiple projects. It is therefore marked prototype only and not counted as delivered capacity — the running share is computed on that basis at ~55%.

The one irreplaceable property of this document is that it can be falsified. If the "running" column contains an individual exploration, what is lost is not that row but the credibility of the whole table — including the parts genuinely in production. The number is smaller; every cell now holds.

07.1 / What I read from the field: demand is emerging bottom-up

Beyond my own work, I track one class of signal. It says more about "should we do this now" than my own track record does — because I did not drive it.

The signal: teams sitting outside the design-to-code chain — asset production, illustration, game art — are quietly building semantic persistence into their own tooling. Not AI generation features. Semantic persistence.

There is a recent internal instance (someone else's independent work, not mine; team and implementation withheld here): a small editor plugin whose authors independently arrived at three mechanisms with no protocol guidance at all:

Their founding insight: an irregular selection fed to the model without its surroundings produces poor output — the object needs its context. That is the spatial edition of DECA's central claim.

What it does not do (the crucial part): provenance becomes queryable, not inheritable. It answers "which prompt did I use last week," but the next revision does not automatically carry the previous constraints. Queryable is an archive; inheritable is a paradigm. That distance is exactly what metric 1 in Section 7 measures.

Three implications:

1. Demand is emerging bottom-up and does not need to be created. Nobody sold them a protocol — they hit real pain ("a week later, why is this layer the way it is?") and built it themselves. This means DECA is not a project requiring evangelism, but one with existing endogenous demand waiting to be served. The success rates of those two differ substantially.
2. It validates layered isolation. What they grew bears no resemblance to DECA-HTML (editor plugin + file-embedded metadata + coordinate contract, not HTML + semantic attributes + a service). Had the pure-visual domain been "covered" rather than interfaced with, it would have gone wrong — the correct move is to define the interface that meets it. Without this signal, that judgment is easy to invert during implementation.
3. Internally this is the highest-density source of such signals, and nobody is reading it systematically. 6,000+ projects, seven business lines, many in-house plugins and internal tools — in effect, many teams telling us which seams hurt enough to be worth building around. This is what Cursor structurally cannot obtain: not data volume, but the observability of endogenous demand. Reading that ecosystem as a signal instrument rather than a tool inventory is part of what I would bring, and it is cheap — the data already exists.

The general point: I do not bring a case library. I bring the habit of reading independent signals and extracting their structural content — which is how a durable protocol requirement is told apart from a passing tool trend. On a protocol effort, that distinction is worth more than any single case.

07.2 / Latest public-market evidence: Brilliant has productized part of DECA's vocabulary

Brilliant, publicly launched in 2026, is one of the closest independent structural parallels to DECA so far. Its Manifesto explicitly argues that code is becoming a build artifact and that the new source is the contract describing how a product looks and behaves: design is not the code, nor a picture of the code, but the contract above the code.

This is not merely positioning. Brilliant has productized several mechanisms structurally aligned with DECA:

Its strongest support for DECA is that "design as a machine-readable engineering source / contract above code" is no longer only a derived thesis; an independent team is now testing it as a product. It also supports WorkBuddy's confluence strategy directly: external tools should own the native design source they are good at, while WorkBuddy connects through adapters instead of recreating their canvases.

But Brilliant is not a complete DECA implementation. The boundaries matter:

1. **Blueprint primarily records what it is and how it is drawn, not why this decision was made.** Stable refs, tokens, components and layout constraints make structure inheritable, but the public documentation does not yet show the equivalent of DECA's third-layer rationale.
2. Its contract is closer to an executable visual contract. Public validation focuses on the DSL, layout, visibility, tokens and components; DECA additionally targets performance goals, data interfaces, interaction rationale, stakeholders and the Experience Contract.
3. Inheritance of the design source does not prove that rationale survives production code. React/HTML export and agent-readable canvas state exist; whether rationale remains after mapping into a real codebase and is actually used in the second AI pass still requires DECA metric 1.
4. Blueprint is a design-source language deeply integrated with the Brilliant engine; DECA targets a semantic contract across carriers. They should not fight for the same layer: Blueprint can be an excellent native-source adapter, HTML its friendly universal interchange form, and DECA the definition of the shared why that must survive conversion.

The precise WorkBuddy conclusion: Brilliant is not a canvas competitor to copy. It is an upstream design source to connect and independent convergence evidence. The more successful it becomes, the stronger the premise that external design sources will multiply — and the more valuable WorkBuddy becomes as the common semantic entry point.

Five objections I hold against my own argument

A proposal containing only supporting arguments is a sales document and should be discounted. So here are the five strongest objections, found by me, that cannot be waved away.

08.1 / A heavy protocol usually loses to a lightweight convention

Markdown beat DocBook. JSON beat SOAP. data-testid beat every structured test-metadata system. The lightweight convention takes 80% of the value at 5% of the cost, and the complete protocol never enters evaluation.

DECA's full form (six semantic layers + service + registry + CI validators) sits squarely on the heavy side. The real threat is not a competitor completing an open layer — it is a single-file convention like DESIGN.md / AGENTS.md arriving first.

Consequence — this reshapes the plan: ship the lightweight version as the front door.

  · design.deca.md        page-level intent and contract (human / AI / git readable)
  · data-deca-intent      intent, including free-text rationale
  · data-deca-component   component identity
  · data-deca-contract    data and version contract

Install: npx deca init
Payoff:  the next AI iteration knows why the last one decided what it did

Six layers, Context Service and the registry all become the enterprise upgrade path, not the entry requirement. Protocol definition rights come from installed base, not schema completeness.

08.2 / Hand-authored metadata always decays

Intent rationale and experience contracts only pay off if actually filled in, and every comparable system says they won't be: JSDoc, commit conventions, Jira custom fields, a11y labels — all sustained only by enforcement. Asking a PM to hand-enter NPS targets and FCP budgets fails not for lack of tooling but because no one owns those numbers.

Consequence: intent must be captured as a by-product, never typed into a form. The engineer already tells the AI "confirm this one, bulk deactivation is high-impact" — that sentence is the rationale. Capture from conversation history, PR review comments, design QA notes; the human only confirms or rejects. Performance budgets come from monitoring baselines, not input fields.

This is why Section 7 measures auto-capture rate rather than contract completeness.

08.3 / Existing codebases have no entry path (not solved in this phase)

Every example in the blueprint builds a new page. But our real workload is modifying one module inside a large existing application — routing, global state, auth, SSR. There is no "produce intermediate HTML then strip" path there, and reverse-deriving semantics from a component tree hits conditional rendering and dynamic imports.

Consequence: semantics must attach to source as a sidecar (Foo.deca.json beside Foo.tsx), anchored by stable selectors, versioned by git — no intermediate artifact required. This also retires the most fragile mechanism in the original design: stripping at build time and restoring via fingerprint matching produces silent mis-attachments after a refactor — worse than failure, because no one audits a "successful" restore. With sidecars, history becomes git log.

I do not intend to solve this in phase one, and I list it explicitly as a known gap. The reason is the direction of resistance: AI generating HTML prototypes is a behaviour that already happens, and adding a context layer to an existing behaviour is an order of magnitude less work than creating a new anchoring mechanism inside legacy code. Adding to a behaviour that already happens is always easier than creating one.

This trade has a cost: legacy projects are where the revenue is — enterprises do not pay for prototypes. So phase one can honestly be positioned only as "testing whether the core claim holds," not "testing commercial viability." If the core claim does not hold, excellent legacy onboarding is worthless; conversely, once it holds, legacy onboarding is an engineering problem with a known direction.

08.4 / Open-sourcing DECA-lite publishes the roadmap

Once the specification ships, anyone can see where the road leads. On its face this hands competitors the hardest step: working out what to build.

But this objection contradicts the strongest argument in this document, and the two cannot both hold:

Section 3.1 argues that this remains incomplete because it is an organizational problem, not a technical one. Brilliant-like implementations make the statement more precise: individual segments are now buildable by one team; the hard part is closing rationale inheritance across design source, mapping layer, AI IDE and production engineering. If that is true, publishing the intent is largely harmless — a competitor who knows still cannot clear the organizational barrier. Conversely, believing that "being known is dangerous" concedes that this is merely a creative problem, which would invalidate both 3.1 and 3.2.

I keep 3.1 and discard the intuition. More importantly, secrecy here is not a mild cost — it is a guaranteed loss:

DECA's value grows superlinearly with installed base, not with secrecy.

An intent format used by only one party is a format the models do not recognise. The entire claim is that the next AI round reads the previous round's rationale, which requires the model, the IDE and the tooling to recognise the same attribute name. With three competing formats, no model vendor will optimise for any of them — at which point it does not even work well internally.

The closest precedent is LSP: Microsoft open-sourced it completely, JetBrains, Vim and Emacs all implemented it, Microsoft lost nothing, and the reference implementation absorbed the ecosystem precisely because the protocol became the standard. The LSP specification is a document readable in a day, containing no secrets.

The real risk is not imitation; it is an alternative:

The second row is exactly the threat named in Objection 1 (an AGENTS.md-style convention arriving first). The two failure modes call for opposite responses: fear imitation → tighten and defer; fear an alternative → accelerate, publish, arrive first. The real threat is the latter, so secrecy pushes in the wrong direction.

Conclusion: open the specification, control the sequencing (3.6). The one genuinely dangerous scenario is a competitor with far greater distribution moving before validation completes — and the countermeasure for that is not secrecy but completing the validation quickly rather than stretching it across a year.

08.5 / AI-generated prototypes decay into a copy nobody reads

This is the one clear way phase one dies, and it has killed every prototyping tool before it:

**The semantically annotated HTML becomes a copy that lives in parallel with production code and has to be synchronised by hand.**

Once that happens the two diverge — the prototype changes and the code does not, or the reverse — and within three months nobody opens the prototype. This is the shared cause of death across generations of design-handoff tools, and it is the trap built into the phrase "prototype demo."

Consequence: there are only two survivable modes, and one must be chosen explicitly.

A third mode — parallel maintenance — must never exist. It is the path of least resistance, so unless it is explicitly forbidden in the plan, implementation will drift into it.

This also constrains the validation design in Section 7: each of the 3 projects must declare A or B explicitly, recorded as a field in the report. Ambiguity there is where the failure starts.

How to tell whether it holds: DECA-lite and one metric

This does not need a large program approved first. The blueprint's three-stage roadmap is the expansion path after the following is proven.

Configuration: 3 AI-generated new projects / prototypes (each must declare mode A or B from §6 Objection 5 in the report) (no legacy codebases — see §6 Objection 3) · DECA-lite only (3 attributes + 1 sidecar + CLI validator) · no Context Service, no marketplace, no restore. Strip the paradigm to its core claim and test that.

New projects are chosen not because they are easy, but because that is where the real increment is: AI-generated projects are appearing in volume today, and none of them carry any design-engineering context — the largest blank space, and the only scenario that requires persuading no one to change their habits first.

The pass line for metric 1 is set at ≥85%, higher than comparable validations. A pure new-build prototype is self-contained: semantics do not cross frameworks, do not survive large refactors, do not face concurrent multi-person edits. The scenario is simpler than a legacy codebase, so the pass line has to be correspondingly higher — otherwise it amounts to using an easier exam to validate the same claim.

Metric 1 is the only one that matters. Every DECA claim reduces to "design decisions become inheritable." If the AI does not demonstrably use the prior round's rationale, then six semantic layers, Context Service, collaboration seats and DPP are all superstructure over an unproven foundation — and none should be funded.

If metric 1 fails, the direction should stop rather than have its narrative adjusted to fit. An unvalidated paradigm ought to be disprovable — declaring in advance what would count as failure is what makes "it does not hold" a conclusion that can be accepted calmly.

What validating it would take, and what it would leave behind

This section answers one concrete question: what is the smallest cost of measuring the metric in Section 7. Whether a direction is worth trying depends largely on how expensive it is when it turns out to be wrong.

10.1 / The minimum conditions for validation

10.2 / Four things deliberately left out of this phase

Each item below is something normally taken along by default, yet before metric 1 exists it only adds sunk cost.

What these four save is not primarily cost — it is the cost of turning around. As long as no infrastructure has been built and no roadmap has been promised externally, a failing metric 1 can be stopped cleanly.

10.3 / What each of the three outcomes would mean

Three tiers by validation outcome, including the one where the claim fails. An outlook containing only the upside has no judgment value.

One honest note on magnitude. The already-running pieces measured ~48 hours → ~0.5 hours and roughly ¥10.74M of labour cost avoided over two months. Those numbers come from the D2C pipeline and must not be read as the expected return of the DECA context layer — the former saves the cost of building it the first time, while DECA has to prove the cost of changing it the second time. They are different ledgers, and phase one is accountable only for the latter.

Phase one is therefore correctly positioned as testing whether the core claim holds, not testing commercial viability (enterprises do not pay for prototypes; the revenue sits in the legacy scenario — see §6 Objection 3). Separating those two is the only thing here that needs to be understood.

10.4 / Why it is still worth one attempt

Everything above rests on one assumption: that design decisions can be structured and inherited by the next AI round. That assumption may not hold — each of the five objections in Section 6 is sufficient to invalidate part of it.

The reason it is still worth one attempt is plain: being wrong here is cheap, and being right changes the substrate of collaboration. More concretely, even if the core assumption is disproven, none of the following depends on it:

Explorations of a new paradigm rarely land on the first attempt, but they almost never come back empty. The more common outcome is that the original proposition is disproven while the tools and methods grown along the way survive and get used somewhere nobody predicted.

Whether an organisation keeps producing new paradigms depends on whether anyone is working on questions that do not yet have answers. Part of the value of this kind of exploration does not appear in any single result; it appears in whether the organisation retains that capacity.

One sentence

In the next era, design and engineering are not two trades but two views of one editing act — and the handoff between them is disappearing. The correct move is therefore not to open another front (a canvas in the IDE, a code mode in the design tool) but to become the place every design tool plugs into: the editor is the mandatory landing point for every artifact, and a terminus is a confluence point by construction. The scenario to define is design-as-code, collaboratively edited — one editable object, concurrent roles, rationale inheritable by the next round; the vehicle is the DECA protocol, and the first mover defines the schema. **A design DSL is the native source, HTML is the friendly universal interchange form above it, and DECA defines the cross-carrier why that must not be lost. This has little to do with the design system — a design system is merely the first adapter already proven to work, while the real ceiling is editor installed base. The work is blocked on an organizational seam rather than on technology, which is why it tends to be articulated from inside the seam rather than from either side of it. That is the position this analysis was written from, and roughly 55% of the system already runs as a by-product of standing there. Brilliant proves that design-as-source plus an agent-native canvas is already being productized; what remains open is the inheritance loop that carries rationale through the canvas, production code and the next AI pass. And the reason this is now rather than later: the trade that will use it — Codesigner — is forming already; tools have begun to recognize the behaviour, but have not yet supplied its decision memory (§2b). One last point: this is simply a direction worth exploring. The core assumption may be disproven; even then, the toolchain, the adapter mechanism and the record of which paths are dead stand on their own (see 8.4). A new paradigm rarely lands on the first attempt, but it almost never comes back empty — and whether an organisation keeps producing new paradigms depends on whether anyone is working on questions that do not yet have answers.**

billiezhang · 2026-08-04 · Updated 2026-08-31 · Internal discussion note Attachment: DECA Design-Engineering Paradigm Blueprint v4.4 — full derivation, 1,500+ lines, 39 documented revision rounds.