Reported issues for Lex

Pod holds 20 of 127 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Lex.

Most discussed

[Ecosystem 3.1] Prove the cross-repository release dependency graph

Thesis

Ecosystem 3.1 is a documented, evidence-backed release train across the Lex toolset. It is not merely a sprint label and it does not force every package to adopt version 3.1.0.

Each repository retains honest package semver. The release train closes only when one reviewed compatibility manifest identifies the exact compatible commits, package versions, signed tags, runtime floors, dependency relationships, and proof receipts for every required component.

Published baseline

Read the thread · 2026-07-21 · open · 9 comments

Lex 3.1: adopt Node 24 as the sole supported runtime floor

Parent

• Ecosystem release train: #780
• Final Lex/Lex-MCP publication leaf: Guffawaffle/lex-mcp#11

Problem

Lex currently advertises and selects Node 20 through 24 across package metadata, current documentation, tests, release workflows, registry publication, and maintenance jobs. Ecosystem 3.1 deliberately drops the historical Node 20/22 floor.

The current >=20 <25 range also carries an accidental upper bound that would reject newer Node releases without evidence.

Outcome

Make

Read the thread · 2026-07-21 · closed · 5 comments

Reorganize config layout: Move working files to .smartergpt.local/lex/

Problem

Currently, lex stores its working policy file at src/policy/policy_spec/lexmap.policy.json, which creates UX confusion:

1. Namespace collision: When users install lex in their own projects and create their policy files, they might accidentally overwrite lex's own policy or be confused about which file to edit
2. No separation of concerns: Template/example files are mixed with actual working configuration
3. Not following industry best practice: Most tools use a dedicat

Read the thread · 2025-11-09 · closed · 5 comments

Create @smartergpt/lex-mcp wrapper package for MCP registry

Problem/Goal

The MCP registry requires mcpName to be in the package that is the identifier in server.json. The registry validates by fetching that package from npm and checking its package.json.

Additionally, npx <package> invokes the default bin of the package. If we added lex-mcp as a second bin to @smartergpt/lex, users running npx @smartergpt/lex would get the CLI, not the MCP server.

Solution: Create a dedicated package @smartergpt/lex-mcp whose only job is

Read the thread · 2025-12-31 · closed · 4 comments

[Policy] Generate deterministic scanner-compatible maps for C/C++ repositories

Problem

lex init --policy currently assumes a root src/ tree and only recognizes TypeScript/JavaScript files. C/C++ repositories and monorepos such as stfc-mod therefore produce an empty policy, even though Lex Frames and scanners require stable module IDs.

The current generator also emits match, while first-party scanner module resolution consumes owns_paths, so generated policy can be schema-valid without actually scoping scanner facts.

Dogfood evidence

• Repository: `Guffa

Read the thread · 2026-07-25 · closed · 3 comments

Document and support shared Lex DB configuration for multi-root VS Code workspaces

Observation

In a multi-root VS Code workspace, Lex MCP and Lex CLI appeared to use different stores by default:

• mcp_lex_system_introspect reported frames: 17 and branch guffa-dev.
• Running lex introspect --json from D:\dev\stfc-mod-sidecar reported frameCount: 0 and branch feature/basic-log-viewer.
• Running lex introspect --json from D:\dev\stfc-mod reported frameCount: 0 and branch guffa-dev.

For this workspace, the desired behavior is a workspace-level memory st

Read the thread · 2026-05-03 · closed · 3 comments

Governance: Add Capability Tier Classification to Frames

Overview

Governance Alignment: Implements Capability Tiers from our coordination cost compression thesis.

Claim 3.4: Matching task tier to model capability reduces overall Turn Cost by avoiding both over-allocation (expensive models on trivial tasks) and under-allocation (failures requiring escalation).

Status

Milestone: Lex 2.2+ (post-freeze)

Implementation Guidance for Copilot

Capability Tiers (from thesis)

| Tier | Role | Example Tasks | Characteristics

Read the thread · 2025-12-05 · closed · 3 comments

Define tenant-scoped sensitive-data lifecycle for Frames, logs, receipts, caches, and artifacts

Threatened boundary

Tenant privacy and sensitive-data lifecycle across Lex and its downstream evidence surfaces.

Attack / failure scenario

Patient data, credentials, proprietary source, or other sensitive content enters Frame text, metadata, errors, logs, receipts, attachments, caches, exports, backups, or downstream embeddings. It is then over-retained, redisclosed to another principal, echoed in diagnostics, or survives an expected deletion.

Current behavior and evidence

Current

Read the thread · 2026-07-23 · open · 2 comments

Most recent

test: bound MCP worker lifecycle and release gate hangs

Evidence

Lex v4.0.4 tag workflow run 33279757343 hung in npm test after MCP Server - Idempotency (AX-008) completed successfully. The exact same SHA (381c52bff91372b307313c9f138543c3f5fbdc6a), Node 24.14.1, npm 11.11.0, runner image, and npm run ci:full command had passed in publication run 33241279551. A single unchanged rerun passed, so this was a transient worker-lifecycle stall rather than a 4.0.4 assertion failure.

On cancellation, GitHub cleaned up the npm run ci:full / `npm

Read the thread · 2026-08-29 · open · 0 comments

[Dogfood] Add stfc-mod-bridge as a local-first workspace with explicit shared recall

Dogfood finding

The now-separate Guffawaffle/stfc-mod-bridge repository needs its own continuity boundary. It is not the native stfc-mod workspace and it is not stfc-companion/sidecar.

A native Windows Bridge workspace setup on 2026-08-12 exposed two simultaneously useful stores:

