# Weekly engineering review loop

## Purpose

Run this review once per week to improve how ASysT is built, tested and released. It is not a changelog,
status summary or product review. It must identify repeated waste, weak evidence and avoidable failure
patterns, then convert them into a short, ranked action list.

The default is **automation-first**. Recommendations such as change-aware verification, isolated browser
shards and exact-surface regression proof are agent-owned checks. They must not add routine owner approvals
or manual acceptance. Human input is requested only for subjective product judgement, an external action,
or explicit public-release authorization.

## Evidence window

Use the seven calendar days ending on the review date:

1. repository-related Codex conversations;
2. commits, tags, release notes and the current relevant diff;
3. focused-test, smoke and full-test ledgers;
4. CI/release stage timings, failures, retries and retained artifacts;
5. the current agent brief and only the skills implicated by the findings.

Prefer compact derived evidence over raw logs. Count retries, total failed wall time, repeated fixes,
slowest stages and frequently changed files. Read a full log or conversation only when the compact evidence
cannot establish the cause.

## Knowledge ownership

These records are complementary and must not mirror each other:

| Record | Owns | Must not become |
|---|---|---|
| Git commit message | Permanent, atomic description of what one commit changed and why | A current-status handoff |
| `.Asyst_LLM/Journal.md` | Current decisions, proof and constraints maintained by the orchestrator/owner | A second Git log or list of every completed fix |
| Weekly report | Cross-task patterns, measured waste and ranked process actions | A summary of all work completed |
| Canonical `_Docs/` document | Durable product, architecture, test or pipeline contract | A weekly observation log |
| Skill | Concise execution procedure and hazards for its subsystem | A duplicate of canonical documentation |

The Assistant does not edit the Journal. It reports durable outcomes to the owner/orchestrator, who decides
whether the next task needs them there. The weekly review may cite Journal state but does not copy it.

## Required report

Create one dated Markdown report in this directory. Put a single action table immediately below the title
with: priority, action, evidence, expected benefit and status. Use `P0` for next-week critical work, `P1`
for important follow-up and `P2` for measured but non-urgent work. Status is one of `Proposed`, `Accepted`,
`In progress`, `Done`, `Deferred` or `Rejected`.

Then answer only:

1. Where did we lose the most time?
2. Which bugs or misunderstandings repeated, and why?
3. What should be added or changed in our agent instructions or skills?
4. Which tests are missing, redundant or low-value?
5. Which CI/release steps are slow, duplicated or unnecessary?
6. Can release publish the exact artifacts already validated by CI instead of rebuilding?
7. Where did we waste AI tokens, and how can smaller context, scripts, targeted commands or better skills reduce it?
8. What should we stop doing, start doing and keep doing?

Every recommendation must include evidence from the week, a concrete change, expected benefit and priority.
Finish with the five highest-value actions for the next week. Be concise, critical and specific; omit
generic advice and work that produced no actionable lesson.

At the next review, reconcile the previous action table first: mark outcomes and carry forward only actions
that remain valuable. Do not silently repeat an unowned recommendation week after week.
