Skip to content

v1.0-roadmap.md

Latest commit

 

History

History
387 lines (272 loc) · 32.6 KB

v1.0-roadmap.md

File metadata and controls

387 lines (272 loc) · 32.6 KB
Raw

v1.0 Roadmap — Synthesis

Author: Synthesis of three parallel research swarms (current state, unimplemented inventory, market review) Date: 2026-04-30 Source reports:

Executive Summary

ADD at v0.9.4 is a more credible product than its public surface implies. The methodology core is broad and internally coherent (27 skills, 19 rules, two runtimes, GPG-signed releases, 12-job CI matrix, ~120 fixture tests). M3 pre-GA hardening shipped cleanly. But:

  1. Only ~1.5 of 6 of ADD's own published GA criteria are met (per .add/config.json:next_promotion_criteria).
  2. Six release-note claims are partially inert in real use (telemetry contract without consumer emission, Codex hook stderr never reaches the agent, AGENTS.md regen ritual missed since v0.9.1, marketplace install has zero CI smoke).
  3. The market has shifted faster than ADD has shipped. Cloud agents (Claude Code Routines, Cursor cloud), visual multi-agent UX, benchmarked memory layers, skill task-evals + security scoring, and a spec-driven branding war are all 2026-era developments where ADD is invisible or behind.
  4. ADD's moat is real but narrow. The maturity ladder (poc → alpha → beta → ga) is genuinely unique and directly maps to what the Anthropic 2026 Agentic Coding Trends Report names THE problem of 2026: the trust gradient. Most other ADD differentiators (hooks, skill orchestration, AGENTS.md generation) have been absorbed by host runtimes or competing tools.

The path to v1.0 in ≤6 versions is not more features. It is truth-pass + closing the GA criteria gates + reframing the methodology around the moats the market validates + explicit "stop competing, start integrating" decisions for capabilities the host runtimes now do better.

A credible v1.0 ships in 6 releases (v0.9.5 → v1.0.0) over 8–10 weeks, with a calendar gate at ~2026-06-22 (60-day beta-stability requirement). The earliest plausible v1.0 tag date is 2026-06-25 assuming no slip.

Part 1 — The Honest GA State Today

What's met

  • Guardrails CI suite running (.github/workflows/guardrails.yml, ~120 tests across 12+ suites)
  • Maturity dog-fooded (.add/config.json:maturity = beta, exemptions empty)
  • Multi-runtime story is structurally real (Claude + Codex, both compile from core/)
  • 7 M3 specs landed
  • GPG-signed releases since v0.7.2; verified-on-GitHub since v0.7.3
  • Three community contributors shipped (4 in v0.7.x, @tdmitruk in v0.8.0/v0.9.2)
  • Migration chain closed back to v0.5.0 (v0.9.4 hotfix)

What's not met (the GA gates ADD itself published)

Criterion (from .add/config.json:next_promotion_criteria) Status Remediation
Guardrail suite running in CI and release-blocking ✓ MET (running); ◐ release-blocking branch protection still TBD One-shot setup; gh repo edit + workflow promotion
Real Claude + Codex install smoke in CI ✗ NOT MET F-008/F-009/F-010 + AC-022/AC-023; needs containerized runners
Per-runtime capability matrix in release notes ◐ PARTIAL (described narratively) AC-027; small documentation pass
60-day stability at beta ✗ ~4 days elapsed of 60 (started 2026-04-23) Calendar gate; earliest GA = 2026-06-22
Marketplace submission approved ✗ NOT MET (no submission attempted) External; submit ~v0.10 cycle
20+ projects using ADD ✗ 3 known Adoption / marketing problem (Swarm 3 territory)

