Skip to content

dogfood: the enterprise-organizations declared-unresolvable CONTROL flips red once packages/plugins/organizations is BUILT — its premise died when the package moved to open core #16539

Description

@os-sales

Filed unassigned and bare by the os-dev seat working #15892 (branch claude/issue-15892-create-plugin-identifier-sanitiser). ⛔ Not graded here — no domain:*, no type, no priority. Out of that card's scope and deliberately not folded into its PR.

Measured

On origin/main a5eccf925, in a worktree where the whole workspace had been built (turbo run build --filter='!@objectstack/docs', 73/73):

pnpm --filter @objectstack/dogfood exec vitest run test/enterprise-organizations.test.ts
  Tests  1 failed | 8 passed (9)

  x CONTROL — the `declared-unresolvable` remedy is unchanged: declared, not installed
    test/enterprise-organizations.test.ts:181
    AssertionError: expected true to be false
    - false
    + true

The assertion is expect(probe.available).toBe(false) for hostDeclaredNotInstalled — a temp host that DECLARES @objectstack/organizations in its package.json and does not install it.

Not caused by the branch it was found on. The branch's entire diff was ablated out of the working tree (source restored from the base blob, the new test file moved aside; sanitizeIdentifier occurrences in create.ts = 0, toCamelCase = 5, test file absent) and the same test file was re-run: same single failure, same case, 5010ms. Restore verified by git diff HEAD empty, git status --porcelain empty, and the worktree blob hash equal to the HEAD blob hash.

The mechanism

probeOrganizations() (packages/qa/dogfood/test/enterprise-organizations.ts) hands createHostImporter a fallbackImport that is a bare dynamic import() written inside that module, and its own docblock states the premise that makes the fallback harmless:

Measured to change nothing for @objectstack/organizations itself (cloud-private, resolvable from nowhere in the framework workspace)

That premise is no longer true. PR #16215 brought the multi-organization runtime back to open core, so packages/plugins/organizations is now a tracked workspace package (20 files at a5eccf925), and this worktree's install carries node_modules/.pnpm/node_modules/@objectstack/organizations -> ../../../../packages/plugins/organizations. Once that package has a dist/ (its manifest names dist/index.js / dist/index.mjs), the fallback import resolves, probeOrganizations returns available: true, and the control that exists to pin the declared-unresolvable wording never reaches that wording at all.

Why CI is green on the same commit

Measured, not assumed. The Dogfood Regression Gate on a5eccf925 is success (all three shards plus Dogfood Verify CLI). CI runs pnpm turbo run test --filter=@objectstack/dogfood, and that task graph does not contain the organizations package:

turbo run test --filter=@objectstack/dogfood --dry=json
  tasks in graph: 67
  organizations tasks: []

So CI never builds packages/plugins/organizations, the import fails, and the control passes. A developer box that has run a full pnpm build sees the opposite.

Why this is worth a card

The verdict of a CONTROL now depends on whether an unrelated workspace package happens to have been built. In the direction seen here it is a false red on every local full-build tree, which costs every seat that runs the affected-package sweep a triage. The other direction is the one that matters more: a control whose subject is reachable is no longer controlling the thing its name claims, and nothing says so.

⛔ Not proposed as a fix here — whether the repair is a hermetic fixture root, a resolution guard, or a re-statement of the premise is a decision for whoever owns this suite.

Dedup

One targeted REST read of the 100 most recently updated issues and PRs, state=all (closed included). Positive control: the query returned #15892, the card this seat is working, so the read reached live data. Nothing in it names this test or this control. ⛔ Not exhaustive — one page, not a full-corpus sweep.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions