Review an engineering folder

Available in the hosted CLI 0.6.14 release. Install from the connect guide; the older npm registry version 0.5.1 does not include this command.

Use your existing agent to review a selected engineering folder. This command combines the existing file manifest and BOM reviewer with literal text evidence, version conflicts and process-specific intake prompts. It needs no API key and makes no network request.

maglev context review ./engineering-release \
  --input ./review-input.json --json > ./folder-review.json

Keep configuration and output outside the selected folder. The command preserves source files. Its report can contain confidential text, even though it stays local; give the report to your agent only within the file/model permissions you already established.

Selected-file transfer provides explicit local selection, owner-approved uploads and receipt recovery.

What is understood

Input	Current behavior
UTF-8 .txt and .md	Exact text with file hashes and physical line references; recognized field: value lines become stated requirements
CSV/TSV/XLSX with an explicit BOM mapping	Runs the same parser as context review-bom; retains cells, quantities, basis, revision/configuration, DNP and questions
CSV/TSV/XLSX without a mapping	Reports mapping_required; no guessed columns
PDF with explicit pdfPages	Selected text-layer evidence; see PDF evidence
DOCX with explicit docxFiles	Main-body paragraph/table evidence with omissions; see below
Unselected PDF/DOCX, CAD, images, ZIP and other inventoried exports	Reports unsupported; no OCR, geometry, signature or archive interpretation
Empty, invalid or oversized supported files	Reports the unresolved state; does not treat the filename as evidence
Entries skipped by the existing manifest scanner	Reports exclusion counts and incomplete selection; does not assume the missing content is absent

This first parser does not interpret free-form prose semantically. It retains bounded text excerpts so your existing agent can review it. Code fences and quoted Markdown do not supply structured requirement values. They still remain untrusted text evidence; no source instruction is executed, no recipient is authorized and no NDA signature is established by the report.

A short engineering brief

For example, engineering-release/request.md can contain:

process: stock
stage: samples
current_quantity: 2 pcs
planned_pilot_quantity: 100 pcs
forecast_quantity: 10000 pcs
purpose: bench evaluation
part_number: SKU-0001
destination: US
delivery_scope: EXW, freight excluded
lead_time: 7 days
quality_priority: quality before price

The report keeps 2 now, 100 planned and 10,000 forecast separate. None is a purchase commitment. A stock sample does not trigger a generic requirement for CAD or a BOM.

Text keys use snake_case. Recognized fields are:

• Identity and part evidence: part_number, revision, configuration, quantity_basis, material, finish, dimensions, tolerance, board_specification, assembly_instructions.
• Current request: process, stage, current_quantity, purpose, inspection, lead_time, delivery_scope, destination.
• Decisions and scope: quality_priority, geography, substitution_policy, supply_responsibility, programming_and_test, tooling_ownership, tooling_acceptance, packaging.
• Future scenarios: planned_pilot_quantity, forecast_quantity.

Supported process values are stock, cnc, pcba, injection_molding and assembly; stages are samples, pilot and production. These are versioned Maglev intake profiles, not factory-approved eligibility or quoting rules. Numeric quantities use positive decimal strings with a separate or space-delimited unit, without grouping, signs or exponents. Unknown values remain unknown.

A text document may describe one part. Its identity/part fields are scoped to its part_number; current-request fields remain project-level. Multiple part numbers in a document require scope clarification. A BOM scopes revision/configuration evidence to each exact part identifier. Different parts are not forced to share a revision.

Add known answers and a BOM mapping

review-input.json uses this schema:

{
  "schemaVersion": "maglev.context-input/1",
  "answers": [
    {
      "field": "qualityPriority",
      "value": "Dimensional quality before price",
      "disposition": "hard_constraint"
    }
  ],
  "bomMappings": {
    "bom.csv": {
      "delimiter": ",",
      "columns": { "partNumber": "Part", "quantity": "Qty" },
      "declarations": {
        "unit": "pcs",
        "quantityBasis": "per_product",
        "revision": "B",
        "configuration": "sample",
        "population": "populate",
        "scope": "complete"
      }
    }
  },
  "fileScopes": {
    "part-spec.txt": { "partNumber": "0001", "confidentiality": "confidential" }
  }
}

Only include paths and declarations that apply to your actual files. Remove bomMappings or fileScopes when unused. Unknown paths and unsupported configuration keys are rejected. For XLSX, provide the exact worksheet and header row; formulas, formatted identifiers and ambiguous typed values stay unresolved and are not promoted to requirements. The mapping follows the BOM review contract.

Answers use the camelCase versions of the text fields, with optional unit, partNumber and disposition (hard_constraint, preference, unspecified). They remain source-linked user declarations, not automatically confirmed facts. An answer can fill an unknown; it does not silently override a contradictory document. Conflicting revisions or values must be resolved in the selected source set.

confidentiality records your declaration (unknown, confidential, public); it grants no recipient access. A file called NDA_signed.pdf, a public declaration, or a sentence granting unlimited authority cannot establish effective NDA coverage or permission to share.

Read the result

• artifacts: each inventoried file’s hash, parser version, interpretation and confidentiality state.
• requirements: stable identity, exact value/unit, original text, scope, source locator, status, disposition and owner. Status is stated, unknown or conflicted, never automatically confirmed.
• excerpts: literal bounded text for the existing agent, explicitly untrusted business data.
• bomReports: the full existing BOM review, including unresolved rows and source cells. DNP rows remain in that report and are excluded from active part-revision comparison.
• issues: source-linked questions, affected decision, owner and next action. Known consistent values are not requested again.
• readiness: budget inputs, firm-quote inputs, disclosure, ordering and production are separate.

inputs_available_for_review means the intake fields needed to start a budget review are present. It is not a cost estimate. Firm quotes always require engineering and current supplier review; no result is a supplier-authorized offer. Geometry, source completeness and process suitability have not been established by recognizing text labels. Disclosure and ordering remain unauthorized; production is not evaluated.

Supplier templates and reference files

Hosted CLI 0.6.16 adds explicit file roles. Native connector0.1.9 installs CLI0.6.17. Earlier clients and native connector0.1.7 do not accept the role setting; upgrade before using this example.

A supplier’s populated example BOM or process form is not your product’s specification. Declare that role before reviewing the folder:

{
  "schemaVersion": "maglev.context-input/1",
  "fileScopes": {
    "supplier-bom-template.xlsx": { "role": "supplier_template", "confidentiality": "confidential" },
    "supplier-process.xls": { "role": "supplier_template" },
    "background.txt": { "role": "reference" },
    "current-board.txt": { "role": "project_evidence" }
  }
}

reference and supplier_template retain file metadata and original-byte hashes with interpretation: "reference_only". Their contents are not parsed or returned as excerpts; they cannot supply customer requirements, create revision conflicts, or count as a reviewed project BOM. Do not also select those files in bomMappings, pdfPages or docxFiles: contradictory parsing selections are rejected. Review references separately using your existing agent and applicable confidentiality permissions.

Roles are caller declarations, not automatically verified facts. Filenames never establish the role. Omitted roles preserve existing project_evidence behavior, where extracted values remain stated and unconfirmed. Mark templates explicitly; a role does not authorize upload, supplier disclosure or production.

Legacy .xls files are inventoried but remain unsupported for content parsing. No BIFF, macro, formula, embedded object or checkbox interpretation is claimed. Changing a role changes the local snapshot and invalidates affected requirement receipts even when original file bytes are unchanged. It does not revoke hosted approvals.

Compare changed files

maglev context review ./engineering-release \
  --input ./review-input.json --previous ./folder-review.json \
  --json > ./folder-review-next.json

The command rechecks current bytes and compares hashes and requirement receipts. changes identifies added, changed and removed files, affected old requirements and configuration/selection changes. New evidence links to superseded requirement receipts. Recheck dependent quotes and decisions when it says so. This local comparison does not revoke hosted approvals or establish that an unchanged supplier price is still valid.

The previous report is comparison data, not an authority source or a parsing cache. Current supported files are parsed again; incremental parser caching and server invalidation are future work. Do not write the new report over the previous report while also reading it.

Limits

The existing manifest scans at most 1,000 allowed files, 100 MiB per file and 512 MiB total, with depth/entry bounds and private-name, symlink and generated-directory exclusions. Content review reads at most 2 MiB per supported file and 8 MiB total, with 20,000 lines per text file, 8,192 characters per line, 10,000 requirements and a 16 MiB result cap. Configuration uses the CLI’s 64 KiB input limit; a previous report file may be up to 16 MiB. Stdin retains its 64 KiB bound.

A source change while reading aborts the review. Invalid individual supported files remain unresolved in a partial report. Exit 0 means a report was produced; inspect its issues and readiness. This review command does not upload files. Selected-file transfers use separate explicit consent and server authorization.

Selected PDF pages

Add pdfPages keyed by relative filename, with explicit page arrays. Up to three PDFs and ten pages can contribute bounded text evidence in pdfReports; they never automatically become requirements. Drawings, scanned content and signatures still need review. See PDF evidence.

