Product Main Repository Change Workflow Template

Use this template for docs/development/ProductChangeWorkflow.md or equivalent workflow pages in product-main repositories.

# Product Main Repository Change Workflow

This workflow defines how `<product-main-repository>` plans, coordinates, tracks, and closes product-level changes across implementation repositories.

`<product-main-repository>` owns product coordination for `<product-name>`. It does not own implementation code.

```mermaid
flowchart TD
  request["Product request"] --> scope{"Scope?"}
  scope --> small["Small product-doc change"]
  scope --> large["Feature or cross-repository change"]
  small --> docs["Update product docs"]
  large --> impact["RepositoryImpact.md"]
  impact --> tasks["HandoffPrompts.md, GitHubTasks.md, tasks.yml"]
  tasks --> issues["Implementation repository issues"]
  issues --> project["Product GitHub Project"]
  project --> progress["Progress.md"]
  progress --> review["ReviewChecklist.md"]
```

## Responsibilities

This repository owns:

- product goal and acceptance criteria
- product architecture and capability map
- product repository registry
- repository impact analysis
- GitHub issue and GitHub Project task coordination
- product progress and release readiness

This repository does not own implementation code. Implementation work belongs in the implementation repositories listed in the product repository registry.

## Change Sizes

Small product-main changes can be planned inline when they only update product docs, prompts, templates, or project metadata.

Use the large workflow when work affects product behavior, multiple repositories, shared contracts, repository ownership, capability ownership, release readiness, or unclear product requirements.

## Large Product Change Folder

Use:

```text
docs/changes/<YYYY-MM-DD-feature-name>/
  BrainDump.md
  FeatureBrief.md
  RepositoryImpact.md
  HandoffPrompts.md
  GitHubTasks.md
  Progress.md
  ReviewChecklist.md
  tasks.yml
```

## GitHub Task Handoff

Each implementation task should include:

- Product Feature ID
- Product Change Folder
- target repository
- repository-owned scope
- acceptance criteria
- docs impact
- verification expectations
- product-main sync requirements

## Docs Parity

Keep product docs, product repository registry, product capability map, GitHub issues, PR completion reports, GitHub Project fields, and product-main progress docs in sync.

Update `anuva-engineering-handbook` when shared Anuva process, templates, prompts, skills guidance, publishing structure, or registry rules change.

## Completion Criteria

A product-main change is complete when:

- product-level acceptance criteria are satisfied or explicitly deferred
- implementation repository issues and PRs are linked
- GitHub Project fields reflect current status
- verification results are recorded
- progress and review docs are updated
- remaining risks and follow-ups are recorded