• preferred repo-local SQLite: .smartergpt/lex/memory.db, Bridge policy loaded with 8 modules, one Bridge-owned Frame;
• organizational PostgreSQL corpus: 666 Frames, reachable through the user-level Lex/A

Read the thread · 2026-08-12 · open · 0 comments

[Compatibility] Add Code Index aliases for code-atlas surfaces

Context

The terminology map in #805 classifies source/symbol extraction, CodeUnit, CodeAtlasRun, the code-atlas command, atlas_analyze, and /api/atlas/* as the experimental Code Index subsystem.

Several existing names are public commands, routes, package paths, or serialized schema literals. Migration must therefore be additive.

Scope

• Add a code-index CLI alias while retaining code-atlas.
• Add a Code Index MCP tool alias while retaining atlas_analyze and existing

Read the thread · 2026-07-27 · open · 0 comments

[Architecture] Split overloaded Atlas terminology into Policy Neighborhood, Code Index, and Frame Graph

Problem

"Atlas" currently names three materially different Lex systems:

1. Policy neighborhood — bounded policy/module context generated around a Frame's module scope and used during recall.
2. Code Index — experimental TS/JS/Python source-unit extraction and provenance.
3. Frame graph — a derived graph connecting historical Frames by module overlap, branch, and temporal proximity.

Using one product term for all three obscures ownership, stability, consumers, performance work,

Read the thread · 2026-07-27 · closed · 1 comment

[Dogfood] Align MCP Frame fallback and policy health with the CLI write contract

Problem

The CLI work completed by #730 exposes a shared Frame write contract and the canonical workspace/unscoped fallback. The MCP path does not provide equivalent recovery.

Live Windows/STFC dogfood evidence in #800:

• frame_validate rejects module_scope: [];
• the error does not disclose the exact valid fallback payload;
• callers succeed only if they already know to send module_scope: ["workspace/unscoped"];
• MCP introspection reports that policy is unavailable but does not ex

Read the thread · 2026-07-27 · closed · 1 comment

Post-4.0 security roadmap: tenant proof, protected execution, and future clinical authority

Disposition

This issue preserves the security and authority research performed after the Lex 4.0.0 release candidate was complete. It is potential post-4.0 work, not a dependency of Lex PR #791, and it does not hold Ecosystem 3.1 / Lex 4.0.0.

The previous Sanctuary hold and blocker classification are superseded by this scope correction.

The bounded Lex 4.0.0 release

Lex 4.0.0 returns to the release scope recorded by PR #791 at signed c

Read the thread · 2026-07-23 · open · 1 comment

Fail closed when scoped LexSona context is missing or mismatched

Threatened boundary

Repository/project/module/task containment of behavioral memory exposed through Lex and LexSona.

Attack / failure scenario

A caller omits an authority-relevant context dimension. A rule scoped to another project, module, or task is then selected because the implementation only compares dimensions present on both the rule and request. The caller learns victim text or existence, or the foreign correction silently influences its behavior.

Current behavior and eviden

Read the thread · 2026-07-23 · open · 1 comment

Bound tenant-scoped MCP payload, query, cache, and concurrency costs

Threatened boundary

Availability and cross-tenant side-effect containment on a shared Lex MCP/runtime process.

Attack / failure scenario

An authorized or compromised tenant submits oversized Frame content, unbounded list/search/contradiction limits, many unique idempotency keys, or concurrent expensive operations. The tenant exhausts memory, CPU, storage, database connections, or event-loop capacity and affects other tenants without crossing an RLS row boundary.

Current behavior and

Read the thread · 2026-07-23 · open · 1 comment

Make trusted CLI filesystem and process effects explicitly authorized and contained

Threatened boundary

Delegated workspace/repository authority on Lex's trusted CLI surface.

Attack / failure scenario

A principal with any valid scoped grant invokes a CLI operation mapped to no capabilities, supplies an arbitrary project root, policy path, repository, or output path, and reads or mutates files outside the authorized workspace. An internal CLI route thereby bypasses restrictions enforced on the MCP surface.

Current behavior and evidence

`src/shared/runtime-scope/cap

Read the thread · 2026-07-23 · open · 1 comment

Prove tenant containment with distinct adversarial principals and negative controls

Threatened boundary

Tenant containment across every supported Lex application surface.

Attack / failure scenario

A principal authorized only for Tenant A attempts to observe, enumerate, infer the existence of, mutate, or indirectly affect a real object owned by Tenant B through CLI, MCP, library, or database-backed application paths.

The current PostgreSQL dogfood canary does not model that attacker. src/shared/runtime-scope/dogfood-topology.ts grants one principal membership in both

Read the thread · 2026-07-23 · open · 1 comment

[Ecosystem 3.1] Delete-first documentation recalibration and migration contract

Thesis

Ecosystem 3.1 must not publish until a human or agent can identify the exact compatible package set, migrate without guessing, recognize bounded failure states, and return to a known-good state without destructive improvisation.

This is a delete-first recalibration, not an invitation to preserve every historical document by rewriting it. Current normative guidance should become smaller, coherent, executable, and visibly separated from historical release evidence.

Parent release depe

Read the thread · 2026-07-23 · closed · 2 comments

PostgreSQL compatibility writes fail after scoped schema migration

Summary

lex remember fails against the configured PostgreSQL FrameStore after the database has reached FrameStore schema v3:

Error: there is no unique or exclusion constraint matching the ON CONFLICT specification

This was discovered while attempting to persist the first LexRunner Ecosystem 3.1 sprint Frame. Dry-run validation succeeded; the durable write failed. The failure itself should become carryover evidence rather than being hidden by switching stores.

Observed env

Read the thread · 2026-07-19 · closed · 0 comments

The remaining reports are on the project's issue tracker.