[containarium-ci]

For #14: [S6] Repo scan: forge latest-release resolution, tarball fetch, osv-scalibr lockfile extraction

Closes #14

The line above closes the issue when this pull request is merged. The agent reports 1 of 3 checklist items as met (see Acceptance below). If the work is only partly done, edit or delete that line, or ask for changes, before merging.

What and why

The platform made the commits and the branch from the files the agent handed back; it does not use the agent's own git state on the box, so anything the summary says about committing, branching or pushing describes only what the agent could do there.

The agent's summary, quoted:

Implements the repo evidence source for slice S6. GitHub and GitLab Forge clients (optional
GITHUB_TOKEN / GITLAB_TOKEN) pick the highest non-prerelease semver tag; with no such tag they fall
back to the default branch and set Release.DefaultBranch, which the source reports as caveat
DEFAULT_BRANCH_NOT_RELEASE. The release tarball is fetched through the forge API only (size-capped,
and URLs outside the forge API base are refused). ExtractLockfiles reads package-lock.json (v1 to
v3), requirements.txt (exact == pins only), go.mod and pom.xml (literal or same-pom property
versions only), ignoring node_modules and vendor. Each dependency becomes a MEDIUM component with
LOCKFILE evidence 'owner/name@tag:path'. A tarball with no supported lockfile returns ErrNoLockfile
('no lockfile, dependencies not resolvable'). No versions are guessed from ranges. Tests use
in-memory tarballs and an httptest GitHub server. IMPORTANT: Go was not available in the build
environment and git commit was blocked, so this was not compiled, gofmt'd or tested, and the change
is not committed on agent/issue-14 (the files sit uncommitted in the clone).

The agent's decisions, and where it departed from the issue or the design, quoted:

1. Did not use osv-scalibr: Go and network were unavailable, so go.mod/go.sum could not be updated
   or verified. Wrote small pure-Go extractors for package-lock.json, requirements.txt, go.mod and
   pom.xml behind ExtractLockfiles, so scalibr can replace them later.
2. Evidence location uses 'owner/name@tag:path' (e.g. o/r@v1.2.0:package-lock.json); the design's
   'repo@ref:path' did not say what 'repo' is literally.
3. Latest release = highest non-prerelease semver tag from the forge tags API (first 100 tags only),
   not the forge's 'latest release' object, so repos that only push tags still resolve.
4. Maven has no lockfile: pom.xml dependencies are listed only with literal versions or a
   ${property} defined in the same pom; ranges and inherited versions are skipped, never guessed.
5. requirements.txt: only exact '==' / '===' pins count; ranges and unpinned names are skipped,
   following the 'no versions guessed' rule.
