Codex
109 lines
4.5 KiB
Markdown
109 lines
4.5 KiB
Markdown
# 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](https://github.com/pikasTech/unidesk/issues/7).
|
||
|
||
## 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.
|
||
|
||
## 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.
|