Skip to content

Validate exact source-hub candidate governance before publication #145

Description

@tom-sapletta-com

The source-hub publication fallback in goal/governance/delivery.py (_governance_gate, run_source_hub_health) returns success after the shared source suites, but does not run the exact candidate governance check against governance/manifest.hub.json with accepted base/current head and CI actor. This allows a locally successful Goal publication to fail the first protected PR scope step.

Reproduced with Goal 71c71d6 and wellmanifest/new-project PR #339, initial head 25bcb6f49cc9469215eb6f92e66741f6fe8a3144: all Goal source-hub tests passed and the PR was published; CI rejected GOV-DELIVERY-001 (estimatedMinutes=40, maxActiveMinutes=30, no file/component budget violations). Exact explicit hub invocation reproduces the failure locally. The new-project project/governance-check.sh wrapper also selects .governance when present, so callers cannot infer source-hub policy from a wrapper PASS. The candidate is being corrected within its small existing implementation scope; no policy limit is relaxed.

Required delivery:

  • In the recognized source hub, run the canonical candidate governance check with the source manifest, accepted base and exact head before push/PR, preserving the existing source suites and required Linux/Windows publication checks.
  • Reject an over-budget candidate even when all source suites pass; do not treat textual diagnostics as exceptions.
  • Keep ordinary adopted repositories on their immutable installed manifest.
  • Regression tests must cover source hub with/without an incidental .governance tree, missing source contracts, exact base/head, governance failure and a valid candidate.
  • Prefer cheap candidate validation before expensive suites, including ticket-bound commit-subject preflight; never weaken either gate.

This is a queued product-owner fix, linked to wellmanifest/new-project#330. No branch/worktree/lease has been allocated and this issue grants no concurrent editing authority. Goal's existing tickets 100/101 and orphan ticket-098 remain preserved; reconcile admission and use the normal managed allocator before implementation.

Related source-hub routing observation after the protected merge: goal governance workspace-check requires an absent .governance/workspace_lifecycle_check.py and refuses the source hub. The canonical scripts/workspace_lifecycle_check.py was run directly read-only and reported 39 existing workspace findings; no overall clean result was claimed and no unknown work was removed. Provide an explicit source-hub read-only route as a separately bounded slice if needed; do not adopt an old package into the source hub to satisfy a path assumption. Among inspected primary paths, only wellmanifest/new-project matched the source-hub fallback. The registration fix itself is independently merged at a5ffa7dd5d0bb5cafbcefbb180204874787c0758 and its own checkout is retired with terminal evidence.

Activity-batching publication observation (2026-09-14): while publishing wellmanifest/new-project ticket-230 / PR354, numeric --ticket 230 was rejected for commit binding only after full source-hub suites. Canonical --ticket ticket-230 succeeded. At Goal 71c71d6, goal/push/core.py calls validate_delivery_ready at line575 before start_time assignment at589 and before committed-candidate resume. This confirms the existing cheap-preflight criterion and exposes omitted preflight duration in the reported total. Release output showed 5.9s total / 0.00s test time while the process had spent over three minutes in preflight suites. Add regression coverage for invalid ticket rejection before expensive tests and total/preflight timing on success and failure; retain all required source and exact-candidate gates. Avoid duplicate issue/worktree: this evidence continues #145. Canonical cross-repository plan: https://github.com/subactor/docs/issues/190 .

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions