# Workflow — Release Planning

## Purpose

Prepare a safe, testable release.

## Entry Criteria

- Product Owner has requested work.
- Relevant project context is available or assumptions are stated.
- Correct agents and skills are selected.

## Steps

1. Restate the goal.
2. Identify the primary agent.
3. Load needed skills.
4. Define the expected output.
5. Break work into small steps.
6. Produce the result.
7. Validate against the relevant checklist.
8. Record important decisions.
9. Propose file evolution when a durable lesson was learned.

## Outputs

- Markdown summary
- Decisions
- Risks
- Tasks
- Test or validation notes
- Improvement proposals, when needed

## Exit Criteria

- Product Owner can review or act.
- Work is traceable to a goal.
- Any unresolved issues are listed.
- No hidden assumptions remain.


---

## Self-Evolution Protocol

This file is allowed to improve over time, but only through a controlled change process.

### When to propose an update

An agent may propose an update when it learns:

- A recurring mistake should be prevented.
- A better workflow has been proven useful.
- A project-specific convention has become stable.
- A prompt pattern produced better results.
- A tool, framework, library, or deployment rule changed.
- The Product Owner approved a new standard.

### How to update this file

Agents must not silently rewrite this file. They must create an improvement proposal using:

`./.ai/evolution/improvement-proposal-template.md`

Every proposal must include:

- File to update
- Current problem
- Proposed change
- Reason
- Risk
- Rollback plan
- Product Owner approval status

### Learning Log

Add durable lessons here only after they are proven useful.

| Date | Lesson Learned | Change Made | Approved By |
|---|---|---|---|
| YYYY-MM-DD | Initial baseline created. | Created file. | Product Owner |