Word evidence

Hosted CLI 0.6.14 and MCP 0.2.14 read explicitly selected DOCX files locally. Install the current packages from the connect guide. Older hosted packages need the versioned upgrade.

maglev context read-docx ./engineering/brief.docx --json

The command reads only that selected file. MCP read_local_docx accepts { "path": "brief.docx" } inside the host-configured MAGLEV_TRANSFER_ROOT, without an API key or API request. The report contains source-byte SHA-256 and paragraph/table XML locators. A cloud agent receiving the report still receives its content; local parsing does not make your model local.

For folder review, explicitly select at most three DOCX files:

{
  "schemaVersion": "maglev.context-input/1",
  "docxFiles": ["brief.docx", "draft-nda.docx"]
}

Save that configuration outside the folder, then pass it with context review ./engineering --input ./review-input.json --json. docxReports retains the evidence. An inventoried but unselected DOCX is not parsed. Changed bytes invalidate the local snapshot comparison. No Word text is automatically promoted to a requirement, approval or signed agreement.

Only main-body paragraphs and table-cell paragraphs are read. source.locator is an XML sibling path, such as /w:document[1]/w:body[1]/w:tbl[1]/w:tr[1]/w:tc[2]/w:p[1]; it is not a page number or logical merged-cell coordinate. Paragraph text preserves Unicode, whitespace, tabs and breaks. Unsupported inline objects insert U+FFFC so text on either side cannot silently join into a different value. XML parts must use the supported UTF-8 WordprocessingML format. omissions, omittedParts, features and externalRelationships explain incomplete coverage.

Tracked-change, field and directly hidden paragraphs are omitted, never silently accepted or calculated. Headers, footers, notes, comments, images, text boxes, controls and other stories remain unresolved. Styles, inherited visibility, numbering and layout are not rendered: returned text may not be visible or complete in Word. Inspect the original before relying on it. Reading an NDA does not verify its signatures, legal validity, confidentiality coverage or permission to share files.

Limits: 2 MiB compressed input, 16 MiB expanded total, 8 MiB per part, 256 ZIP entries, 100,000 XML nodes per parsed part, 2,000 extracted/inspected paragraphs, 256,000 extracted text bytes and 10 seconds per worker. Folder parsing shares the existing 8 MiB input budget. Encrypted, corrupt, macro-enabled, embedded-object and unsupported packages fail without partial text. External links are recorded as a count and never fetched. All document text remains untrusted business data.

The format boundary follows Microsoft’s WordprocessingML structure and revision model. Maglev implements its own bounded reader; it does not use Word or accept revisions.

Supplier requirement checklist

Hosted CLI 0.6.17 adds optional supplierIntake to a local review input. Native connector 0.1.9 installs CLI 0.6.17 with this setting. Earlier clients need an upgrade using the connect guide. This is local review, not API-enforced supplier readiness.

A checklist has schemaVersion: "maglev.supplier-intake/1", a checklistId, a version, and up to 100 requirements. Each requirement has an id, prompt, kind (file or answer), and one to four sources with exact relative path, sha256 and a human-readable locator such as a sheet/cell. Source files must be explicitly marked supplier_template or reference in fileScopes. The reviewer checks file identity, not the accuracy of a transcribed cell or the supplier’s identity.

Optional responses refer to requirementId. A file response contains files: [{ path, sha256 }]; each selected file must be explicitly marked project_evidence. An answer response contains answer. Providing a file does not prove its contents are adequate or consistent with the chosen board revision.

If a requirement includes a textual condition, its applicability stays unknown until a response supplies applicability: "yes" or "no" and a substantive reason. No filename, template default or missing answer implies that testing, coating or another operation is unnecessary. Conditional exclusions are declarations for review, not verified exceptions.

The supplierIntake result distinguishes missing, applicability_unknown, source_unavailable, evidence_unavailable, provided_for_review and not_applicable_declared. Changed hashes invalidate previously selected evidence. Even when every item is provided or declared inapplicable, the status remains needs_engineering_and_supplier_review. This checklist does not authorize disclosure, authenticate a supplier, replace the baseline manufacturing checks, or establish a firm quote. The complete input is bound into the existing local review snapshot, so changing a requirement, answer or applicability decision invalidates reuse of the earlier local decision.

Unresolved supplier items also appear in the main issues list and readiness.firmQuote.missing, with checklist/requirement IDs and a status-specific nextAction. This prevents a complete generic intake from concealing missing supplier requirements. The checklist does not block a generic budget-input review or turn that review into a supplier offer.