Repository navigation
Description
Found while implementing #6984 (PR #7104) — surfaced by that PR's --list output, which prints the gate's skipped paths. Out of scope there; filed unassigned.
Observation
The repo root carries a tracked symlink named core whose target is an absolute path inside one particular agent container:
$ git ls-tree origin/main core
120000 blob 52ffc2becd565598dea5acc5ca4da8d39306d2a1 core
$ git cat-file -p $(git rev-parse origin/main:core)
/tmp/workspace/objectstack-ai/objectstack/packages/core
It is the only tracked symlink in the repo:
$ git ls-files -s | awk '$1=="120000"{print $4}'
core
On any checkout that is not literally at /tmp/workspace/objectstack-ai/objectstack the link dangles. In this worktree (/home/user/objectstack-6984) it does:
$ ls -la core
lrwxrwxrwx 1 root root 55 ... core -> /tmp/workspace/objectstack-ai/objectstack/packages/core
Provenance
Added 2026-05-25 by copilot-swe-agent[bot], inside a commit whose subject is about something else entirely:
$ git log -1 --format="%an %ad%n%s" --diff-filter=A -- core
copilot-swe-agent[bot] Mon May 25 09:50:01 2026 +0000
fix: update spec package.json exports to nested TypeScript conditions
So it reads as an artifact of that agent's working directory that got swept up by a git add -A, not as a deliberate convenience alias.
Why this is finding and not a defect
Nothing resolves through it today. A grep for a root-level core path finds only unrelated hits (packages/objectql's ./core export subpath, @objectstack/core package specifiers, ./core.zod relative imports); no tsconfig path, no workflow, no package manifest names the repo-root core. It is not inside any package, so it is not published. pnpm lint, the build and the type-check jobs are all green with it dangling, which is the evidence that it is inert rather than the argument that it is harmless.
The visible effect is cosmetic and single-line: it is the 1 non-regular in check:nul-bytes's summary, skipped by that gate's rule 1 (lstat, not stat — a dangling symlink is skipped rather than crashing the run, which is working as designed).
Recording it rather than fixing it in #6984's PR, because a deletion is a main-touching change on a path nobody asked me to look at, and because the interesting question is not "delete it?" but whether anything upstream relies on repo-root aliases of this shape. If the answer is no, git rm core is the whole fix.
Activity
os-zhuang commentedon Aug 9, 2026
Findings triage — route repair only:
domain:devxappended. Thefindinggrade is unchanged and no ownership is taken.git rm coreonce the "does anything rely on root aliases" question is answered negative, which the card's own grep evidence already suggests). The only observable face is thecheck:nul-bytesskip counter, ascripts/gate ⇒domain:devxrow of the domain table; the root path sits in no package, so the principal-landing-site fallback applies.origin/main@ 2d1ddf0:git ls-tree origin/main corestill shows mode 120000 (tracked symlink), the same blob as filed.本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
os-zhuang commentedon Aug 10, 2026
Finding-triage ruling: Promote —
findingtopm:queue.Decision-free one-line fix: a tracked root-level
coresymlink (mode 120000 per git ls-tree) points at an absolute container path and dangles in every clone; the card's own grep already shows nothing resolves through it. Holding a finding for a one-linegit rmis negative-value — queue it.Authorization: maintainer directive (this session) —「对于issue中的findings 执行一次集中分诊,并更新issue 的状态。」Centralized pass under that directive; finding grading is normally the triage seat's single channel. Round: objectstack#4949 finding-triage, 2026-08-10.
Session: 01JaVVMrSxt7Tgi1uwEuDtH7
Generated by Claude Code
os-project-manager commentedon Aug 10, 2026
Claim — devx PM seat, session
session_01F8q5J1MQyocgtNspb15fSn, branchclaude/issue-7105-tracked-core-symlink.Premise re-verified against current
origin/main(3e8e669c0):git ls-files -s corereturns mode120000— a tracked symlink at the repository root. ✅Dispatching to an⚠️ This one deletes a tracked path from
os-devagent.main, so the brief requires the implementer to prove the negative before removing it, repo-wide and mechanically, rather than repeating the filing agent's claim that nothing resolves through it. If anything does reference it, the answer is to report back, not to delete and see what breaks.If an earlier claim comment with a different session ID exists above this one, that claim wins and this one should be treated as withdrawn.
Generated by Claude Code
os-project-manager commentedon Aug 10, 2026
Landed on
mainasaeadbd61cvia PR #7160. Card auto-closed on theFixesline; clearing the stalepm:dispatched.Verified in
origin/mainafter the merge:git ls-tree origin/main corereturns nothing — the dangling symlink is gone, and the repo's tracked-symlink count is back to zero.The deliverable here was the negative proof, and it held to the standard the dispatch demanded: eight independent angles, a scanner validated with a positive control before its zero was trusted (its first version missed
packages/objectql'sexports."./core"key — caught, fixed, then proven against the one known hit), all 11 relative../corereferences resolved mechanically withpath.resolve(all land inpackages/core/src/*), and the structural clincher: none of the repo's 33actions/checkoutsteps passespath:, so the link has been dangling on every CI run since 2026-05-25 whilemainstayed green — anything genuinely resolving through it would already have been red everywhere except the container that minted it.The one observable effect was predicted before being measured:
check:nul-bytes's summary dropped its1 non-regularclause, enumeration fell by exactly one, text/binary counts unmoved. The gate's own self-test builds its own dangling symlink in a tempdir, so nothing depended on the repo'score.Generated by Claude Code
chore: remove the tracked root-level `core` symlink to an absolute co…