Branch and Workflow Plan¶
Example purpose¶
This artifact defines the repository workflow for controlled implementation.
The goal is to keep implementation traceable: work items connect to branches, branches connect to commits, commits connect to PRs, PRs connect to design and verification evidence, and merge decisions preserve LMU/COICP guardrails.
Project¶
LMU Campus Operations and Incident Coordination Platform
Document control¶
| Field | Value |
|---|---|
| Artifact owner | COICP Product Engineer |
| Primary reviewers | Architecture Review Board chair, IT security reviewer, AI reviewer, Compliance reviewer |
| Status | Accepted for ES-106 readiness baseline |
| Last updated | 2026-07-06 |
| Related Engineering Stage | ES-106 — Implementation Readiness |
| Project workspace target | docs/project-workspace/implementation/branch_and_workflow_plan.md |
Implementation context¶
| Field | Value |
|---|---|
| Source design package | ES-105 Design |
| Implementation readiness stage | ES-106 — Implementation Readiness |
| Controlled implementation stage | ES-107 — Controlled Implementation |
| Implementation baseline produced | LMU-COICP-IMPL-001 |
| Integrated baseline expected next | LMU-COICP-INT-001 |
| Candidate expected after testing | LMU-COICP-RC-001 |
| Downstream release posture | Internal engineering review only |
| Planned downstream review environment | LMU-COICP Internal Engineering Review Environment |
| Planned downstream dataset | Spring Semester Synthetic Incident Dataset |
| AI Incident Summary | Deferred / disabled |
| Operational pilot | Not approved |
Branch strategy¶
Use short-lived feature branches tied to implementation work items.
Each branch implements one coherent work package or closely related set of work items. Branches stay small enough for review and must not mix unrelated design areas.
Branch naming¶
| Branch Type | Pattern | Example |
|---|---|---|
| Feature | feature/IW-###-short-name |
feature/IW-001-incident-record |
| Fix | fix/IW-###-short-name |
fix/IW-003-status-validation |
| Evidence / docs | evidence/IW-###-short-name |
evidence/IW-004-review-notes |
| Guardrail / test | test/IW-###-short-name |
test/IW-007-evidence-failure |
Pull request expectations¶
Each PR should include:
Work item:
Source design:
Requirements / constraints:
Evidence behavior:
Access-control impact:
AI-use disclosure:
Tests / checks:
Known gaps:
Guardrails confirmed:
LMU boundary impact:
Merge criteria¶
- Work item done criteria satisfied or limitation recorded.
- Required tests or checks pass, or gaps are explicitly recorded.
- Evidence, access, AI, emergency-boundary, and retention guardrails are preserved.
- AI-assisted code reviewed if applicable.
- Evidence or documentation updated where relevant.
- Reviewer accepts traceability.
- IT security reviewer reviews access-sensitive changes.
- AI reviewer reviews AI-sensitive changes.
- Architecture Review Board chair reviews evidence-sensitive changes.
- Compliance reviewer reviews retention/data-sensitive changes.
- Campus Safety liaison reviews emergency-boundary behavior.
Review requirements¶
| Change Type | Required Review |
|---|---|
| Core incident workflow | COICP Product Engineer |
| Evidence event behavior | Architecture Review Board chair |
| Access-control behavior | IT security reviewer |
| AI interaction | AI reviewer |
| Failure behavior | COICP Product Engineer and Architecture Review Board chair |
| Scope or emergency category handling | Product Owner and Campus Safety liaison |
| Retention-sensitive behavior | Compliance reviewer |
Workflow guardrail¶
No PR should merge if it weakens evidence creation, access control, AI review boundaries, emergency-response exclusions, or data governance without a recorded implementation decision and reviewer acceptance.