Improve Shared Practices

The framework should become more effective as teams learn which instructions, components, reviews, and verification practices work. A short Product Engineer/architect retrospective creates a path from local lessons to durable improvements without introducing a large process for every project.

Responsible participants: Product Engineer and architect; UX designer or other specialists when relevant.
Inputs: Recent cycle experience, repeated agent errors, review findings, testing gaps, useful local patterns, and maintenance friction.
Outputs: A few concrete improvements, each identified as a local adjustment, a shared-asset proposal, or a decision not to change anything.

1. Identify meaningful friction. Look for recurring ambiguity in specifications, repeated coding-agent mistakes, missing components, unnecessary review delays, and defects that independent testing might have caught sooner.

2. Identify successes worth preserving. A concise instruction, reusable component, better acceptance criterion, or effective review pattern may be valuable beyond the original project.

3. Decide the level of change. Some improvements belong only in a project's own instructions or specifications. Others may benefit multiple applications and deserve proposal as enterprise assets. Avoid promoting temporary workarounds simply because they happened to work once.

4. Apply appropriate governance. The architect or relevant enterprise owner evaluates shared changes for generality, compatibility, security, documentation needs, and maintenance responsibility. Protected standards are not silently rewritten by coding agents.

5. Keep the result small and visible. Record the selected action, its owner, and the relevant artifact. A retrospective with no useful change can conclude quickly; it does not need to produce a quota of process improvements.

• “The agent repeatedly created a custom validation routine even though the approved library already supports the behavior.” Possible action: clarify the library's usage guidance.
• “Specifications for role-based actions omitted negative permission cases.” Possible action: improve the feature-specification template.
• “Several pods need the same form component.” Possible action: architect reviews a candidate for enterprise reuse.
• “A one-off client interaction was unusually specialized.” Possible action: leave it project-local rather than expanding shared standards.

Useful decisions have an owner and an appropriate destination; changes to protected shared materials follow normal approval; and no new governance burden has been imposed solely to demonstrate that a retrospective occurred.

Collecting long lists of low-value actions; letting agents change protected instructions autonomously; turning every local exception into a new corporate rule; and failing to update documentation when an approved reusable asset changes.