pikasTech-unidesk/docs/reference/strategy-governance.md

Strategy Governance

This document owns the strategic filter for UniDesk requirements: external-benefit traceability, short-term versus long-term investment, and anti-loop guardrails for architecture proposals. The analysis record for the current strategy framing is GitHub issue #7. The long-term governance follow-up for the default user path versus diagnostics/status boundary is DC-DCSN-P0-2026-004.

Scope

Use this document when deciding whether a proposal should exist at all, how urgently it should be pursued, and whether it belongs to the short-term stabilization lane or the long-term base-layer lane.

This document does not replace docs/reference/release-governance.md, docs/reference/deploy.md, docs/reference/ci.md, or docs/reference/dev-environment.md. Those documents own the execution rules. This document owns the demand filter before execution begins.

Strategic Principle

UniDesk should be driven by verifiable external demand, not by infinite internal derivation or architecture taste.

External demand includes:

• user workflow value;
• operator recovery and incident reduction;
• deployment speed and reliability;
• delivery throughput;
• availability and observability;
• cost reduction that can be observed in practice;
• adoption or retention of a real platform capability.

Internal work is acceptable only when it can be traced to one of those outcomes or when it is a bounded investment that clearly compounds future external value.

If a proposal only improves internal elegance, symmetry, or conceptual purity, it is not sufficient by itself.

Requirement Test

Before accepting a requirement, answer these questions:

1. Who outside the implementation layer benefits?
2. What external metric improves?
3. How can the improvement be observed or verified?
4. Is the benefit short-term or long-term?
5. What user, operator, or delivery pain does it remove?
6. What is the removal condition if the proposal is only a temporary bridge?

If the answers are weak, the requirement should be dropped, narrowed, or rewritten.

Short-Term Work

Short-term work is the work that improves the current usable system quickly.

It is valid when it:

• stabilizes release/v1;
• protects production availability;
• makes CI/CD more reliable;
• reduces manual recovery effort;
• fixes user-visible defects;
• removes a blocking infrastructure defect that slows delivery;
• reduces the cost of shipping the next verified change.

Short-term work should be chosen when the main problem is today’s delivery or today’s operational fragility.

Long-Term Work

Long-term work is justified only when it creates reusable base capability with a measurable future payoff.

It is valid when it:

• raises the ceiling of future delivery speed;
• reduces the cost of every later change;
• improves the quality of the stable base for future releases;
• removes a recurring class of operational pain;
• creates a platform primitive that several real workflows will use.

Long-term work must still have:

• a named beneficiary;
• a measurable hypothesis;
• a bounded budget;
• an explicit exit condition;
• a reason it cannot wait forever.

If it does not have those properties, it is just internal expansion.

Anti-Patterns

Do not accept requirements that are only:

• architecture experimentation without a user or operator payoff;
• feature-flag proliferation without a clear removal path;
• hidden dual paths that are hard to test or observe;
• abstractions added only because they feel cleaner;
• infrastructure work that cannot be tied to delivery, availability, recovery, or cost;
• refactors that move complexity around without reducing external pain.

Review Rule

When a new idea is proposed, classify it immediately:

• short-term if it helps the current stable base ship, recover, or stay alive;
• long-term if it compounds future capability and has a clear payoff path;
• reject if it cannot be tied to external benefit.

The default bias should be toward the simplest path that satisfies the external need. Complexity is only justified when it pays for itself in visible external value.

Default Path Boundary

When a product surface has both a primary user workflow and an internal diagnostics or acceptance surface, the primary workflow must remain the default discoverable entry. Diagnostics and status pages may exist for verification, recovery, or observability, but they do not become the product's headline or default route unless a decision record explicitly says so.

For the current HWLAB case, DC-DCSN-P0-2026-003 freezes the short-term product direction, and DC-DCSN-P0-2026-004 records the longer-term governance rule for keeping the default path distinct from diagnostics/status surfaces.

Relationship to Other Governance Docs

• docs/reference/release-governance.md owns release lines, stabilization windows, runtime pinning, and feature-flag governance.
• docs/reference/deploy.md owns desired-state reconciliation and rollout semantics.
• docs/reference/ci.md owns CI execution on D601.
• docs/reference/dev-environment.md owns the persistent dev lane.

This document sits above those execution rules. It decides whether a proposed change is worth doing and whether it belongs to the short-term lane or the long-term lane.