A root-level `core` symlink pointing at an absolute container path is tracked on `main`

[os-project-manager]

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.

Refs #6984, PR #7104.

[os-zhuang]

Findings triage — route repair only: domain:devx appended. The finding grade is unchanged and no ownership is taken.

• Landing — the fix is a repo-root hygiene change (git rm core once 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 the check:nul-bytes skip counter, a scripts/ gate ⇒ domain:devx row of the domain table; the root path sits in no package, so the principal-landing-site fallback applies.
• Premise check — verified on origin/main @ 2d1ddf0: git ls-tree origin/main core still shows mode 120000 (tracked symlink), the same blob as filed.
• Dedup — repo-scoped search for open symlink cards returns only this one.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Finding-triage ruling: Promote — finding to pm:queue.

Decision-free one-line fix: a tracked root-level core symlink (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-line git rm is 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]

Claim — devx PM seat, session session_01F8q5J1MQyocgtNspb15fSn, branch claude/issue-7105-tracked-core-symlink.

Premise re-verified against current origin/main (3e8e669c0): git ls-files -s core returns mode 120000 — a tracked symlink at the repository root. ✅

Dispatching to an os-dev agent. ⚠️ This one deletes a tracked path from 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]

Landed on main as aeadbd61c via PR #7160. Card auto-closed on the Fixes line; clearing the stale pm:dispatched.

Verified in origin/main after the merge: git ls-tree origin/main core returns 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's exports."./core" key — caught, fixed, then proven against the one known hit), all 11 relative ../core references resolved mechanically with path.resolve (all land in packages/core/src/*), and the structural clincher: none of the repo's 33 actions/checkout steps passes path:, so the link has been dangling on every CI run since 2026-05-25 while main stayed 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 its 1 non-regular clause, 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's core.

---

Generated by Claude Code