P0: Make Queen/Bee task formatting valid by construction and repair skipped issues #1654

Problem

Queen's issue-to-task intake can silently skip otherwise useful tasks when required structural sections are missing. A historical Queen HUD report for 2026-10-08 said 449 of 488 issues lacked a Boundary section; this is historical evidence, not a current count. Re-measure current production before stating the present impact.

Goal

Make task formatting valid by construction, and repair existing open candidate tasks that fail the real intake contract. Do not rely on humans or agents remembering a checklist.

Boundary

• Scope: audit the canonical task contract in gHashTag/t27 (including specs/queen/tasks.t27 and the active dispatch/eligibility rules), and the live task creation/intake paths in gHashTag/BrowserOS and gHashTag/trinity.
• Allowed: read-only diagnosis, deterministic validators, template/creation-flow fixes, migration/report tooling, and narrowly scoped repairs to existing open issues.
• Not allowed: weakening the eligibility gate to accept malformed tasks, silently rewriting task intent, closing/reassigning tasks without evidence, or claiming a bee was dispatched without a runtime receipt.
• Output: cite the exact rule/source and paths; separate current measurements from historical snapshots; report every repaired issue URL and validation result.
• Completion: only complete when new tasks are structurally valid by default, invalid tasks get actionable errors before entering the queue, existing open candidate tasks are audited/repaired, and regression tests prove the behavior.

Required investigation

1. Find the canonical source of truth for task eligibility and the exact required section names/semantics. Confirm whether Boundary is required, case-sensitive, and whether any other required fields/sections exist. Do not invent a new contract if tasks.t27 already defines it.
2. Capture a current intake/skip report with counts by reason and representative issue links; do not reuse historical counts as current.
3. Audit open tasks that are intended for Queen/Bees, identify missing or invalid required sections, and repair their structure without changing their objective.
4. Fix the canonical issue/task template and every relevant creation path so required sections are prepopulated with clear instructions.
5. Add a validator at the earliest reliable boundary (creation or queue intake) with actionable diagnostics naming each missing/invalid field.
6. Add regression tests for valid tasks, missing Boundary, empty Boundary, malformed acceptance criteria, ambiguous scope, missing repository/context, and legacy tasks.
7. Add a safe batch repair/dry-run report for existing open tasks; never fabricate scope or acceptance criteria. Flag tasks requiring human clarification instead.
8. Verify end-to-end that a correctly formatted task becomes eligible and that a malformed one is rejected with an explicit reason.

Acceptance criteria

• Canonical task schema/rule is linked and documented.
• New task creation paths produce all required sections by default.
• Invalid tasks are blocked or routed to a repair queue with exact diagnostics, not silently skipped.
• Existing open Queen/Bees candidate tasks have a report: valid / repaired / needs clarification, with URLs.
• Tests cover valid and invalid cases and run in CI.
• Before/after counts and actual validation commands/results are posted here.
• No claim of live dispatch unless a bee run/dispatch receipt is linked.

Initial findings

The recently created T27F issues #1650 and #1651 did not have an explicit Boundary heading. They have now been amended with scope, allowed/disallowed work, output requirements and completion criteria. Issues #1652 and #1653 also now contain explicit Boundary sections. This repairs those four issue bodies, but does not prove that the live Queen intake accepted or dispatched them.

Related issues

• Queen/Bee runtime performance and intake liveness: EPIC: Queen + Bee Runtime Performance — measure, eliminate stalls, reuse work, then accelerate the core #1645
• T27F epic: EPIC: T27F — Native generative UI and visual application engine #1648
• T27F AST/IR audit: Queen → Bees: audit T27 AST/IR and design the GF16 visual-spec prototype #1650
• Numeric format pilot audit: Queen → Bees: compare T27 numeric formats and choose the right T27F visual-spec pilot #1651