Skip to content

fix(project): name the project a memory belongs to, and refuse to guess it - #558

Open
kevintseng wants to merge 4 commits into
mainfrom
fix/project-attribution
Open

kevintseng wants to merge 4 commits into
mainfrom
fix/project-attribution

Conversation

@kevintseng

Copy link
Copy Markdown
Contributor

Refs #527

What changes for you

  • learn can now be told which project a lesson belongs to: project over MCP, memesh learn --project on the CLI. POST /v1/learn requires it; without it the request is refused and nothing is written.
  • When the MCP server runs inside MeMesh's own folder (Codex starts plugin servers there), it cannot tell which project you are in. learn, task_state and briefing without project are refused there with one line saying what to pass. A server started in your workspace (Claude Code) behaves as before.
  • An empty or path-shaped project name is refused everywhere a project is written. Otherwise a project name is used exactly as given, so a task state or lesson is found again under the same spelling.
  • Existing path-shaped project keys can still be read over GET /v1/task-state and GET /v1/briefing-index.
  • The PreCompact hook no longer saves a snapshot when its input has no usable session id or folder; it records why instead.

Checks

  • npm run verify green for this tree.
  • New and updated tests cover the HTTP 400, the CLI refusals, the MCP refusal in MeMesh's own folder, the exact-spelling round trip and the PreCompact skips.

…ss it

- `learn` takes an optional `project` over MCP and `memesh learn --project`
  (omitted, it uses the current directory's project, as `task_state` and
  `briefing` do). `POST /v1/learn` requires `project`: the HTTP server's
  own directory is never the caller's project, so a missing one is a 400
  and nothing is written.
- An MCP server running in MeMesh's own directory (Codex starts plugin
  servers in the plugin's directory) cannot tell which project the caller
  is in: `learn`, `task_state` and `briefing` without `project` are refused
  there with one line saying to pass the project the SessionStart briefing
  gave. A server started in a workspace (Claude Code) is unchanged.
- `learn`, `task_state`, `briefing` and the CLI's `task`, `briefing`,
  `import --notes` and `learn` refuse an empty or path-shaped project,
  absolute or relative. A project name is otherwise used exactly as given
  everywhere, so a stored task state or lesson is found again under the
  same spelling.
- `GET /v1/task-state` and `GET /v1/briefing-index` still read an existing
  path-shaped project key exactly as stored; writes to one are refused.
- The PreCompact hook skips a payload whose `session_id` or `cwd` is
  missing, blank or not a string, and records why.

Refs #527
# Conflicts:
#	CHANGELOG.md
#	dist/mcp/THIRD_PARTY_NOTICES.txt
#	dist/mcp/server.js.map
#	dist/transports/mcp/handlers.d.ts.map
#	dist/transports/mcp/handlers.js.map
…t errors

- A project name longer than 200 characters is refused by `learn`,
  `task_state`, `briefing` and the CLI's `task`, `learn` and `briefing`,
  the same limit the read routes already applied; before, the CLI stored
  a key that the dashboard and MCP could not read back.
- When a project cannot be determined from the working directory, the
  error says how to find it: run `memesh briefing --json` in the workspace
  and pass its `project` field.
- The exported OpenAI tool schema for `learn` says that HTTP requires
  `project`.
- The changelog and API reference state the rules precisely: they apply
  to `learn`, `task_state` and `briefing` (messaging and
  `kg rename-project` are unchanged), and a server run from the checkout
  it is started in counts as MeMesh's own directory.

Refs #527

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant