docs(ams): document AMS's verified standalone, ORB/gittensor-optional capability - #6842
Merged
Merged
Conversation
… capability Adds an explicit invariant plus a verified-behavior callout to the AMS deployment guide (and its DEPLOYMENT.md source): AMS works against any GitHub repository, requiring neither ORB, gittensor registration, nor a target repo's .loopover.yml. Verified end to end (init, doctor, discover) against real public repositories with no .loopover.yml and no gittensor registration, using only a plain GITHUB_TOKEN. Closes #6205
loopover-orb
Bot
added
the
gittensor:feature
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Bundle ReportChanges will increase total bundle size by 2.1kB (0.03%) ⬆️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: loopover-uiAssets Changed:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Documents AMS's verified standalone, ORB/gittensor-optional capability in the AMS deployment guide, per the full end-to-end verification below.
Closes #6205
Verified: plain GITHUB_TOKEN path
Ran
@loopover/miner(npm install -g @loopover/miner@latest) on a real machine, using only a plainGITHUB_TOKEN(noloopover-mcp login):loopover-miner status/doctor/init --verify-token— all correct, offline where documented, token validated where not.loopover-miner discover <owner/repo>against several real, public, non-gittensor repos with no.loopover.yml:loopover-miner attempt <owner/repo> <issue#> --miner-login <login> --liveagainst two real, well-scoped issues on a repo I have contributor standing on:duplicate_cluster_high) rather than blindly attempted — the gate is doing its job.claude-clidriver's--permission-mode acceptEditsdenies everyRead/Bashtool call, so it can never actually read a file or run a test non-interactively) — confirmed via manual reproduction with and without the fix (bypassPermissions: 0 denials, real fix + regression test produced;acceptEdits: 19/19 denials, zero real work, 31 turns and real $ spent for nothing).Conclusion: the standalone
GITHUB_TOKENpath works exactly as designed throughdiscoverand attempt orchestration; the coding-agent driver itself has a real, now-documented bug (#6840) that currently blocks it from completing real work, independent of the standalone-repo story this issue set out to verify.Verified: device-flow paths
Two distinct device-flow mechanisms exist and were both tested:
loopover-miner init --interactive's own "Authorize with GitHub" option (LOOPOVER_MINER_AMS_OAUTH_CLIENT_ID) — works end to end once pointed at the already-deployed classic OAuth App (GITHUB_OAUTH_CLIENT_IDinwrangler.jsonc, currently used for dashboard login). No dedicatedloopover-amsApp exists yet, contra the code's own comments/docs, which describe a not-yet-registered App as the intended target — worth a design decision on whether to keep reusing the dashboard's App or register a dedicated one (flagged separately, not fixed here).loopover-mcp login's own device-flow (a completely separate mechanism — logs into LoopOver's own backend, whichresolveGitHubTokenthen calls/v1/auth/github/tokenagainst) — reproducibly broken. Filed as loopover-mcp login's device-flow polling gets 429'd by its own /v1/auth/* strict rate limit #6792: the polling route falls under a blanket 10-req/60s rate-limit class that a spec-compliant device-flow poller reliably exhausts within seconds.Docs updated
apps/loopover-ui/content/docs/ams-deployment.mdx(+ its DEPLOYMENT.md source) rather thandocs.miner-workflow.tsx/docs.quickstart.tsxnamed in the issue — neither of those actually covers@loopover/miner's autonomous discover/attempt loop (miner-workflow.mdxis about the separate, semi-autonomous@loopover/mcpcopilot tool;quickstart.mdxis@loopover/mcp-only).ams-deployment.mdxis the doc that actually corresponds to what was tested.Other findings (not fixed here, noted for awareness)
@loopover/miner(2.0.0) and@loopover/mcp(0.9.0) npm packages are both meaningfully stale relative tomain(currently 3.0.0 for both) —@loopover/mcp's publishedbinfield is stillgittensor-mcp, notloopover-mcpat all, and its current source can't even resolve its own@loopover/engine@^3.0.0dependency against what's published. Not filed as its own issue since it's a release/publish-process gap rather than a code bug, but worth knowing before recommendingnpm install -g @loopover/mcpto anyone right now.Test plan
npm run docs:drift-checknpm run test:miner-deployment-docs-auditnpm --workspace @loopover/ui run build