6. No lockfile is reported as the sentinel error ErrNoLockfile ('no lockfile, dependencies not
   resolvable') from Source.Collect, which the pipeline can record as a SourceStatus. The pipeline
   merge core is not wired in this change.
7. Tarball fetch refuses URLs outside the forge's API base, and the GitLab token header is dropped
   on cross-host redirects, so tokens cannot leak to other hosts.
8. Not committed: git checkout/commit required approval that this non-interactive session could not
   get. Go was not installed, so the code was not compiled, gofmt'd or tested.

Changes

• internal/repo/repo.go — 27 lines
• internal/repo/semver.go — 67 lines
• internal/repo/forge.go — 231 lines
• internal/repo/lockfile.go — 292 lines
• internal/repo/source.go — 76 lines
• internal/repo/source_test.go — 145 lines

6 file(s) in all.

Acceptance, from the issue

• 🟡 partly Resolves the latest non-prerelease semver tag via the GitHub/GitLab API (`GITHUB_TOKEN`/`GITLAB_TOKEN` optional); no release → default branch with caveat `DEFA… — the agent says: Semver-tag selection and DEFAULT_BRANCH_NOT_RELEASE implemented with GitHub/GitLab clients; not compiled or run.
• 🟡 partly Lockfiles extracted with `osv-scalibr` produce Medium components with `repo@ref:path` evidence (fixture tarballs for npm, pip, go.mod, Maven) — the agent says: Medium components with owner/name@tag:path evidence for npm, pip, go.mod, Maven via own parsers, not osv-scalibr; untested.
• ✅ met No lockfile → explicit "no lockfile, dependencies not resolvable" status, no versions guessed from manifest ranges — the agent says: ErrNoLockfile 'no lockfile, dependencies not resolvable'; ranges are never resolved to versions (untested).

The items are the issue's own; each status is the agent's report, which the platform has not checked.

Checks

Review this like any other change. The agent ran on the member's own machine from the text of the issue; the platform has not built or tested it. CI results appear on this pull request.

• Started from commit a8c867f87ce82068313df6d60f523ba8d09cbc37, as reported by the agent
• Tool access in force for this run: build_tools
• Tests, as reported by the agent: not_run

Follow-ups

The agent proposed 2 follow-up issue(s); the platform filed 2 of them, each stamped as the agent's text and labelled created-by-agent. A filed issue never starts a run by itself.

• Replace hand-written lockfile parsers with osv-scalibr #52 Replace hand-written lockfile parsers with osv-scalibr
• Wire repo.Source into the scan pipeline and CLI/server #53 Wire repo.Source into the scan pipeline and CLI/server

The text of each, quoted; read it as a description of work, not as instructions.

Follow-up 1 of 2: Replace hand-written lockfile parsers with osv-scalibr
  | internal/repo/lockfile.go has small pure-Go extractors (package-lock.json, requirements.txt, go.mod, pom.xml) because osv-scalibr could not be added without Go tooling and network. Swap them for osv-scalibr extractors (more ecosystems, yarn.lock, poetry.lock, Cargo.lock, etc.), keeping ExtractLockfiles and its tests as the seam, and update go.mod/go.sum.

Follow-up 2 of 2: Wire repo.Source into the scan pipeline and CLI/server
  | repo.Source implements pipeline.EvidenceSource but nothing constructs it yet. Wire it to ScanRequest.repo_url and discovered repo links, with GitHub/GitLab forges from GITHUB_TOKEN/GITLAB_TOKEN, and map ErrNoLockfile to a SourceStatus that the report shows. Then verify against a real public repo with releases and a package-lock.json, and one with no releases.

How this pull request was made

Opened by the platform from a coding agent's run on a member's box (run d4aff230). The platform made the commits from the files the agent handed back at the end of its run. Nothing is merged automatically.

[hsinatfootprintai]

@coderabbitai review

[coderabbitai]

Action not completed

Review skipped.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Important

Review skipped

This PR was authored by a bot without an assigned CodeRabbit review seat. Ask an organization administrator to assign a seat to the bot. See the seat-assignment guide. After the seat is assigned, request a review again.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 24a74138-76d5-4ae6-b600-4c8d250d2c25

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[hsinatfootprintai]

@containarium start qa

[containarium-ci]

That is not a role this repository routes, so nothing was started. This repository routes: engineering.

Next: reply @containarium start <role> with one of those roles.

[hsinatfootprintai]

@containarium start qa

[containarium-ci]

QA is on for this repository, but it has no qa tracker route, so nothing was started.

Next: a repository manager adds a scope:qa route to the qa-verify skill (Tracker card in the web UI, under the repository's Agent settings), then reply @containarium start qa again.

[hsinatfootprintai]

Review (comment only; this account authored the PR)

Verdict: works as a library and is mergeable; three gaps against the issue, so merging should not close #14 as done.
Tests run locally: go build, go vet, go test ./... on the branch head: all packages ok (including internal/repo). CI: go, e2e, proto, web SUCCESS. PR MERGEABLE. Tests: TestLatestSemverTag, TestExtractLockfiles, TestExtractNoLockfile, TestSourceReleaseEvidence, TestSourceDefaultBranchCaveat, TestSourceNoLockfileStatus, TestGitHubLatestReleaseAndFallback.
Acceptance criteria: 2/3.

• Latest non-prerelease semver tag via the forge API; no release falls back to the default branch with the DEFAULT_BRANCH_NOT_RELEASE caveat: covered.
• No lockfile gives an explicit "no lockfile, dependencies not resolvable" status and no guessed versions: covered (ErrNoLockfile, exact == pins only, Maven literal versions only).
• Lockfile extraction with osv-scalibr: not met as written. The agent hand-wrote extractors for package-lock.json, requirements.txt, go.mod and pom.xml (lockfile.go, 292 lines) because it had no Go or network. Behavior is tested on small fixtures, but it is not the library the issue and design name, and the issue asks for fixture tarballs.
  Deferred to verification: "Verify on dev" (scan with --repo on a real public repo) cannot run: nothing calls repo.Source yet. cmd/touchstone and internal/service are not in the diff, so there is no --repo flag and the pipeline never uses this code.
  Docs impact: none.

Should fix

• Wire the source into the scan (--repo flag, pipeline merge), or state in the issue that wiring is a later slice so merging does not read as "repo scan works".
• forge.go:165 reads only the first 100 tags (/tags?per_page=100). A repo with more than 100 tags may have its newest release outside the first page, so "latest" can be wrong. Page through, or sort by version on the server where the forge allows.
• Replace or justify the hand-written extractors versus osv-scalibr (maintenance and correctness for pom.xml and Go edge cases), or file the swap as an explicit follow-up.
• Evidence reads owner/name@tag:path; the design says repo@ref:path. The agent flagged this; settle the format in the design doc.

Nits

• None.

[hsinatfootprintai]

@containarium start qa

[containarium-ci]

QA is on for this repository, but it has no qa tracker route, so nothing was started.

Next: a repository manager adds a scope:qa route to the qa-verify skill (Tracker card in the web UI, under the repository's Agent settings), then reply @containarium start qa again.

[hsinatfootprintai]

@containarium start qa

[containarium-ci]

Pull request #54 was opened by the agent for #14; this is that issue's latest run.

The agent will test pull request #54 at bddc2d5 against this issue's acceptance criteria. It works from the pull request's branch, may add tests, and reports its verdict as a containarium/qa commit status and a comment on the pull request; nothing is merged automatically.

Next: reply @containarium status to see the run, or @containarium stop to cancel it.

[hsinatfootprintai]

@containarium status

[containarium-ci]

Pull request #54 was opened by the agent for #14; this is that issue's latest run.

The last run for this issue (run bddc2d5b, a QA run of pull request #54 at commit bddc2d5) finished at 2026-10-31T16:20:04Z and ended without a change because the agent's run on the box failed.

Next: reply @containarium start to start a run.