@vectros-ai/cli 0.6.5 → 0.6.7

package/dist/cli.mjs

@@ -481,10 +481,18 @@ var DocumentRequest;
     Text: "TEXT",
     None: "NONE"
   };
+  DocumentRequest2.Status = {
+    Active: "ACTIVE",
+    Archived: "ARCHIVED"
+  };
 })(DocumentRequest || (DocumentRequest = {}));
 var DocumentResponse;
 ((DocumentResponse2) => {
   DocumentResponse2.Status = {
+    Active: "ACTIVE",
+    Archived: "ARCHIVED"
+  };
+  DocumentResponse2.IndexStatus = {
     PendingUpload: "PENDING_UPLOAD",
     Uploaded: "UPLOADED",
     Extracting: "EXTRACTING",
@@ -5255,7 +5263,7 @@ var DocumentsClient = class {
     return handleNonStatusCodeError(_response.error, _response.rawResponse, "GET", "/v1/documents/{id}/versions");
   }
   /**
-   * Starts a file-based document by returning a short-lived presigned S3 PUT URL. Upload the file bytes directly to `uploadUrl`; the document is then automatically queued for text extraction and asynchronous indexing. Supplying an `externalId` makes this idempotent — re-initiating an upload with the same `externalId` re-issues a fresh presigned URL to the SAME existing document/object (so a re-upload inherently replaces the file body) rather than creating a duplicate. The response's `created` field (and the HTTP status — 201 when a new document was minted, 200 when an existing one was matched) tells the two apart. With `?upsert=true`, the submitted `payload`/`title` are also applied to the matched document (file-body divergence cannot be diffed at upload-init — the bytes have not arrived yet — so the re-upload itself replaces the body; `?upsert=true` requires the `documents:u` scope). Requires the `documents:c` scope.
+   * Starts a file-based document by returning a short-lived presigned S3 PUT URL. Upload the file bytes directly to `uploadUrl`; the document is then automatically queued for text extraction and asynchronous indexing. Supplying an `externalId` makes this idempotent — re-initiating an upload with the same `externalId` re-issues a fresh presigned URL to the SAME existing document/object (so a re-upload inherently replaces the file body) rather than creating a duplicate. The response's `created` field (and the HTTP status — 201 when a new document was minted, 200 when an existing one was matched) tells the two apart. With `?upsert=true`, the submitted `payload`/`title` are also applied to the matched document (file-body divergence cannot be diffed at upload-init — the bytes have not arrived yet — so the re-upload itself replaces the body). Creating a NEW document requires the `documents:c` scope. Re-uploading over an EXISTING document overwrites (and re-indexes) its body, so it is an update: it requires the `documents:u` scope (as does `?upsert=true` for the metadata).
    *
    * @param {Vectros.FileUploadRequest} request
    * @param {DocumentsClient.RequestOptions} requestOptions - Request-specific configuration.
@@ -9657,12 +9665,14 @@ var DATA_PLANE_ACTIONS = [
   "inference:r",
   "documents:r",
   "documents:c",
+  "documents:u",
   "folders:r",
   "folders:c"
 ];
+var EDITOR_ACTIONS = [...DATA_PLANE_ACTIONS, "records:d", "documents:d", "folders:d"];
 var agenticSdlc = {
   name: "agentic-sdlc",
-  version: "1.0.0",
+  version: "1.3.0",
   description: "A whole-SDLC system of record for an AI development team \u2014 decisions, designs, references, runbooks, post-mortems (as documents) plus controls, conventions, gotchas, and a glossary (as records), cross-linked and recalled by meaning.",
   contextId: "agentic-sdlc",
   contextName: "Agentic SDLC Knowledge Base",
@@ -10097,6 +10107,19 @@ var agenticSdlc = {
           fieldType: "date",
           description: "ISO-8601 last-reviewed date. Range-queryable.",
           renderHints: { label: "Reviewed on", widget: "date", order: 12 }
+        },
+        {
+          // Provenance for sync: the source file this record was distilled from. A
+          // record can't carry an in-file marker the way a document can (many records
+          // come from one file), so it names its source instead — a change to that file
+          // finds (equality lookup) and re-extracts exactly its records. Equality, not
+          // range: file-level is the sync unit (re-extraction reprocesses the whole file),
+          // and the schema keeps its single range lookup for the date row.
+          fieldId: "sourceRef",
+          fieldType: "string",
+          filterable: true,
+          description: "The source file (repo path) this record was extracted from \u2014 its provenance; a change to that file re-extracts its records. The specific section is encoded in the record externalId.",
+          renderHints: { label: "Source ref", widget: "text", order: 13 }
         }
       ],
       lookupFields: [
@@ -10106,7 +10129,8 @@ var agenticSdlc = {
         "area",
         "verifiedBy",
         "relatedDecision",
-        { fieldName: "reviewedOn", rangeEnabled: true }
+        { fieldName: "reviewedOn", rangeEnabled: true },
+        "sourceRef"
       ]
     },
     {
@@ -10183,9 +10207,23 @@ var agenticSdlc = {
           fieldType: "date",
           description: "ISO-8601 \u2014 when last revised. Range-queryable.",
           renderHints: { label: "Updated on", widget: "date", order: 9 }
+        },
+        {
+          // Provenance for sync — see the note on `control.sourceRef`.
+          fieldId: "sourceRef",
+          fieldType: "string",
+          filterable: true,
+          description: "The source file (repo path) this record was extracted from \u2014 its provenance; a change to that file re-extracts its records. The specific section is encoded in the record externalId.",
+          renderHints: { label: "Source ref", widget: "text", order: 10 }
         }
       ],
-      lookupFields: ["area", "status", "establishedBy", { fieldName: "updatedOn", rangeEnabled: true }]
+      lookupFields: [
+        "area",
+        "status",
+        "establishedBy",
+        { fieldName: "updatedOn", rangeEnabled: true },
+        "sourceRef"
+      ]
     },
     {
       // A GOTCHA / sharp edge: a symptom, its cause, and the fix. A tight typed
@@ -10239,9 +10277,22 @@ var agenticSdlc = {
           fieldType: "date",
           description: "ISO-8601 \u2014 when first hit. Range-queryable.",
           renderHints: { label: "Discovered on", widget: "date", order: 7 }
+        },
+        {
+          // Provenance for sync — see the note on `control.sourceRef`.
+          fieldId: "sourceRef",
+          fieldType: "string",
+          filterable: true,
+          description: "The source file (repo path) this record was extracted from \u2014 its provenance; a change to that file re-extracts its records. The specific section is encoded in the record externalId.",
+          renderHints: { label: "Source ref", widget: "text", order: 8 }
         }
       ],
-      lookupFields: ["area", "status", { fieldName: "discoveredOn", rangeEnabled: true }]
+      lookupFields: [
+        "area",
+        "status",
+        { fieldName: "discoveredOn", rangeEnabled: true },
+        "sourceRef"
+      ]
     },
     {
       // A glossary TERM — a definition keyed by the term itself. Structure-dominant:
@@ -10301,6 +10352,14 @@ var agenticSdlc = {
           fieldType: "date",
           description: "ISO-8601 \u2014 when last revised. Range-queryable.",
           renderHints: { label: "Updated on", widget: "date", order: 7 }
+        },
+        {
+          // Provenance for sync — see the note on `control.sourceRef`.
+          fieldId: "sourceRef",
+          fieldType: "string",
+          filterable: true,
+          description: "The source file (repo path) this record was extracted from \u2014 its provenance; a change to that file re-extracts its records. The specific section is encoded in the record externalId.",
+          renderHints: { label: "Source ref", widget: "text", order: 8 }
         }
       ],
       // `term` is a UNIQUE equality lookup — exact "define X" + a one-per-term
@@ -10309,7 +10368,8 @@ var agenticSdlc = {
         { fieldName: "term", unique: true },
         "area",
         "relatedDecision",
-        { fieldName: "updatedOn", rangeEnabled: true }
+        { fieldName: "updatedOn", rangeEnabled: true },
+        "sourceRef"
       ]
     }
   ],
@@ -10327,11 +10387,13 @@ var agenticSdlc = {
   // grants the human none by default. Bind it after bootstrap with:
   //   vectros access grant --principal usr_<your-user-id> --context agentic-sdlc --role editor
   // (or the admin app's Access > Contexts > agentic-sdlc > Profiles > Create).
-  // Editor PARITY with the service key (same DATA_PLANE_ACTIONS) so a human
-  // curator can browse AND write/correct the KB; still no :d and no control-plane
-  // action, so the scope gate accepts it exactly like the accessProfile.
+  // The editor gets the full data plane so a human curator can browse, write/correct,
+  // AND hard-delete the KB (EDITOR_ACTIONS = the service key's set + delete). The
+  // service key deliberately lacks delete and archives instead; the trusted human
+  // owner may permanently remove genuine strays. Still no control-plane action, so
+  // the scope gate accepts it as a data-plane-only role.
   roles: {
-    editor: [{ allowedActions: DATA_PLANE_ACTIONS }]
+    editor: [{ allowedActions: EDITOR_ACTIONS }]
   },
   servicePrincipal: {
     externalId: "agentic-sdlc",
@@ -14010,9 +14072,9 @@ async function runBlueprintTest(fileOrName, opts, deps = {}) {
 
 // src/build-info.ts
 var BUILD_INFO = {
-  cli: true ? "0.6.5" : "dev",
-  sdk: true ? "0.31.0" : "dev",
-  blueprints: true ? "0.6.3" : "dev"
+  cli: true ? "0.6.7" : "dev",
+  sdk: true ? "0.32.0" : "dev",
+  blueprints: true ? "0.6.5" : "dev"
 };
 function formatBuildInfo() {
   return `vectros ${BUILD_INFO.cli} (sdk ${BUILD_INFO.sdk}, blueprints ${BUILD_INFO.blueprints})`;