Access control and audit scope

Purpose

Define the minimum operator access-control and audit posture for Portal, TzenBoard, and related recovery/admin surfaces.

Operator auth model for Admin pages

• Portal Admin pages are operator surfaces, not public product pages.
• Access should resolve to a small trusted operator group only.
• At minimum, all Admin routes should sit behind one explicit operator-auth boundary before PROD exposure.
• Until full auth is wired, DEV-only exposure must be treated as temporary and documented in runbooks/evidence.

Risk-tiered action separation

Low-risk operator actions

Examples:

• viewing dashboards
• reading logs/evidence
• viewing board state
• reading wiki/knowledge pages

Allowed roles:

• Dan
• Product Owner
• Scrum Master
• Developer
• QA Tester
• Tech Writer

Medium-risk mutation actions

Examples:

• editing Story packet fields
• creating comments/decisions/approvals
• queue/sync/runtime nudges that do not mutate production infra

Allowed roles:

• Product Owner
• Scrum Master
• Developer
• QA Tester
• Architect/Tzen acting within delegated limits

High-risk / destructive actions

Examples:

• backup restore
• destructive delete/archive operations beyond normal board semantics
• production config rewrites
• promotion / rollback execution
• secrets rotation override paths
• nginx/TLS rollout that affects public ingress

Required separation:

• one operator executes
• one second operator (Architect or Dan) reviews/approves
• action must leave a durable audit trail and evidence artifact

Minimum audit trail for governance-critical changes

Each governance-critical action should capture:

• actor identity
• timestamp
• action type
• target object or scope
• request id / run id if applicable
• before/after summary when mutation occurs
• resulting state
• linked evidence artifact path if one exists

TzenBoard closeout-specific rule

For Story closeout to done, require: 1. QA evidence recorded 2. approved qa_review 3. final sanity-check by Architect or Dan 4. evidence reference/artifact path attached

Runbook expectations

Runbooks for risky actions must document:

• normal path
• override/emergency path
• rollback path
• operator evidence to capture

Practical implication for current migration

Before calling Portal/TzenBoard production-ready, the following must be true:

• Admin/operator auth boundary is explicit
• risky actions are separated by role/approval
• audit evidence survives operator mistakes and retries