Four hard blockers (Swarm 1 risk register)

  1. F.1 — Marketplace install has zero CI reproduction. v0.8.1 F-001 was caught by maintainer running claude plugin validate manually post-merge, not by CI.
  2. F.2 — next_promotion_criteria is the project's published GA bar; tagging v1.0 today violates the project's own definition.
  3. F.4 — Stale public surfaces compound: README "11 rules" (actual 19), PRD "v0.4.0 as Next" (actual v0.9.4), getadd.dev footer v0.9.1, AGENTS.md generated marker v0.9.1, core/rules/maturity-loader.md cascade matrix omits 4 v0.9.0 rules.
  4. F.7 — PRD § 4 v1.0.0 description is historic; 6 of 8 listed v1.0 bullets already shipped in v0.7.x–v0.9.x. The PRD does not describe what v1.0 actually means now.

Three honesty-audit findings worth surfacing publicly

  • Telemetry contract present, emission unverified. Even ADD's own dog-fooded .add/ has no telemetry/ directory. The OTel-aligned claim is real-on-paper, not measured-in-use.
  • Codex hook stderr does not reach the agent. v0.9.0 prompt-injection-defense + v0.9.3 secrets-scanner are warn-only on Codex (audit log only, no inline warning). Hard-block on git push deferred to v0.10 (F-012). Anyone marketing "GA security" against OWASP Top 10 Agentic 2026 must own this gap publicly.
  • PR #6's autoload: false mechanism shipped (v0.9.2) but no rule actually uses it yet. The mechanism for cache-discipline-via-on-demand-loading exists; the extraction has not happened. Token-cost reduction from PR #6 is currently 0 in practice.

Part 2 — Three Insights From Synthesis

Insight 1 — The work to v1.0 is mostly truth + integration, not new features

Swarm 1 found the public surfaces drift; Swarm 2 found 9 specs marked "Draft" that are operationally Complete; Swarm 3 found that most ADD-invented features are now table-stakes-in-host. The aggregate signal: v1.0 is a credibility release, not a feature release. Polish, prove, position.

Insight 2 — F-012 hook feedback channel is a force multiplier

Three specs have downstream blockers waiting on F-012 (Codex hook stderr → agent feedback): secrets hard-block, prompt-injection blocking, runtime feedback parity. Closing F-012 closes three partial-state gates at once. Whether this is solvable in ADD or requires upstream Codex CLI work is the v0.10 question.

Insight 3 — ADD's only durable moat is maturity-aware methodology

Every other ADD differentiator (hooks, skill orchestration, AGENTS.md generation, sub-agent dispatch, swarm worktree pattern, multi-runtime adapters) is being absorbed or replicated by host runtimes (Claude Code Tasks, Routines, Plan Mode, Skills, AGENTS.md ecosystem) or competing tools (Cursor 3 Agents Window, BMAD, Spec Kit, OpenSpec, SpecWeave). The poc → alpha → beta → ga cascade is unique to ADD AND directly maps to the trust-gradient problem the Anthropic 2026 Trends Report names as THE 2026 issue. Lean into maturity. Stop fighting on absorbed surfaces.

Part 3 — Must-Have for Viable GA in ≤6 Releases

The version-by-version path. Each release is scoped to land cleanly without rebases against the next; each closes specific GA-criterion items or blockers.

v0.9.5 — Hygiene + Truth Pass (~1 day, 2026-05-02 target)

A single doc-only release that closes the public-surface drift. Already-shipped functionality, just no longer lying about it.

  • Truth pass: README rule count (11→19), README roadmap section (rewrite from "v0.4.0 — Next" to current state), PRD header date + § 4 v1.0 reframe, CLAUDE.md template/knowledge counts, core/rules/maturity-loader.md cascade matrix completed for 4 v0.9.0 rules.
  • Frontmatter sweep: flip 9 specs from Draft/Implementing to Complete (Swarm 2 § A.2 list).
  • Plan closeout: append Status: Complete (vX.Y.Z) to 17 stale plan files (Swarm 2 § F.2).
  • Retire orphans: mark specs/timeline-events.md Superseded with one-line note pointing at telemetry-jsonl + dashboard skill data sources.
  • AGENTS.md regen: python3 scripts/generate-agents-md.py --write so the dog-fooded marker reflects v0.9.5.
  • Architect/Editor model-role rule: the smallest M3 deferral; one-paragraph addition.
  • CHANGELOG entry summarizing all of the above as "v1.0 prep — credibility hygiene."

