View Tasks GitHub Settings Review Candidates Promote to PR Lane PR Status Completion Audit

Task: 2026-04-11-wo-licence-level-enable3

Project: wo

Task Name: licence-level-enable3

Task State: awaiting_openai_configuration

Ranking State: ranking_pending

Auto Top 1: Not set

Auto Top 2: Not set

Effective Top 1: Not set

Effective Top 2: Not set

Active PR Lane:

Promoted Candidate:

Workflow

Environment: HTTP · OpenAI not ready · GitHub not ready

Generation status: openai_not_configured using gpt-5-codex

Current next step: Review PR v1, compare the four candidates, confirm or override Top 1 and Top 2, then promote one candidate to the PR lane.

This task keeps PR v1 as the anchor brief. One of v1/v2/v3/v4 becomes the active PR-lane path after review.

PR v1 Base Brief

Download PR v1 File

PR v1 BASE BRIEF
================

Project Area: wo
Task Name: licence-level-enable3

Goal
----
1. Preserve effective-source precedence during contract map construction.
The next PR must ensure that effective authoritative Typhoon data is not overwritten, downgraded, or bypassed by later nested/compat/container reads when valid effective truth is already present.

2. Keep one selected-map architecture.
The next PR must preserve the current intended architecture:
- select one authoritative Typhoon contract map
- consume that selected map
- normalize/finalize once
It must not reintroduce mixed-source per-field reconstruction.

3. Support feature_flags / features only as bounded selected-map readers.
If Typhoon caps or horizons are stored under feature_flags / features inside the already-selected map, the PR may read them only as bounded fill-only support. They must not become a new source-selection path.

4. Preserve canonical-first ordering.
Direct canonical contract keys must always win first.
Direct compat aliases may fill only when canonical keys are absent.
Nested feature_flags / features reads may fill only when both direct canonical and direct compat paths are absent.

5. Preserve effective-first source selection.
The resolver must continue to prefer effective authority when it is valid and not isolated-false. Compat remains secondary and bounded.

6. Prevent isolated-false suppression of richer compat truth.
If effective is isolated-false, compat may only be consulted in the bounded richer-truth case already defined. This exception must remain narrow and must not widen into general compat promotion.

7. Keep fail-closed behaviour intact.
If no authoritative Typhoon contract truth exists after the bounded source-selection path completes, WO must fail closed.

8. Preserve valid forecast entitlements already carried in effective/nested payloads.
The next PR must not silently drop:
- typhoon_forecast_points
- typhoon_visible_comparisons_cap
- forecast_horizons
when those are present in valid selected/effective payload structures.

9. Keep Typhoon boolean truth tied to explicit contract truth.
No new inference from caps, horizons, windows, plan names, or UI state may be introduced.

10. Stay single-file and WO-only.
The next PR must remain confined to includes/class-wo-entitlements.php.

Extra Constraints
-----------------
1. Do not change source precedence.
Do not alter the intended precedence order beyond the exact bug fix:
- effective valid wins
- isolated-false effective may check bounded richer compat
- otherwise fail closed

2. Do not build effective_authority_sources from stale top-level effective aliases first.
When constructing authority candidate maps, do not let stale top-level effective aliases override fresher nested or selected-map truth incorrectly.

3. Do not ignore feature_flags / features when they are part of the already-selected map.
If the selected map stores Typhoon caps/horizons in feature_flags / features, the next PR must read them there as bounded fallback coverage.

4. Do not let feature_flags / features affect source selection directly.
feature_flags / features support is reader coverage only inside the already-selected map. It must not become its own authority source or selector trigger.

5. Do not reintroduce remote-option substitution into the primary Typhoon contract path.
No remote option value may outrank or substitute for selected-map contract truth in the main path.

6. Do not reintroduce cap-derived boolean invention.
No deriving:
- multi_period from visible comparisons cap
- v2 from cap presence
- forecast from horizons/caps alone

7. Do not broaden recursive payload traversal.
Any nested reading must stay bounded to already-approved selected-map structures. No broad recursive guessing.

