@projectctx/agent 0.1.0-alpha.0 → 0.1.0-alpha.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/mcp.js +3 -2
- package/package.json +3 -3
package/dist/mcp.js
CHANGED
|
@@ -29,9 +29,10 @@ export function createMcpServer(logger) {
|
|
|
29
29
|
logger?.debug("creating MCP server");
|
|
30
30
|
const server = new McpServer({ name: "projectctx-agent", version: "0.1.0-alpha.0" });
|
|
31
31
|
logger?.debug("registering MCP tool: scan_workspace");
|
|
32
|
-
server.tool("scan_workspace", "Scan a local workspace with the ProjectCtx scanner and return structured JSON. Read-only: no memory writes or cloud calls.", {
|
|
32
|
+
server.tool("scan_workspace", "Scan a local workspace with the ProjectCtx scanner and return structured JSON. Read-only: no memory writes or cloud calls. The result includes auditTargets[]: EVERY content-bearing folder — git repos AND plain folders (docs, notes, research, campaigns) — each with facts and a suggestedReadPlan. Coverage mandate: do not silently skip any audit target, and never infer meaning from folder or file names — meaning comes from reading the actual file contents. If your host can spawn subagents, fan out MULTIPLE IN PARALLEL, roughly one focused subagent per audit target; when targets number in the dozens or more, cluster related targets per subagent rather than skipping any. If the host cannot spawn subagents, make sequential focused passes over each target. Each subagent must open and read its target's suggestedReadPlan files, then read further into the real source/docs/notes until it genuinely understands the target (read real code in repos, not just the README), and report anything meaningful it finds. Subagents return memory candidates — never writes — e.g. Project, Person, Decision, Research Thread, Campaign, Experiment, Service, Dataset, Open Question, Source (open-ended; capture other meaningful things too), each with title, type, why it matters, source file path(s), confidence, suggested collection, and suggested relationships. Then dedupe candidates against existing memory (get_workspace_schema + search_memory/query_records): exact match → reuse/update; similar → warn and ask the user; propose a new collection only if genuinely needed. Ask the user before writing anything; use the preview/apply flow only.", {
|
|
33
33
|
rootPath: z.string().optional(),
|
|
34
34
|
maxRepos: z.number().int().positive().optional(),
|
|
35
|
+
maxTargets: z.number().int().positive().optional(),
|
|
35
36
|
maxFilesPerRepo: z.number().int().positive().optional(),
|
|
36
37
|
maxExcerptBytes: z.number().int().positive().optional(),
|
|
37
38
|
maxDepth: z.number().int().positive().optional(),
|
|
@@ -58,7 +59,7 @@ export function createMcpServer(logger) {
|
|
|
58
59
|
}
|
|
59
60
|
});
|
|
60
61
|
logger?.debug("registering MCP tool: preview_code_memory");
|
|
61
|
-
server.tool("preview_code_memory", "Compile codebase scan context and an agent-written code brief into a ProjectCtx memory preview. No durable memory writes are applied.", previewCodeMemorySchema.shape, async (input) => {
|
|
62
|
+
server.tool("preview_code_memory", "Compile codebase scan context and an agent-written code brief into a ProjectCtx memory preview. No durable memory writes are applied. Write each repo brief self-contained: describe the repo on its own terms; do not define it by contrast to sibling records. To group repos, reuse an existing Project rather than forking a parallel one — the compiler reuses an exact-name match and returns warnings that surface similar-named existing projects. Read the returned warnings before you apply. To reuse a surfaced project, pass its externalId as projectExternalId when it has one, or reuse it by its exact title/alias when it does not — projectExternalId accepts only an externalId, never a record id. The flow self-provisions its own code ontology: the Repos and Projects collections and the builds relationship type are reused if they already exist, otherwise created on the fly, and are POPULATED in the same pass (repo + project records, builds links) — so scanning into a brand-new empty workspace needs no seeding. Separately, if the repo context clearly describes an entity type no existing collection covers (e.g. Services, People, Datasets), you may propose it in the optional collections[] input; those emergent collections are created/reconciled by name (exact-name reuse, fuzzy warning) but are NOT populated by code-memory yet — they are created empty. Prefer an existing collection; do not propose one just because a topic is mentioned in passing.", previewCodeMemorySchema.shape, async (input) => {
|
|
62
63
|
try {
|
|
63
64
|
return jsonText(await runPreviewCodeMemory(previewCodeMemorySchema.parse(input), logger));
|
|
64
65
|
}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@projectctx/agent",
|
|
3
|
-
"version": "0.1.0-alpha.
|
|
3
|
+
"version": "0.1.0-alpha.2",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"files": [
|
|
6
6
|
"dist",
|
|
@@ -29,8 +29,8 @@
|
|
|
29
29
|
"pack:verify": "node scripts/verify-package.mjs"
|
|
30
30
|
},
|
|
31
31
|
"dependencies": {
|
|
32
|
-
"@projectctx/contracts": "0.1.0-alpha.
|
|
33
|
-
"@projectctx/indexer": "0.1.0-alpha.
|
|
32
|
+
"@projectctx/contracts": "0.1.0-alpha.2",
|
|
33
|
+
"@projectctx/indexer": "0.1.0-alpha.2",
|
|
34
34
|
"@modelcontextprotocol/sdk": "^1.13.1",
|
|
35
35
|
"@napi-rs/keyring": "^1.3.0",
|
|
36
36
|
"zod": "^3.25.67"
|