Not a feature release. Removes the smokescreen so v0.9.6+ work happens against accurate documentation.

v0.9.6 — Post-Release Skill + Release-Blocking Gates (~1 week, 2026-05-09 target)

Operationalize the publication ritual; promote the CI suite from "passing" to "release-blocking."

  • /add:post-release skill (specced at specs/post-release-publication.md, 32 ACs, plan exists). Walks docs/release-materials.md filtered by release type, runs auto-items, prompts on manual items, writes session log at .add/post-release-logs/release-vX.Y.Z.md. Idempotent re-runs.
  • AC-024 — Guardrails release-blocking. Branch protection on main requiring guardrails.yml green + 1 reviewer; release.sh grows gh run list --branch main --limit 1 --json conclusion precondition.
  • scripts/install-claude.sh (AC-028) — public-user install bypassing marketplace auth. Pulls from a tag-pinned URL with checksum. Closes the gap surfaced 2026-04-30.
  • Migrations CI guard (F.9 / F-015 partial). Compile-drift extension: fail PRs that bump core/VERSION without adding a migration entry. Closes the v0.8.1→v0.9.3 silent-skip pattern that surfaced in v0.9.4.

Closes 1 of 6 GA criteria fully (release-blocking guardrails); makes the post-release ritual a first-class skill.

v0.9.7 — Catalog Generation + Site Sync + AC-027 (~2 weeks, 2026-05-23 target)

End the manual-counts/manual-website drift forever. Position the security narrative correctly.

  • F-019 catalog generator — scripts/generate-command-catalog.py is the single source for skill counts, command syntax, risk levels, dispatch policy, write behavior. Consumed by README inserts, marketplace.json description, runtime AGENTS/CLAUDE docs, website inputs.
  • Site metrics generator + skills-page generator — closes the release-materials.md open follow-ups; MountainUnicorn/getadd.dev index.html metrics bar and docs/skills.html are regenerated from core/. Skills count drift closed permanently.
  • /add:announce skill (CHANGELOG → blog post draft). Closes the uneven blog cadence gap; produces blog/<slug>-v<X.Y>.html scaffold the maintainer edits before publication.
  • AC-027 per-runtime capability matrix in release notes template + SECURITY.md reframe. Honestly states: Claude hook stderr surfaces to agent (v0.9.x ✓); Codex hook stderr does not (downstream blocker for hard-block of injection + secrets).

Closes 1 of 6 GA criteria (per-runtime capability matrix) cleanly. Sets up v0.10's F-008/F-009/F-010 work to actually be testable against published expectations.

v0.10.0 — F-015 Config Schema + F-016 Installer Ownership + F-012 Decision (~3 weeks, 2026-06-13 target)

The first release that formalizes contracts. Decision point: whether to land F-012 hook-feedback in ADD or accept it as upstream-gated.

  • F-015 config schema + migration graph validator. New core/schemas/config.schema.json. Migration graph tests prove every supported version can hop to current. Enforces what v0.9.4 patched reactively.
  • F-016 installer ownership manifest. scripts/install-codex.sh writes dist/codex/ownership.json; backups overwritten files; --dry-run; uninstall only owned files. Required before official marketplace approval.
  • F-012 hook feedback channel — research + decision. Two paths:
    • (a) ADD-side polling adapter — Codex hook writes injection events to .add/security/injection-events.jsonl; new ADD-side reader injects unread events into the next user-prompt context. Works without upstream Codex changes. Medium effort.
    • (b) Document the limitation honestly and don't ship a fake fix. Codex stderr does not reach the agent; the audit trail is the user's responsibility to inspect. v1.0 marketing language is "warn-only on Codex; full enforcement on Claude."
    • Recommend (a) if feasible in v0.10 timebox; fall back to (b) if research shows it's brittle.
  • Once F-012 lands (or is officially deferred): secrets-scanner hard-block at git push (closing the v0.9.3 deferral) and prompt-injection escalation from warn-only to blocking on critical patterns.

