chore: use published core package in examples

[alongubkin]

Fixes ALIEN-189.

Updates examples to depend on the published @alienplatform/core package instead of repo-local link dependencies, so downloaded examples install cleanly.

Validation:

• clean bun install --frozen-lockfile for byoc-database, endpoint-agent, and github-agent remote-agent

[greptile-apps]

Greptile Summary

This PR replaces link: path dependencies on the local packages/core source with a published @alienplatform/core@^1.7.0 version across four examples, so they can be cloned and installed standalone without the rest of the monorepo.

• byoc-database, endpoint-agent, and github-agent/remote-agent all have updated bun.lock files reflecting the new resolved version; the bun-based installs should be fully reproducible.
• full-stack-microservices has its package.json updated but no pnpm-lock.yaml is committed, leaving installs non-reproducible for that example.
• All three bun lockfiles now contain multiple resolved versions of @alienplatform/core (1.7.0 for the workspace and 1.3.5/1.0.1 for nested deps like @alienplatform/sdk and @alienplatform/testing), which is worth monitoring for cross-version type or runtime identity issues.

Confidence Score: 4/5

Safe to merge for bun-based examples; the pnpm example is left without a lockfile which reduces reproducibility but doesn't break anything today.

The three bun examples are cleanly updated with matching lockfiles and should install reproducibly. The full-stack-microservices example has no committed pnpm lockfile, so fresh installs will float to whatever resolves at install time. Additionally, all bun lockfiles now carry dual core versions because sdk and commands-client haven't been updated to peer on 1.7.0, which is worth watching but doesn't break the examples today.

examples/full-stack-microservices/package.json — no pnpm-lock.yaml was committed alongside the dependency change

Important Files Changed

Filename	Overview
examples/byoc-database/package.json	Switches @alienplatform/core from link: to ^1.7.0 published package; no structural issues
examples/endpoint-agent/package.json	Switches @alienplatform/core from link: to ^1.7.0 in devDependencies; consistent with test-only usage
examples/full-stack-microservices/package.json	Switches @alienplatform/core from link: to ^1.7.0, but no pnpm-lock.yaml was committed; pnpm installs won't be reproducible
examples/github-agent/packages/remote-agent/package.json	Switches @alienplatform/core from link: to ^1.7.0 in runtime dependencies; lockfile correctly updated
examples/github-agent/packages/remote-agent/bun.lock	Updated to core 1.7.0 at top level; nested packages sdk and commands-client still pin core@1.3.5, introducing dual-version resolution
examples/byoc-database/bun.lock	Updated core from 1.3.5 to 1.7.0; nested versions for testing and commands-client are expected overrides
examples/endpoint-agent/bun.lock	Core updated to 1.7.0; core correctly moved from dependencies to devDependencies in workspace block, matching package.json

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User clones example] --> B{Which example?}
    B -->|byoc-database| C[bun install frozen]
    B -->|endpoint-agent| D[bun install frozen]
    B -->|github-agent remote-agent| E[bun install frozen]
    B -->|full-stack-microservices| F[pnpm install - no lockfile]

    C --> G[core 1.7.0 top-level]
    D --> H[core 1.7.0 top-level]
    E --> I[core 1.7.0 top-level]

    G --> K[commands-client uses core 1.3.5 / testing uses core 1.0.1]
    H --> L[commands-client uses core 1.3.5 / testing uses core 1.0.1]
    I --> M[sdk uses core 1.3.5 / commands-client uses core 1.3.5]

    style F fill:#f96,stroke:#c00
    style K fill:#ffe,stroke:#cc0
    style L fill:#ffe,stroke:#cc0
    style M fill:#ffe,stroke:#cc0

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
examples/full-stack-microservices/package.json:10-13
**Missing pnpm lockfile for reproducible installs**

