Static sample preview

AI Code Stability Probe

Repo: ruvnet/RuView

CA$500

Assessment: AI-assisted codebase

This AI Code Stability Probe sample shows how FoldEngine detects false closure in AI-adjacent codebases: projects that look complete through documentation and structure, while the runtime path has not been validated. Based on a public GitHub issue, not private work or a live backend response.

Question

Does this AI-adjacent codebase's public surface support the confidence its documentation and structure imply?

Target surface

Product/surface: the documented install/runtime path for the public AI-adjacent codebase. The decision is whether the code is stable enough to build on, demo, or hand to a developer. The claim tested is that documentation and structure should not imply runtime readiness without reproducible evidence.

Short finding

RuView presents documentation and an install path that suggest a working project. A public issue reports that setup on macOS / Python 3.11 exposed missing dependencies and functional logic that may not have been tested against a real runtime. This is a false-closure pattern: the project looks complete, but runtime evidence does not yet support the surface claim.

What FoldEngine checked

  • Public GitHub issue reporting installation failure and missing dependencies.
  • README install instructions and dependency claims versus reported reality.
  • Visible project structure and test surface.
  • Whether the implied completeness is supported by runtime evidence.

What FoldEngine did not check

  • Whether the code was AI-generated (we do not certify generation method).
  • Repository code execution or live testing.
  • Maintainer intent or blame.
  • Security audit or dependency vulnerability scan.
  • Private forks or downstream applications.

Evidence boundary / receipt-style summary

Artifact kind
ai_code_stability_probe
Evidence surface
Public GitHub issue and repository surface
Private access
None
Execution
No repo code execution

Seed candidates

Bounded change proposals extracted from the probe evidence. Each recommendation has a hypothesis, evidence requirements, and verification steps.

Seed A — Pin dependency manifest

Hypothesis: Explicit pinned dependencies enable reproducible installs and prevent silent breakage.

Value: high · Risk: low

Evidence required: requirements.txt or equivalent with exact version pins.

Verification: Clean install from pinned manifest succeeds on a fresh environment.

Seed B — Add one runtime smoke test

Hypothesis: A single end-to-end test proves the core functional path actually runs.

Value: high · Risk: low

Evidence required: Test file exists; test exercises the primary documented workflow.

Verification: Test passes on a documented environment with exit code 0.

Decision receipt: HOLD

Do not treat as production-ready or hand to a developer for production work until the recommendations below are resolved.

Decision
Hold
Expires
30 days from issuance, unless superseded by a closure check

What must change:

  • Dependency manifest pinned and install tested
  • At least one runtime smoke test passes

Governed next steps

Recommended execution order with unlock conditions and exit criteria.

  1. Priority 1 — Seed A: Pin dependency manifest

    Unlock: Repository write access available.

    Exit: Clean install from pinned manifest succeeds on a fresh environment.

  2. Priority 2 — Seed B: Add runtime smoke test

    Unlock: Seed A complete (dependencies installable).

    Exit: Test passes on documented environment.

  3. Closure check available

    Unlock: Both recommendations resolved.

    Exit: Closure Verification probe confirms hold conditions cleared; receipt upgrades to proceed.