Optional in this release if scope allows: adapter contract authoritative (F-007) as a foundation for v0.11. If F-007 doesn't fit, defer to a post-v1.0 architectural cycle (it's the right pattern but heavy work).

v0.11.0 — Codex Coherence + Real Install Smoke (~3 weeks, 2026-07-04 target)

The single biggest GA-credibility hardening cycle. Resolves Q-001 (Codex marketplace schema) and ships real install reproduction in CI.

  • Q-001 resolved — Codex packaging format pinned to a current, tested format (current Codex CLI is v0.140+; ADD pin is v0.122). Re-baseline the Codex adapter; either pin to current stable or move to "latest minor of Codex CLI tested in CI."
  • F-008 Codex marketplace/package format — manifests match pinned CLI's actual conventions.
  • F-009 Codex skill policy metadata — agents/openai.yaml shape validated.
  • F-010 Codex hooks/config enablement — hooks installed plugin-relative or safely merged into global config with detection + clear messaging.
  • AC-035 containerized Codex CI runner — Docker image with pinned Codex CLI; runs install smoke + /add-init + skill discovery.
  • AC-023 real Codex install smoke in CI — closes one of the two big GA gates.

Single largest release of the v1.0 arc. Codex coherence is the single biggest credibility risk for v1.0.

v1.0.0 GA — Real Claude Smoke + Release Evidence + Promotion (~1 week, 2026-06-25–07-11 target depending on slip)

The promotion release. Calendar gate is the binding constraint: 60-day beta stability earliest = 2026-06-22.

  • AC-022 real Claude install smoke in CI — containerized Claude Code runner; installs from marketplace; runs /add:init --quick; verifies .add/config.json produced.
  • AC-025 release evidence artifacts — supported runtime matrix, known limitations, install smoke outputs, command catalog snapshot, version map, migration coverage. All emitted at release time alongside the GitHub release.
  • /add:promote --execute --target ga — runs the cascade gap analysis; reads the maturity-cascade matrix; promotes if criteria met. Cascade matrix for ADD itself gets a "plugin-source mode" addendum so cascade rows that assume a deployment ladder (Tier 2-3, two reviewers, daily standups) are explicitly N/A for plugin projects.
  • Marketplace submission — submit to official Claude Code marketplace registry. External dependency on Anthropic review process.
  • CHANGELOG [1.0.0] — release notes that lead with maturity ladder + multi-runtime + structured methodology (the moats), are honest about what's warn-only on Codex (per AC-027), and ship with measurable release evidence.

Calendar gate

The 60-day beta-stability criterion was published 2026-04-23. Earliest honest v1.0 tag = 2026-06-22. The 6-release cadence above lands v0.11.0 at ~2026-07-04 and v1.0.0 at ~2026-07-11, comfortably past the calendar gate.

If the 60-day requirement is renegotiated (the criterion was set by the maintainer, not externally), v1.0 could ship in ~6 weeks instead of 8–10. But: 60 days is the minimum interval for users to actually file regressions, and tagging GA before any beta-cycle bug-find is precisely how projects ship "GA" releases that are really still beta.

Recommendation: hold the line on 60 days.

Part 4 — Capability Family Architecture (v1.0 and Beyond)

The user's stated direction: ADD evolves into "a family of loosely coupled capabilities that enhance agent driven development." Synthesis of Swarm 3 § F + Swarm 2 § C + the M3 milestone "Out of Scope" deferrals.

What stays IN ADD (the canonical core)

