Skip to content

[Feature] Forge observation and doctor extensions (PR-3) #164

Closed

Description

@Rwanbt

Problem

ainative doctor/status report installation state but have no concept of the
observed forge, remote candidates, Work Authority resolution state, or the
effective release source. Multi-Forge requires a read-only observation surface
that never dials out, never reads credentials, and never guesses a provider from
a hostname.

Source: Multi-Forge v1.3.2-final §55–59 (PR-3).

Expected outcome

ainative forge detect and ainative forge status describe what can be observed
locally about the project's remotes and features; doctor displays the effective
profile, feature set, Work Authority resolution state and release source — with
zero network, credentials, writes or persistent trust.

Acceptance criteria

  • Blocked until PR-1 green.
  • Commands ainative forge detect and ainative forge status exist and
    satisfy: network calls = 0, credentials = 0, writes = 0, persistent
    trust = 0.
  • Provider hints: github.com → github, gitlab.com → gitlab,
    unknown/custom host → unknown; self-hosted provider detection is never
    guessed from hostname alone.
  • Fork rendering: origin/upstream candidates are displayed without automatic
    preference; ambiguity is rendered (e.g. Resolution: AMBIGUOUS).
  • Doctor extensions display: profile, assurance level, effective feature set,
    observed remote candidates, Work Authority resolution state, release source,
    release selection reason, release auth origin, unresolved ClaimAttempts —
    never credentials.
  • Output is stable, machine-readable where the rest of the CLI is
    (--json), and derived through the shared feature projection.

Out of scope

  • Provider network calls, credential lookup, trust persistence.
  • Release source resolution implementation (PR-4A) — doctor only displays it once
    it exists; until then the current effective source is shown.
  • Claims resolution logic (PR-2).

Context

  • ainative/cli.py, ainative/lifecycle/status.py, machine_health.py.
  • Depends on PR-1.

Dependencies

Activity

  1. self-assigned this
    on Sep 16, 2026
  2. Rwanbt commented on Sep 16, 2026

    @Rwanbt
    OwnerAuthor

    Claiming this Issue; implementation on \multiforge\ (local, CI at the end).

  3. Rwanbt commented on Sep 16, 2026

    @Rwanbt
    OwnerAuthor

    Multi-Forge implementation merged into dev (squash f0101fc via PR #172), full CI matrix green (52/52: Linux/Windows/macOS, py3.11/3.13). The Issue stays open until the final dev -> main promotion, per the maintainer rule that main is untouched until everything is tested and integrated.

  4. Rwanbt commented on Sep 16, 2026

    @Rwanbt
    OwnerAuthor

    The follow-up increment (mandatory secret-pattern floor, scenarios J/M/P, documentation parity) is merged into dev (squash a8e1fb6 via PR #174, CI 76/76 green). The Issue stays open until the final dev -> main promotion.

  5. Rwanbt commented on Sep 17, 2026

    @Rwanbt
    OwnerAuthor

    Done: the work is merged into main (squash 8f319ad via PR #176, full CI matrix green including the Production Gate). Closed as completed.

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

Metadata

Metadata

Assignees

Labels

priority:P2Useful improvementtype:featureA new capability or improvement

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions