A city purple team shares a git repository where red posts emulation plans and blue posts detections. What collaborative practice does that enable?

Collaborative version control for municipal red and blue artifacts such as emulation plans and detections in a shared git repository is the practice a city purple team enables when both colors commit to one repo. Shared history lets red publish planned techniques and blue publish detections or gaps against those plans, creating a durable purple feedback loop. Version control also supports review, rollback, and onboarding far better than tribal knowledge. Collaborative live editing for municipal red and blue artifacts such as emulation plans and detections in a shared git repository fails by concept: live editing means simultaneous real-time co-authoring, not committed version control with review, rollback, and durable tracking of red plans against blue detections. Collaborative automated execution for municipal red and blue artifacts such as emulation plans and detections in a shared git repository fails by concept: automated execution means running jobs or pipelines, not creating shared commit history for collaborative authoring and review of artifacts. Collaborative access attestation for municipal red and blue artifacts such as emulation plans and detections in a shared git repository fails by concept: attestation is periodic certification of access, not active collaboration with shared history and change review for a purple feedback loop. Exam caveat: a shared repo still needs branch permissions and secret scanning so offensive tooling credentials and sensitive civic data are not casually committed. Operational check: confirm red emulation plans and blue detection content both exist in the shared repository with recent commits, that access is limited to purple participants, and that CI or CODEOWNERS enforce review on changes.