These align with ADD's moats, are unique in the market, and are durable across host-runtime evolution:

  1. Methodology lifecycle artifacts — spec, plan, cycle, retro, milestone. These ARE the methodology.
  2. Maturity ladder (poc → alpha → beta → ga) — unique to ADD; trust-gradient implementation.
  3. Maturity-aware rule cascade — load only the rules appropriate to the current maturity level.
  4. Sub-agent role definitions (test-writer / implementer / reviewer / verify) — methodological scaffolding even when host runtimes ship sub-agent dispatch primitives.
  5. TDD-deletion guardrail / test-count gate — load-bearing trust mechanism, demonstrably unique.
  6. Swarm worktree pattern + a NEW live status surface (the gap Swarm 3 § A2 named).
  7. AGENTS.md generation with spec-lifecycle hooks (Swarm 3 § A8 — make it living, not one-shot).
  8. Cross-project learnings library schema — canonical schema, regardless of storage backend (engine becomes pluggable per § F2).

What goes OUT (delegate / integrate)

Capabilities the market does better as standalone tools or where host runtimes have caught up:

  1. Persistent memory engine — Mem0 / MemPalace / Letta / Zep. ADD provides an adapter, not an engine. Default fallback: keep library.json as a deterministic versionable cache.
  2. Eval harness infrastructure — LangChain Deep Agents Eval, Tessl Task Evals, Braintrust. ADD plugs in with a thin core/evals/ directory of behavioral signatures; runs through whichever harness the user already has.
  3. Telemetry backend — OTel emission stays in ADD; storage/UI is Honeycomb/Langfuse/Helicone. Don't build a backend.
  4. Skill registry — Tessl. ADD publishes there; doesn't host.
  5. MCP tool surface — git, filesystem, web fetch. ADD doesn't ship MCP servers for primitives that already exist; uses what's there.
  6. Computer use / visual feedback — Anthropic's beta + Cursor's design mode. ADD invokes when at beta+ maturity; doesn't reimplement.
  7. Code search / repo-map — Aider/Cody/Augment/Sourcegraph. Host responsibility.
  8. Cloud execution / scheduling — Claude Code Routines / Cursor cloud / GitHub Actions. ADD emits descriptors (Routine YAML, GitHub Action workflow, cron expression) so users on any runtime can pick up /add:routine-driven scheduled cycles.

What gets ADDED (the v0.10–v1.x roadmap)

Capabilities ADD doesn't have but the market is converging on. Sized + prioritized per Swarm 3 ranking.

Capability Source Sizing Priority Target
Cloud / scheduled execution adapter (/add:routine) Swarm 3 § A1 Medium MUST v0.11 or v1.0
Skill task-evals + security scoring Swarm 3 § A3 Medium MUST v0.10 (parallel with F-015)
Multi-agent fleet visualization Swarm 3 § A2 Small-Medium SHOULD v0.10 (extends /add:dashboard)
Persistent task DAG with blocked-by edges Swarm 3 § A4 Medium SHOULD v1.0 (bridges to Claude Code Tasks)
AGENTS.md as living artifact (spec-lifecycle hooks) Swarm 3 § A8 Small SHOULD v0.9.7
Plan Mode read-only enforcement Swarm 3 § A9 Small SHOULD v0.10
Built-in eval harness for the methodology Swarm 3 § A5 Large SHOULD v1.1 (post-GA)
Persistent semantic / temporal memory adapter Swarm 3 § A6 Medium COULD v1.1+
Computer use for spec verification Swarm 3 § A7 Medium COULD v1.1+ (beta+ maturity only)
Tool-agnostic skill packaging cleanup Swarm 3 § A10 Medium COULD v1.1+ (audit redundant adapter work)
MCP server emission target Swarm 3 § E5 mitigation Medium COULD v1.1+
Cursor / Cline runtime adapters Swarm 3 § C3 Medium each COULD v1.1+ (validates multi-runtime architecture)

M4 milestone shape (post-GA)