The three bun-based examples each have an updated `bun.lock` committed alongside their `package.json` changes, so `bun install --frozen-lockfile` works cleanly. `full-stack-microservices` uses pnpm but has no committed `pnpm-lock.yaml`. After this change a user cloning the example and running `pnpm install` will get whatever versions resolve at that point in time rather than a pinned, reproducible set — which is at odds with the stated goal of downloaded examples installing cleanly. Running `pnpm install` in this directory and committing the resulting `pnpm-lock.yaml` would close the gap.

### Issue 2 of 2
examples/github-agent/packages/remote-agent/bun.lock:337-342
**Dual `@alienplatform/core` versions in the same install**

The top-level dependency resolves to `@alienplatform/core@1.7.0`, but both `@alienplatform/sdk` and `@alienplatform/commands-client` still pin `@alienplatform/core@1.3.5` as a nested override. If either package uses `instanceof` checks or module-identity comparisons against core types, objects created with 1.7.0 won't match the 1.3.5 class references and will silently fail. The same pattern appears in `byoc-database/bun.lock` and `endpoint-agent/bun.lock` for `commands-client`. Consider updating or peering `@alienplatform/sdk` and `@alienplatform/commands-client` to accept core `^1.7.0` so only a single version is installed.

_{Reviews (1): Last reviewed commit: "fix: use published core package in examp..." | Re-trigger Greptile}

[greptile-apps]

Missing pnpm lockfile for reproducible installs

The three bun-based examples each have an updated bun.lock committed alongside their package.json changes, so bun install --frozen-lockfile works cleanly. full-stack-microservices uses pnpm but has no committed pnpm-lock.yaml. After this change a user cloning the example and running pnpm install will get whatever versions resolve at that point in time rather than a pinned, reproducible set — which is at odds with the stated goal of downloaded examples installing cleanly. Running pnpm install in this directory and committing the resulting pnpm-lock.yaml would close the gap.

Prompt To Fix With AI

This is a comment left during a code review.
Path: examples/full-stack-microservices/package.json
Line: 10-13

Comment:
**Missing pnpm lockfile for reproducible installs**

The three bun-based examples each have an updated `bun.lock` committed alongside their `package.json` changes, so `bun install --frozen-lockfile` works cleanly. `full-stack-microservices` uses pnpm but has no committed `pnpm-lock.yaml`. After this change a user cloning the example and running `pnpm install` will get whatever versions resolve at that point in time rather than a pinned, reproducible set — which is at odds with the stated goal of downloaded examples installing cleanly. Running `pnpm install` in this directory and committing the resulting `pnpm-lock.yaml` would close the gap.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Dual @alienplatform/core versions in the same install

The top-level dependency resolves to @alienplatform/core@1.7.0, but both @alienplatform/sdk and @alienplatform/commands-client still pin @alienplatform/core@1.3.5 as a nested override. If either package uses instanceof checks or module-identity comparisons against core types, objects created with 1.7.0 won't match the 1.3.5 class references and will silently fail. The same pattern appears in byoc-database/bun.lock and endpoint-agent/bun.lock for commands-client. Consider updating or peering @alienplatform/sdk and @alienplatform/commands-client to accept core ^1.7.0 so only a single version is installed.

Prompt To Fix With AI

This is a comment left during a code review.
Path: examples/github-agent/packages/remote-agent/bun.lock
Line: 337-342

Comment:
**Dual `@alienplatform/core` versions in the same install**

The top-level dependency resolves to `@alienplatform/core@1.7.0`, but both `@alienplatform/sdk` and `@alienplatform/commands-client` still pin `@alienplatform/core@1.3.5` as a nested override. If either package uses `instanceof` checks or module-identity comparisons against core types, objects created with 1.7.0 won't match the 1.3.5 class references and will silently fail. The same pattern appears in `byoc-database/bun.lock` and `endpoint-agent/bun.lock` for `commands-client`. Consider updating or peering `@alienplatform/sdk` and `@alienplatform/commands-client` to accept core `^1.7.0` so only a single version is installed.

How can I resolve this? If you propose a fix, please make it concise.