Google ADK and Forge Versonas (orientation)

This page situates Google’s Agent Development Kit (ADK) next to Forge SDLC and Versonas — discipline contracts with phase-aware review and structured output — without replacing Forge terminology or methodology.

Google ADK and Forge Versonas (orientation)

This page situates Google’s Agent Development Kit (ADK) next to Forge SDLC and Versonas — discipline contracts with phase-aware review and structured output — without replacing Forge terminology or methodology.

What ADK is here

  • ADK is an optional runtime / orchestration layer (workflow agents, tools, artifacts, callbacks). It does not replace Forge: Ore → Ingot → Spark → Charge → Done → Released stays the work model; do not introduce a second task hierarchy or duplicate your WBS.
  • Versonas are not “generic agents.” They are Forge discipline lenses with scope boundaries, bridge-aware phase depth, and (when you use the standard report) §5-shaped output: concerns, evidence requests, recommendation, optional suggested next Versonas. See the contract in blueprints: blueprints/sdlc/methodologies/forge/versona/VERSONA-CONTRACT.md (submodule in this repo).

Today vs future

Surface Role
Cursor .mdc rules + @ Versonas Primary IDE path for interactive discipline review; align active rules with forge/forge.config.yaml when you adopt it (alignment guide in blueprints).
forge-logs/versona/ Session outputs and structured reviews checked into the repo — durable, reviewable.
ADK (optional, later) Same contracts can back discipline services for scripted, CI, or headless runs — dual surface with Cursor, not a separate methodology.

Using Forge Versonas on this site

These generated pages deepen the same ideas (links work on forgesdlc.com and in a local website/ preview):

Shorter hub: Getting started with Forge SDLC · Terminology and lifecycle

First steps with ADK (external)

  • Official docs: ADK documentation · Get started
  • This repository does not ship ADK dependencies by default; treat integration as a phased adoption (spike → pilot → hardening). Verify APIs and stable surfaces against current ADK releases before production use.

Full technical plan (contributors)

The detailed, repo-specific plan (options, ceremonies, guardrails, rollout) lives in GitHub:

forgesdlc — docs/architecture/adk-integration-plan.md

Ground rules (short)

  • Humans own intent, risk, and irreversible decisions; materialize durable decisions in Ember Log, ADR, and Directive patterns — not only in chat or ADK session memory.
  • One WBS / task hierarchy; one set of Spark IDs.
  • Prefer stable ADK primitives first; label alpha / experimental features explicitly if you try them.

Canonical source

Edit google-adk-and-forge-versonas.md first; regenerate with docs/build-handbook.py.