After v1.0 ships, the architectural cycle that was deferred from M3:

  • M4 — Architectural cycle:
    • F-006 host-neutral kernel (extract Claude-shaped terms from core/)
    • F-007 adapter contracts authoritative (compile/install scripts read adapter.yaml as source-of-truth, not hard-coded)
    • ${ADD_HOME} / ${ADD_USER_LIBRARY} neutral path variables
    • Runtime overlay split (per-runtime layered content on top of neutral core)
    • Cursor + Cline runtime adapters as the proof
    • /add:parallel worktree-based parallel cycle execution
    • Capability-based /add:eval skill (after eval harness lands)
    • /add:cycle rename to /add:arc (coordinated with parallel-cycle redesign)
    • Cross-tool memory schema for ~/.claude/add/

This is genuinely M4-sized work. Trying to land any of it in v1.0 displaces the credibility-hardening cycle that v1.0 actually needs.

Family of loosely coupled capabilities — concrete picture

                        ADD CORE (canonical methodology)
                ┌────────────────────────────────────────┐
                │  spec / plan / cycle / retro / milestone│
                │  maturity ladder (poc → alpha → beta → ga)│
                │  sub-agent role definitions             │
                │  TDD-deletion guardrail                 │
                │  swarm worktree pattern                 │
                │  cross-project learnings schema         │
                └────────────────┬───────────────────────┘
                                 │ compile + adapters
                                 ▼
                  ┌──────────────────────────────────┐
                  │  RUNTIME ADAPTERS                 │
                  ├──────────────────────────────────┤
                  │  Claude Code   Codex CLI          │
                  │  Cursor (v1.1) Cline (v1.1)       │
                  │  MCP server emission (v1.1+)      │
                  │  GitHub Actions (Routines target) │
                  └──────────────┬───────────────────┘
                                 │ integrates with
                                 ▼
            ┌───────────────────────────────────────────────────┐
            │  EXTERNAL CAPABILITY LAYER (ADD calls; doesn't build)│
            ├───────────────────────────────────────────────────┤
            │  Memory engines:    Mem0 / MemPalace / Letta       │
            │  Eval harnesses:    LangChain DeepAgents / Tessl   │
            │  Telemetry sinks:   Honeycomb / Langfuse / Sentry  │
            │  Skill registry:    Tessl Registry                 │
            │  Computer use:      Anthropic / Cursor design mode │
            │  Code search:       host-runtime native            │
            │  Cloud execution:   Claude Routines / GitHub Actions│
            └───────────────────────────────────────────────────┘

The "loosely coupled" framing is correct. The core is small and durable; the adapter layer is a thin compilation target; the external capabilities are integrations, not rebuilds.

Part 5 — What We Stop Doing (Swarm 3 § D)

Capabilities to actively retire because the market has moved past them or the host runtimes now do them better:

  1. Bespoke hook system where it duplicates host hooks. Both Claude Code (PostToolUse with duration_ms, etc.) and Codex CLI (stable hooks observing MCP tools and apply_patch) ship robust native hooks. Audit runtimes/{claude,codex}/hooks/ for what's still load-bearing vs. redundant.
  2. Hand-rolled cross-project learning storage. ~/.claude/add/library.json was useful in 2025. Now Mem0 / MemPalace / Letta exist as benchmarked engines. Make storage pluggable; default to library.json cache + memory-engine-of-choice MCP adapter.
  3. Manual SVG infographic regeneration. Auto-generate from a data file; stop hand-tuning offsets. Closes part of F-019.
  4. Rules as the only behavioral surface. Position rules as one layer among (Skills, Rules, Hooks, AGENTS.md, References). The PR #6 references: mechanism is already a step in this direction; lean further.

Part 6 — Where We Double Down (Swarm 3 § C)

The four moats:

  1. Maturity ladder (poc → ga). Lead the v1.0 README with this. Make the maturity cascade visible to users via /add:promote --check and a rendered cascade diagram in docs. The Anthropic 2026 Trends Report calls trust-gradient THE 2026 problem; the maturity ladder IS the trust-gradient implementation.
  2. Methodology as canonical artifact. Position ADD as "the methodology, not the tool." Skills are an implementation detail; the methodology (spec → plan → cycle → retro → milestone with cross-project learning) is the value. This positioning matters because Cursor / Cline / Copilot all have skills; they don't have methodology.
  3. Multi-runtime neutrality from core/. Cursor and Cline runtime adapters in v1.1 prove the architecture beyond Claude+Codex. Talk about ADD as runtime-neutral methodology, not "Claude plugin that also works on Codex."
  4. TDD-deletion guardrail. Document this prominently. Package the test-count gate as a standalone hook that can run alongside any methodology — even users who don't adopt full ADD benefit.

Part 7 — Risks + Mitigations

The eight market risks Swarm 3 named, with explicit v1.0 mitigations:

Risk Severity v1.0 Mitigation
E1. Anthropic native-shipping ADD's features HIGH Reposition: methodology > tool. Map Tasks/Routines/Plan Mode as adapter targets, not competitors.
E2. Codex v0.122 pin brittleness HIGH v0.11.0 re-baselines Codex adapter; CI matrix tests latest minor.
E3. AGENTS.md ecosystem evolution MEDIUM Subscribe to AAIF; make /add:agents-md schema-driven so new sections add via template, not skill body.
E4. Spec Kit + DeepLearning.AI canonical MEDIUM-HIGH Ship Spec Kit compatibility layer (/specify → /plan → /tasks → /implement mapped to ADD flow). Submit a guest lecture / blog post into the spec-driven discourse.
E5. MCP server explosion MEDIUM Expose ADD as MCP server (v1.1). /add:spec, /add:plan, /add:cycle callable from Cursor/Windsurf without installing ADD as a plugin.
E6. Skill marketplace security collapse MEDIUM Submit ADD's skills to Tessl Registry; pursue Snyk security scoring; publish task-eval scores. Be in the trusted corner from launch.
E7. EU AI Act August 2026 MEDIUM (HIGH for enterprise) OTel JSONL emission already 80% of Article 12 logging substrate. Document ADD's compliance posture in SECURITY.md v1.0.
E8. IDE-as-runtime absorption MEDIUM-HIGH long term Be useful WITHIN those runtimes. ADD as methodology layer running on top of any execution runtime; never below.

Part 8 — Open Decisions (Maintainer Input Required)

Strategic forks that need the user's call before v0.10 work can scope:

D1. Hold or revise next_promotion_criteria?

The published GA gates (60-day stability, real install smoke, marketplace approval, 20+ projects) are demanding. They're also defensible. Recommendation: hold all six. Lower the bar and the public credibility argument collapses ("ADD relaxed its own GA criteria to ship v1.0").

D2. F-006/F-007 host-neutral kernel — v1.0 or v1.1?

This is genuinely architectural. Touches every skill body, every rule, scripts/compile.py, both adapter YAMLs, plus a runtime-overlay layer that doesn't yet exist. Recommendation: defer to v1.1. v1.0 is a credibility release; the host-neutral kernel is the right next milestone (M4) but trying to land it in v1.0 displaces the install-smoke + Codex-coherence work that v1.0 actually needs. F-006/F-007 in v1.1 lets v1.0 ship cleanly and v1.1 ship as the architectural milestone with proof (Cursor/Cline adapters).

D3. F-012 hook-feedback channel — ADD-side adapter or document the limitation?

ADD-side polling adapter is doable. Whether it's clean depends on Codex CLI session lifecycle (research not yet done). Recommendation: spike option (a) in v0.10; if research shows brittleness, fall back to (b) honest docs and accept warn-only on Codex through v1.0. Either way, AC-027 makes the difference visible to users.

D4. ADD as MCP server — v1.0 or v1.1?

Exposing ADD as MCP server is mitigation E5 (MCP-server explosion). It's also a v1.1 capability that doesn't gate GA. Recommendation: v1.1. Don't add scope to v1.0.

D5. Brand strategy — ADD-the-plugin or ADD-the-methodology?

Spec Kit + DeepLearning.AI + JetBrains + Anthropic course materials = an industry consolidation around named methodology brands. ADD is currently invisible in this discourse. Two paths:

  • (a) Single brand: ADD-the-plugin. Marketing focuses on the plugin install; methodology is implementation detail.
  • (b) Two brands: ADD-the-methodology (paper / spec / book) + ADD-the-plugin (one implementation). Allows the methodology to be referenced independent of the plugin; opens contributing-to-the-methodology vs. contributing-to-the-plugin paths.

Recommendation: (b), but defer to post-v1.0. v1.0 ships the plugin cleanly; the brand split happens in marketing/docs work that's parallel-but-not-blocking to engineering.

D6. Telemetry self-hosting — opt-in collector or document the gap?

PRD § 3 lists 5 metrics that depend on telemetry aggregation. ADD ships emission but not collection. Recommendation: document the chicken-and-egg honestly in v1.0 release notes; provide a scripts/collect-telemetry.py reference implementation that aggregates .add/telemetry/*.jsonl from a consumer report. Don't claim metrics that aren't measurable; don't pretend the gap doesn't exist.

D7. Calendar gate — hold 60 days or accept beta-skip risk?

Earliest honest v1.0 = 2026-06-22. The 60-day window is the minimum interval for users to file regressions. Recommendation: hold. A v1.0 tagged before any beta cycle finds a real bug is functionally still beta.

⤷ Maintainer override (2026-06-14, supersedes the recommendation above): The arbitrary 60-day calendar floor is dropped. v1.0 is gated on the Anthropic marketplace approval (criterion #5) instead — an external, non-arbitrary signal — together with the remaining substantive criteria (#1–#4, #6: release-blocking guardrails, real install smoke, capability matrix, beta-evidence bundle, external-use attestation). Rationale: the marketplace review is itself a real-world gate and its timeline already provides a natural stabilization window, making a separate fixed-day floor redundant. Accepted trade-off: GA could tag with fewer elapsed beta-days than 60 if approval lands early; the substantive criteria (esp. install smoke + the beta-evidence bundle requiring ≥3 clean releases) remain the regression safeguard. The binding constraint is now marketplace approval, not the calendar.

Closing

ADD at v0.9.4 is a credible beta. v1.0 is reachable in 6 releases over 8–10 weeks, gated by a 60-day calendar floor. The path is mostly hygiene + integration + Codex coherence + truth-in-marketing — not new features. The capability family direction is correct: small canonical core, thin adapter layer, integrate with the external capability layer the market builds better.

The four moats — maturity ladder, methodology lifecycle, multi-runtime neutrality, TDD-deletion guardrail — are durable. Lean into them. Stop competing where hosts now do better. Position ADD as the methodology that runs on top of any execution runtime, never below.

The most important single insight: the market is moving toward the trust-gradient as the 2026 problem, and ADD already shipped a trust-gradient implementation in 2025 (the maturity ladder). The case for v1.0 GA is not "ADD has more features" — it's "ADD has the right concept and proves it."

Next Actions (if maintainer agrees with this synthesis)

  1. Make decisions D1–D7. ~30 min of conversation.
  2. Open docs/milestones/v1.0-ga.md as the canonical milestone doc, sized 8–10 weeks across 6 releases.
  3. Begin v0.9.5 hygiene release. Smallest scope, doc-only, dog-foods the upcoming /add:post-release skill informally.
  4. Promote /add:post-release spec from Draft → Approved. v0.9.6 work.
  5. Draft /add:announce spec. Unspecced today; needed for v0.9.7.
  6. Spike F-012 ADD-side polling adapter (D3 decision).
  7. Decide on Cursor/Cline adapter timing for v1.1 milestone shaping.

The synthesis is complete. The path is clear. The 60-day calendar is the binding constraint. Everything else is execution.