8. Do not add helper sprawl unless absolutely necessary.
Prefer the smallest local change that fixes:
- effective precedence
- selected-map cap/horizon coverage
- bounded feature_flags / features reads
Avoid turning this into another mini-rewrite.

9. Do not change UI, rendering, Settings, Typhoon page, CSS, JS, LC, OAuth, broker, refresh orchestration, or non-Typhoon entitlement behavior.

10. Do not change the downstream coherence clamp architecture.
The clamp may remain, but it must operate on the correctly selected/finalized contract map.

11. Do not preserve broken legacy behavior just because it existed.
This is a version 1.0 plugin line. Broken legacy behavior does not need preserving where it blocks the correct authority model.

12. Do not let compat outrank authoritative effective truth.
Compat may only win in the isolated-false richer-truth branch. No broader compat promotion.

13. Do not let horizons act as standalone authority-strength substitutes.
Horizon presence alone must not upgrade authority or capability truth.

14. Do not allow selected-map reader changes to spill back into authority gating.
Reader coverage fixes must stay reader coverage fixes. They must not alter which map gets selected except where the current bug explicitly proves the selected-map content was being under-read.

15. Keep the PR narrow enough that the change can be described as:
“Preserve effective precedence and selected-map cap/horizon coverage without changing authority selection.”

OPERATOR CHECK BEFORE ACCEPTING NEXT PR VERSION

Accept the next PR only if it clearly does all of the following:
- preserves effective-first precedence
- keeps compat bounded
- fixes under-reading of feature_flags / features inside the selected map
- does not reintroduce mixed-source reconstruction
- does not reintroduce remote-option substitution
- does not reintroduce cap-derived boolean inference
- stays in includes/class-wo-entitlements.php only

Required Flow
-------------
1. Keep this brief as the anchor intent for later audit.
2. Generate four internal candidates from this brief.
3. Rank all four candidates and identify Top 1 and Top 2.
4. Promote only one candidate into the active PR lane.
5. After review and merge, audit delivered code against this PR v1 brief.

Acceptance Notes
----------------
- Keep scope narrow.
- Work inside wo/ unless explicitly justified otherwise.
- Preserve authority and PR guide constraints.

GitHub Settings

Repo Owner: DavidB-DnD

Repo Name: codex-projects

Base Branch: main

Codex Review Required: yes

Protected Branch Required: yes

Status Checks Required: yes

PR Lane

Promoted Candidate:

Promoted Branch:

PR Ready: no

GitHub PR Number:

GitHub PR URL:

GitHub Review Status:

GitHub Checks Status:

Merge Ready: no

Merge Block Reason:

Candidate Comparison Panel

v1 — wo-licence-level-enable3-v1

Candidate

Strategy: Implement the narrowest possible safe patch. Minimize file changes and avoid scope creep.

Rank Position:

Summary:

Strengths:

Risks:

Selection Reason:

Non-selection Reason:

Download Candidate Prompt

Promote This Candidate

v2 — wo-licence-level-enable3-v2

Candidate

Strategy: Implement the safest maintainable path. Stay tightly scoped but favor clarity and durability.

Rank Position:

Summary:

Strengths:

Risks:

Selection Reason:

Non-selection Reason:

Download Candidate Prompt

Promote This Candidate

v3 — wo-licence-level-enable3-v3

Candidate

Strategy: Implement the strongest conservative behavior-preserving path. Minimize UX and integration risk while remaining robust.

Rank Position:

Summary:

Strengths:

Risks:

Selection Reason:

Non-selection Reason:

Download Candidate Prompt

Promote This Candidate

v4 — wo-licence-level-enable3-v4

Candidate

Strategy: Implement the strongest approval-likely path under the authority docs. Be conservative, review-friendly, and structurally strong.

Rank Position:

Summary:

Strengths:

Risks:

Selection Reason:

Non-selection Reason:

Download Candidate Prompt

Promote This Candidate