Project management
Scope: hcs · Status: Active · Tracking: AB#4945
This standard defines how repositories plan work and publish PMO views. The authoritative tracker remains the system of record. A generated board is a read-only presentation artifact, never a replacement backlog.
Authoritative trackers
| Repository platform or scope | Authoritative planning source |
|---|---|
HCS with ado_model: solution | The solution Azure DevOps project named in the registry |
| HCS with per-repository ADO | The repository's registered Azure DevOps project |
| GitHub-native intake | GitHub Issues and Projects, with the sync rules in Work item sync |
| AzureLocal | GitHub Issues and the organization Project; see the AzureLocal scoped overlay |
| TierPoint ProdTech | GitLab Issues and Milestones; see the TierPoint scoped overlay |
The board configuration MUST identify one authoritative provider and an explicit repository or project scope. The choice SHOULD come from master-registry.db; an operator MAY override it at invocation when intentionally producing a narrower or broader view.
Plans and subplans describe delivery approach and decisions. Trackable commitments from those plans MUST be represented by work items and linked back to the plan. Automation MUST NOT parse prose into a parallel task list.
Board contract
The reusable implementation is under templates/pmo-board/ and is generated with scripts/pmo/Update-PmoBoard.ps1.
A conforming board:
- is a self-contained HTML snapshot with no runtime CDN or tracker dependency;
- is read-only and links changes back to the authoritative work item;
- supports list/milestone and Kanban views, search, filters, progress, responsive layout, printing, and snapshot JSON export;
- permits configuration of title, subtitle, mark, colors, filters, and status mapping;
- stores generated output under ignored
.artifacts/pmo/; and - contains no access tokens, credentials, private API responses, or editable local backlog.
The standard columns are Planned, Ready, In progress, Blocked, Done, and Deferred. Provider-specific states map to these columns in configuration. Unknown values fall back to Planned so work remains visible.
Generation and publication
Generation MAY run manually or from the supplied Azure DevOps, GitHub Actions, or GitLab CI templates. Scheduled jobs SHOULD run no more frequently than every six hours unless the project has a documented need. Pipeline publication is an authenticated build artifact by default.
Remote interactive publication is optional and MUST remain restricted unless the repository owner explicitly approves public access:
- Claude Code may publish the generated HTML as a restricted artifact.
- Codex may publish it with Sites when that capability is available and access can remain owner-only or workspace-restricted.
- Local publication identifiers or URLs belong in ignored
.pmo-board.publish.json, not source.
The product repository MUST NOT commit generated snapshots merely to host them. Public websites, new hosting services, databases, and tracker write-back require a separate design decision.
Provider behavior
- Azure DevOps: read work items with Azure CLI authentication. Solution projects may include several repositories; per-repository views apply an explicit repository filter when available.
- GitHub: read Issues through authenticated
gh. GitHub remains authoritative for its native issue fields under the existing split-source sync model. - GitLab: read Issues through the GitLab API using
GITLAB_TOKEN. TierPoint data MUST NOT be mirrored into HCS Azure DevOps. - Fixture: local JSON exists for tests and demonstrations only.
Support
The board is best-effort open-source tooling. Baseline support covers the current template, documented providers, compatibility fixes, and reasonable defect review. Custom hosting, organization-specific field models, write-back automation, and service-level guarantees are not included.