Skip to content

ROADMAP.md

Latest commit

 

History

History
77 lines (51 loc) · 4.45 KB

ROADMAP.md

File metadata and controls

77 lines (51 loc) · 4.45 KB
Raw

AgencyOps roadmap

This roadmap grows AgencyOps in response to real work. It is a sequence, not a promise to create every possible agency document.

Operating rules

  • Work on the current phase before expanding the next one.
  • Add a document only when it will be used in an active or immediately upcoming workflow.
  • Limit each change to one operational problem when practical.
  • At the end of each phase, remove duplication and defer anything without a clear owner.

Phase 0 — Foundation

Goal: establish the repository contract without inventing processes.

  • Define scope, structure, operational knowledge model, document lifecycle, and naming conventions.
  • Add contributor guidance for humans and AI assistants.
  • Establish a staged roadmap.
  • Choose initial maintainers and the pull-request approval rule.
  • Add lightweight Markdown link and style checks when the first operational document is introduced.

Exit condition: contributors can decide what belongs here, where it belongs, and how it should be changed.

Phase 1 — Delivery baseline

Goal: describe the minimum shared path and quality bar for delivering one web project.

  • Create standards/definition-of-done.md from a completed project's actual acceptance checks.
  • Create sops/project-lifecycle.md with phases, owners, entry conditions, and exit conditions.
  • Create templates/project-brief.md only after the lifecycle identifies its required inputs.
  • Adopt and test templates/PROJECT.md as the living operational record on one project.
  • Use all three on one project and record friction as issues rather than immediately adding more documents.
  • Review after the pilot; merge overlap and remove steps that were not useful.

Exit condition: one project has used the baseline from intake through handoff, and the documents reflect what actually worked.

Phase 2 — Web quality and change safety

Goal: make common quality expectations and project changes predictable.

  • Create standards/web-baseline.md with measurable accessibility, performance, SEO, security, and compatibility expectations.
  • Map automatable requirements to checks used by starters and projects.
  • Create sops/change-control.md from real scope-change and approval needs.
  • Add no more than two supporting templates, and only where repeated manual recreation is evident.
  • Pilot the standards on a second project and resolve conflicts with the Phase 1 baseline.

Exit condition: two projects can apply the same quality baseline and handle a change without relying on undocumented knowledge.

Phase 3 — Astro starter contract

Goal: connect policy to executable starter repositories without coupling their source histories.

  • Create starters/astro-contract.md defining required capabilities, checks, metadata, and allowed deviations.
  • Define the minimal agencyops.json schema and include the adopted AgencyOps release or commit.
  • Adapt one Astro starter as the reference consumer.
  • Verify that canonical prose remains in AgencyOps while enforcement remains in the starter.
  • Document the upgrade procedure using one real AgencyOps baseline change.

Exit condition: a starter declares its AgencyOps baseline, enforces objective requirements, and can be upgraded through a reviewed process.

Phase 4 — Operational depth

Goal: add guidance only in areas where repeated work or mistakes justify it.

Choose the next item from evidence gathered in projects; do not pursue all tracks at once.

  • Add the highest-value missing process, likely discovery, launch, handoff, support, or incident response.
  • Write a playbook when a recurring situation needs judgment beyond a linear process.
  • Record the first consequential repository decision as decisions/0001-short-title.md.
  • Add an ownership review cadence and review current standard documents.
  • Evaluate search, generated indexes, or shared packages only after repository size makes navigation or synchronization measurably difficult.

Exit condition: every added artifact has an owner, evidence of use, and no competing canonical document.

Later, when earned

Possible future capabilities include automated metadata validation, generated documentation indexes, a versioned shared configuration package, structured onboarding paths, and a counsel-approved legal-template library with explicit governance. Adopt them only when the maintenance cost is lower than the demonstrated cost of the problem they solve.