Add explicit documentation sync after implementation changes

[scappuccino-grid]

Addresses inconsistent workspace doc updates by adding an explicit rule to planning_and_documentation_sync_rules and a documentation_sync phase (7b) to coding-flow between validation and user review.

[github-actions]

Rosetta Triage Review

Summary: This PR addresses a gap in the Rosetta coding workflow where workspace documentation files (ARCHITECTURE.md, CODEMAP.md, TECHSTACK.md, etc.) were not explicitly updated after implementation. It adds a new rule to bootstrap-execution-policy.md and inserts a documentation_sync phase (7b) between implementation validation and user review in coding-flow.md.

Findings:

• Change is minimal, focused, and well-targeted (14 additions, 4 deletions across 2 files)
• The new rule 2 in bootstrap-execution-policy.md enumerates specific workspace docs to check, which is clear and actionable
• Phase 7b is logically placed and consistent with the workflow's XML phase structure
• agents/coding-flow-state.md update in phase 7b step 4 matches the pattern used by every other phase in the file
• Minor inconsistency: documentation_sync (phase 7b) has applies="ALL" and delegates to a subagent for MEDIUM/LARGE tasks in its step 2 text, but unlike other delegating phases (e.g., impl_validation phase 7, review_code phase 6), it does not declare subagent and role attributes on the phase tag itself — consider adding them for consistency

Suggestions:

• Consider adding subagent="engineer" (or similar) and role="..." attributes to <documentation_sync phase="7b" applies="ALL"> to align with the existing phase tag convention used by phases 1–3, 5–7, 9–11

Automated triage by Rosetta agent

[scappuccino-grid]

Hey Igor, i know we said just to add "update documentation" at the end of coding flow but i think that this approach could be useful:

• policy file focus only on IMPLEMENTATION.md but others docs could be impacted as well by activities that don't require coding flow (adding a library, clarifying project scope, etc)
• having in "coding-flow.md" a step (7b) that analyze if any change should be mapped in docs seems also useful to me.

[isolomatov-gd]

I wonder why we could not update line 65 of coding-flow.md with just few words:
2. Input: approved specs + plan. Output: working code, build passing.
=>
2. Input: approved specs + plan. Output: working code, build passing, update relevant documentation briefly.

Then line 75:
2. Input: implementation diff, specs, plan. Output: review findings and recommendations.
=>
2. Input: implementation diff, specs, plan, check if documentation is updated, brief, and matches the file intent. Output: review findings and recommendations.

This automatically updates files and reviewer automatically reviews it.