salesforce-metadata-mcp 2.8.7 → 2.11.2

package/CHANGELOG.md

@@ -1,5 +1,469 @@
 # Changelog
 
+## [2.11.2] - 2026-08-06
+
+### Security — resolved all 5 production-dependency advisories (2 high, 3 moderate)
+
+`@modelcontextprotocol/sdk` bumped `1.29.0` → `1.30.0` (minor, non-breaking). Every advisory traced
+back to that one dependency:
+
+| Package | Advisory | Severity |
+|---|---|---|
+| `@modelcontextprotocol/sdk` | vulnerable range 1.25.0–1.29.0 | moderate |
+| `@hono/node-server` | path traversal in `serve-static` on Windows via encoded backslash (`%5C`) | moderate |
+| `hono` | ReDoS in CORS middleware via `Access-Control-Request-Headers` | moderate |
+| `ip-address` | leading-zero octet / CIDR-suffix / IPv4-mapped-IPv6 parsing bugs enabling SSRF and trust-boundary bypass (3 advisories) | high |
+| `fast-uri` | host confusion via backslash authority introducer | high |
+
+Only two of these actually required a change here. `hono`, `fast-uri`, and `ip-address` sit under
+parent ranges (`^4.11.4`, `^3.0.1`, `^10.2.0`) that already admit their patched versions, so any fresh
+install resolves them safely regardless of what this repo's lockfile happens to pin. `@hono/node-server`
+did not: SDK 1.29.0 constrained it to `^1.19.9`, which cannot reach the patched 2.0.5. SDK 1.30.0
+widens that to `^1.19.9 || ^2.0.5`. The SDK's own advisory needed the bump too.
+
+**Note on why the lockfile is not the fix.** This package is a library — consumers resolve from the
+`dependencies` ranges in `package.json` at install time and never see `package-lock.json`. Running
+`npm audit fix` alone would have cleaned the local `npm audit` output while changing nothing for
+anyone installing from npm. The dependency bump is what actually reaches users, and only once
+published.
+
+Resolved after the bump: `@modelcontextprotocol/sdk` 1.30.0, `@hono/node-server` 2.1.0, `hono` 4.13.0,
+`fast-uri` 3.1.5, `ip-address` 10.4.0. `npm audit` reports 0 vulnerabilities for both production and
+full trees.
+
+Verified beyond the audit output, since the SDK is the protocol layer and a clean `tsc` proves nothing
+about runtime: **stdio** transport handshakes and lists 223 tools; **HTTP** transport (`TRANSPORT=http`)
+serves `/health`, completes an `initialize` over `/mcp`, 404s unknown paths, and still binds
+`127.0.0.1` by default (the v2.8.8 hardening is intact — this mattered to check, as the changed
+packages are exactly the ones behind that transport); and a real `tools/call` round-trip dispatches
+through zod validation into the handler, failing only at the expected credentials boundary.
+
+### Fixed — server advertised a stale hardcoded version to MCP clients
+
+`src/index.ts` hardcoded the version in four places (`McpServer` init, both startup banners, the
+`/health` payload) and was never bumped for v2.11.0 or v2.11.1, so the server reported **2.10.0** in
+its `initialize` response while `package.json` said 2.11.1. Now read from `package.json` at runtime via
+`createRequire(import.meta.url)`, so it cannot drift again. A direct JSON import is not viable here:
+`package.json` sits outside `tsconfig`'s `rootDir` (`./src`), so importing it would restructure `dist/`.
+
+### Docs
+
+Corrected the tool count in `QUICKSTART.md` (212 → 223) and in the GitHub repository description
+(212 → 223). Both had drifted for the same reason: neither ships in the npm tarball, so publishing
+never surfaces them the way it does `README.md`/`TOOLS.md`/`package.json`.
+
+## [2.11.1] - 2026-08-03
+
+### Fixed — `sf_retrieve_metadata` reported success on zero-result retrieves, plus two dead parameters found while investigating
+
+Ajay's follow-up report confirmed v2.11.0's `sf_create_agent_action`/`sf_describe_object` fixes were
+correct — his contradicting evidence turned out to be tested against a stale Claude Desktop MCP
+subprocess predating the rebuild (a recurring gotcha this project has hit before: a rebuilt `dist/`
+only takes effect after a full restart). His genuinely new finding, independent of that mix-up, was
+real: `sf_retrieve_metadata` returned `success: true` and `"Retrieved 1 file(s)."` for a retrieve that
+found **zero** of the requested components — because Salesforce's retrieve zip always includes
+`package.xml` as its own manifest even when every requested member comes back empty, and the file count
+included it. Verified with his exact repro (4 nonexistent `GenAiFunction` names) against a control
+retrieve of a real component.
+
+Fixed in `retrieveMetadataAndWait`: the reported count now excludes `package.xml`, and when components
+were requested by name but none came back, the result is `success: false` with an explicit message
+listing what was requested — instead of a misleadingly cheerful count of a manifest nobody asked for.
+
+**Investigating this surfaced two more, more severe versions of the same underlying problem**, both
+previously untested: the tool's schema has advertised `metadataType`+`componentName` (single-component
+shortcut) and `packageXml` (raw manifest) as alternatives to `components` since this tool existed, but
+the handler only ever read `params.components` — the other two were silently no-ops. A call using
+either form retrieved **nothing at all** (an empty `<unpackaged>` body) while still reporting a
+"successful" retrieve of the manifest-only zip, even when the requested component genuinely existed.
+Wired up both: `metadataType`/`componentName` now builds a single-item `components` array, and
+`packageXml` now extracts the `<types>`/`<version>` content from the supplied document and uses it
+directly as the retrieve request body (needs the `met:` namespace prefix added to every element, since
+the SOAP body has no default namespace, unlike a standalone package.xml). Verified live for all three
+paths: the shortcut form now retrieves a real flow's XML, the zero-match array form now fails honestly,
+and a hand-written raw `packageXml` retrieve returns real content.
+
+No regressions: `test-suite.mjs` 209/212 (2 pre-existing unrelated failures, same as before).
+
+## [2.11.0] - 2026-08-03
+
+### Fixed — `sf_create_agent_action` was fundamentally broken for Flow/ApexClass-backed actions; the misdiagnosis pointed users at their org's licensing instead of the real bug
+
+Ajay reported that `sf_create_agent_action` failed for `type=Flow` even against a confirmed-Active
+flow, and that the failure message wrongly concluded custom agent actions were unsupported in the org
+("check your Agentforce/Einstein licensing") — disprovable because he had just created five
+Flow-backed actions successfully through Salesforce's own Agentforce Builder UI, in the same org, same
+user, same flows.
+
+**Root cause, found by following Ajay's own recommended debugging path (diff a UI-created action's
+real XML against what the tool generates) and going further once retrieval came back empty:**
+`sf_create_agent_action` built a classic Metadata API `.genAiFunction` deploy with
+`<invocationTarget>` set to the flow/class **API name** — but UI-created actions, read back via the
+Tooling API's `GenAiFunctionDefinition` object (the classic Metadata API's `GenAiFunction` type turned
+out not to expose these records at all — confirmed by a wildcard retrieve finding zero results even
+for the five UI-created ones), showed `InvocationTarget` holding an 18-character **record ID**
+(`FlowDefinition.Id` / `ApexClass.Id`), not a name. The generic "Specify a valid invocationTarget and
+invocationTargetType" error — previously treated as a reliable org-capability signal after testing in
+an unrelated org — turned out to be Salesforce's error for *this exact payload bug* in an org that
+supports the feature just fine.
+
+Fixed by switching `sf_create_agent_action` from the classic Metadata API deploy to a Tooling API
+`GenAiFunctionDefinition` upsert — the same mechanism Agentforce Builder itself uses — resolving
+`reference` to the right record ID first (`FlowDefinition.DeveloperName` → `Id` for Flow,
+`ApexClass.Name` → `Id` for ApexClass). Verified live end-to-end, not just unit-tested: created a real
+action against Ajay's own reported flow through the actual registered tool handler (reproducing his
+repro exactly), confirmed the fix also works for ApexClass, and confirmed a Tooling-API-created action
+is correctly picked up by a topic (`GenAiPlugin`) deployed the normal Metadata-API way — the two APIs
+share the same underlying records, so mixing them across the 5-step agent sequence is safe.
+`PromptTemplate`/`DataCategoryGroup`/`ExternalService` are now honestly refused (clear "not yet
+verified" message) rather than silently deploying an unverified, likely-broken payload — matching this
+project's standing rule not to ship unverified metadata behavior.
+
+**`sf_create_agent`'s pre-flight capability probe (added in v2.10.0)** used the same broken deploy
+path internally, so it always failed and hard-blocked agent creation even in orgs — like this one —
+where it works fine. Rewritten to match: it now attempts a real Tooling API insert with a
+syntactically-valid-but-nonexistent target ID. This fails fast on a specific field-validation error in
+any org where the object exists (verified live: `INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST`), and since
+nothing is ever actually written, there's no cleanup step either — simpler than the old probe, which
+had to deploy-then-delete a throwaway. Verified live: `sf_create_agent` now succeeds normally in this
+org, both with and without `skipActionCapabilityCheck`.
+
+Also fixed: `sf_describe_object` returned a bare `NOT_FOUND` 404 for standard objects whose *feature*
+is disabled (Ajay's repro: `Quote`, when the Quotes feature is off in Setup) — indistinguishable from a
+typo'd or nonexistent object name. Added a hint for a hardcoded list of commonly feature-gated standard
+objects (Quote, Contract, Order, Campaign, Territory2, WorkOrder, ServiceAppointment, etc.) pointing at
+Setup instead of sending the user hunting for a naming mistake that isn't there.
+
+**`qa-agentforce.mjs` needed a substantial rewrite, not just the tool code.** The suite's own
+assertions were written under the same now-disproven assumption ("demo-org cannot create GenAiFunction
+actions") baked into skip logic throughout — so the action/topic verification paths had never actually
+executed in any prior session, and once they finally ran (because the underlying bug they were gated
+behind is now fixed), they surfaced a second, independent, pre-existing gap: `existsInOrg`'s plain REST
+`queryRecords` can't see `GenAiFunction`/`GenAiFunctionDefinition` (Tooling-API-only, confirmed) or
+`GenAiPlugin` (no SOQL interface at all, confirmed both plain REST and Tooling — only readable via
+classic Metadata API `readMetadata`) — it happened to work before only because those checks were never
+reached. Rewrote `existsInOrg` to dispatch to the right API per type, and rewrote the action-type
+matrix check to read `GenAiFunctionDefinition.InvocationTargetType` back via Tooling API instead of a
+`retrieveMetadata` call that (per the finding above) was always going to come back empty. Suite went
+from 33 passed/15 failed (pre-fix) to 35 passed/2 failed against a live org.
+
+**Known open item, not a code defect:** after extensive live testing today (mine plus Ajay's own
+UI-based testing), further `GenAiFunctionDefinition` inserts in `demo-org` started failing with
+`DUPLICATE_DEVELOPER_NAME` ("...already exists or has been previously used") even against
+brand-new, never-used developer names and master labels — isolated by testing fresh-name/reused-label
+and fresh-everything/reused-target combinations independently; neither explains it, and the condition
+persisted for several minutes and across unrelated work. Most likely an org-side rate limit or cooldown
+on this object triggered by the volume of creates/deletes during today's testing, not a regression in
+this fix — the two remaining `qa-agentforce.mjs` failures are this condition surfacing honestly through
+the tool's real error message, not a masked defect. Re-run the suite after some time has passed to
+confirm it clears; if it doesn't, this needs further investigation as a genuine platform limit.
+
+## [2.10.0] - 2026-08-01
+
+### Fixed/Added — 4 more findings from an extended manual test session (Bugs 6-8, and a sharper Bug 3), plus 2 new tools
+
+Ajay's follow-up report superseded the previous one. Bugs 1, 2, 4, 5 from that report were already
+fixed in v2.9.0 (confirmed still present in this session, not re-fixed) — the report describing them
+as unfixed was written from a Claude Desktop session whose MCP server subprocess had been running
+since before v2.9.0 landed; restarting Claude Desktop picks up a rebuilt `dist/`, an already-spawned
+subprocess does not. New findings below.
+
+**Bug 3, revisited with much stronger evidence.** The previous release's conclusion (org-side schema
+propagation lag) held, but Ajay's new evidence sharpened *what kind* of lag it is: persisted 2+ hours
+in his session (ruling out ordinary propagation delay), and — critically — REST describe worked fine
+on **pre-existing** custom fields on standard objects (Opportunity's own custom fields) while failing
+on everything newly created, which looked like it might be specific to brand-new custom *objects*
+rather than fields in general. Tested that distinction directly and decisively: created a field on the
+standard `Account` object and a field on a brand-new custom object side by side, then polled both for
+2 full minutes. **Both were equally stuck** — this rules out "new object vs. existing object" as the
+differentiator. The real explanation: Ajay's "working" standard-object fields were older, already-
+propagated fields from earlier sessions, not freshly created ones — not evidence that new fields on
+standard objects propagate faster. Also directly tested Ajay's identity-mismatch hypothesis (REST and
+Metadata clients authenticating as different users): confirmed live that both use the exact same
+`auth.accessToken`, resolving to the same user (`semwalajaydevorg@agentforce.com`) and same org ID —
+ruled out. Revised, more precise conclusion: this org has a severe (multi-hour-observed), general
+schema-cache propagation lag affecting all newly created fields, regardless of parent object type —
+still not something any client-side code change can fix.
+
+**Bug 6: `sf_create_agent` now probes GenAiFunction (custom action) support before creating a Bot
+shell.** Reproduced Ajay's exact finding: active Agentforce permission set licenses are not sufficient
+evidence that custom actions work — confirmed by deploying a `GenAiFunction` aimed at a deliberately
+nonexistent target and getting the identical generic error a real target would get, meaning the org
+never even attempts target resolution. Added a pre-flight probe (a real, throwaway `GenAiFunction`
+deploy, cleaned up automatically) that runs before the Bot shell is created on the first call in the
+5-step sequence: if actions aren't supported, the call fails immediately with no shell created, instead
+of leaving an orphaned Bot with no planner/topic/action once step 2 turns out to be unreachable. Added
+`skipActionCapabilityCheck` for topics-only agents that don't need custom actions. Verified live both
+ways: the probe correctly blocks with no shell created, and the skip flag correctly bypasses it.
+
+**Bug 7: `sf_create_agent_topic` now validates that every referenced action exists before deploying.**
+Previously, a topic referencing a missing action deployed and failed with an opaque Salesforce support
+ErrorId naming nothing. `GenAiFunction` isn't SOQL/Tooling-queryable in every org (confirmed: it isn't
+in `demo-org`), so existence is checked via Metadata API `readMetadata` instead, which works regardless
+of SOQL support for the type. Verified live: a topic referencing a nonexistent action is now rejected
+before ever reaching Salesforce, naming the specific missing action.
+
+**Bug 8: added `sf_delete_metadata`.** There was previously no way to remove anything deployed by this
+MCP server — `sf_deploy_metadata` has no `destructiveChanges` support, and diagnostic/orphaned metadata
+had nowhere to go (confirmed: Ajay's stranded `AccountOpportunityAgent` Bot shell was still in the org,
+alongside 13 similar leftovers from earlier sessions). Wraps the `deleteMetadata` SOAP call, which
+already existed as an internal service function but was never exposed as a tool. Verified live with a
+real round-trip (create → delete → confirm gone) and by actually attempting cleanup of the accumulated
+org backlog: correctly surfaced Salesforce's own 10-record-per-call limit (batched around it), and
+correctly surfaced a real dependency-order error when a `GenAiPlannerBundle` was still referenced by a
+Bot. The specific stuck Bot records from earlier sessions remain undeletable — a pre-existing, already-
+documented Salesforce-side "unexpected error" on those particular records, not something this tool or
+any client-side retry can work around.
+
+**Documented, not a bug**: Flow `textTemplates` strip leading/trailing whitespace on deploy while
+preserving internal newlines — concatenating per-iteration templates in a loop without an internal
+separator runs lines together. Added to the `sf_create_flow` schema description.
+
+**Confirmed already fixed, not re-touched**: Bugs 1 (duplicate Decision rule names), 2 (filter value
+typing), 4 (FLS warning), 5 (raw-XML pre-validation) — all still present and correct in this codebase,
+verified by direct inspection before assuming anything needed re-fixing.
+
+Tool count 222→223 (`sf_delete_metadata`). Regression: `qa-agentforce.mjs` gained 5 new checks for
+Bugs 6/7 (all existing `sf_create_agent` calls updated with `skipActionCapabilityCheck` so the new
+probe doesn't change what those pre-existing tests were actually testing); `test-suite.mjs` gained a
+real create→delete→confirm-gone round-trip test for `sf_delete_metadata`.
+
+## [2.9.0] - 2026-08-01
+
+### Fixed — 5 real bugs from a genuine manual test session in Claude Desktop, all reproduced and re-verified live
+
+Ajay tested v2.8.9 by hand in Claude Desktop against a real Developer Edition org — created a custom
+object, six custom fields, and two Flows built against them — and reported five specific issues found
+along the way. Every one below was reproduced first (not assumed from the report), root-caused in the
+source, fixed, and re-verified against `demo-org` before being called done.
+
+**`sf_create_flow` emits duplicate rule developer names for 2+ Decision elements (blocking).**
+Reproduced exactly: `Deployment failed: Duplicate developer name: Rule_1`. Root cause: each Decision's
+rule `<name>` was `Rule_1`, `Rule_2`, ... scoped per-decision, but Salesforce requires uniqueness across
+the whole Flow. Fixed in both XML generators by namespacing with the parent Decision's own name
+(`Decision_One_Rule_1`), verified unique in the deployed XML afterward. Fixing this surfaced a second,
+related bug in the same code path: `<defaultConnectorLabel>` was only emitted when `defaultConnector`
+was set, but Salesforce requires it unconditionally (it labels the implicit "no rule matched" branch,
+which exists whether or not it connects anywhere) — every existing Decision test in this repo's own
+suite happened to set `defaultConnector` explicitly, which is exactly why this had never been caught.
+Fixed in both generators; added a permanent regression test with two Decisions, the second deliberately
+relying on implicit fall-through. Flow suite: 142→144 checks, 144/144 passing.
+
+**`sf_create_flow`'s filter/assignment values only accepted strings, and GetRecords filters silently
+mistyped numbers.** The schema rejected a native boolean (`value: true`) with a bare zod error; the
+reported workaround (`value: "true"`) did work correctly (booleans were already string-sniffed
+correctly), but investigating this surfaced a real, more serious, previously-unreported bug in the same
+code: GetRecords filter values had NO numeric detection at all — unlike Decision/CreateRecords/
+UpdateRecords, which all correctly detect numeric-looking values, GetRecords filters emitted
+`<stringValue>100</stringValue>` for every non-boolean value including numbers, which risks incorrect
+or no matches when filtering Number/Currency/Percent fields with comparison operators. Fixed the missing
+numeric detection in both generators, and widened `rightValue`/`filterValue`/`filters[].value`/
+`inputAssignments[].value`/`assignments[].value` to accept string, number, or boolean directly (coerced
+to string before the existing, now-correct typed-XML logic) so the natural call shape works without a
+string-coercion workaround. Verified live: a native boolean and a native number filter both produce the
+correct typed XML element in the deployed flow.
+
+**REST describe / SOQL not seeing custom fields that the Metadata API and Tooling API confirm exist.**
+Reproduced exactly — `describe field count: 10` (only standard fields), matching the report precisely,
+persisting well past 60 seconds and after granting FLS (also reproduced: 0 grants by default). Ruled
+out an in-process cache (there isn't one — `sf_describe_object` makes a fresh HTTP call every time,
+confirmed by reading the code) and ruled out XML element ordering in the picklist-value generator via a
+controlled live A/B test (an initial hypothesis that looked promising but didn't hold up once tested
+head-to-head). What's actually happening: Salesforce's own REST describe/SOQL schema cache lagged
+behind the Metadata API and (intermittently, itself) the Tooling API by 10+ minutes on this org during
+testing — a genuine platform-side propagation characteristic, not something any client-side code
+change can fix. Implemented the mitigation Ajay suggested regardless: `sf_describe_object` gained
+`waitForFields`/`timeoutSeconds` to poll until named fields appear (or say clearly that they still
+haven't, with a pointer to the Tooling API to confirm the field truly exists), so callers don't have to
+hand-roll retry loops. Documented plainly in both the tool description and the CHANGELOG that this is
+an org-side lag, not a bug in this server — don't re-diagnose it as one without new evidence.
+
+**`sf_create_custom_field` leaves every new field with zero FLS grants and no indication a follow-up
+call is needed.** Reproduced: `sf_get_field_permissions` returns 0 grants immediately after a
+`success: true` field creation, for every profile including System Administrator. Fixed by checking FLS
+right after creation and appending an explicit warning to the response when none exist, naming the
+exact fix (`sf_create_field_level_security`) — chose this over auto-granting FLS by default since that
+would silently change existing behavior; surfacing the truth is a strictly additive fix.
+
+**`sf_create_flow_from_xml` surfaced raw, unhelpful Salesforce schema errors for 3 common mistakes.**
+Added `validateAndNormalizeFlowXml()`: a bounded, depth-tracking tokenizer (not a full XML parser —
+sufficient for direct children of the root `<Flow>` element) that catches, before ever deploying: (1)
+non-contiguous top-level elements of the same type (interleaved `<assignments>`/`<decisions>` etc.,
+which Salesforce reports as a baffling "Element X is duplicated at this location in type Flow" instead
+of naming the real issue — grouping), (2) missing `<start>` `locationX`/`locationY`, auto-defaulted
+rather than just flagged since there's no ambiguity about a safe default, (3) an SObject-typed
+`<variables>` entry missing `<objectType>`, naming the specific variable (Salesforce's own error for
+this one was already good — replicated its style for consistency, and to catch it pre-deploy instead of
+after). Verified live: interleaved elements and a missing objectType are both now rejected pre-deploy
+with a specific, actionable message and never reach Salesforce at all; missing start coordinates are
+silently defaulted and the flow deploys successfully.
+
+**Full regression, both before committing and after every individual fix**: `qa-flow-comprehensive.mjs`
+142→144/144 (2 new checks from the Bug 1 regression test, all passing). `test-suite.mjs` and the
+Agentforce suites held their existing pass rates — none of these five fixes touch Agentforce code paths.
+
+## [2.8.9] - 2026-07-31
+
+### Fixed — the v2.8.8 command-injection guard was over-broad; narrowed after a second round of live testing
+
+Asked for a second round of testing before publishing v2.8.8, rather than treating the first pass as
+done. Good call: it surfaced a real false-positive regression in the fix itself. The original guard
+rejected any `sf` CLI argument containing `` " ` $ & | ; < > ^ `` — but a systematic, one-character-
+at-a-time live test (each character alone, then each paired with a quote) showed every one of those
+metacharacters is completely inert on its own through cross-spawn; **only a literal `"` combined with
+a following metacharacter reaches a live shell.** A quote alone never did either. That means the
+original guard would have rejected entirely legitimate values this codebase's own tools pass
+routinely — a package description like `"Sales & Service Tools"`, a company name like
+`"O'Brien Industries"` — with zero actual security benefit, since none of those ever reach a shell
+regardless. Narrowed to reject only `"` (plus raw newlines, never legitimate in a single CLI arg
+either). Re-verified live, both directions: the original exploit payload (`"x & echo ... & echo x"`)
+is still rejected; a package description containing `&` and `'` now reaches the real `sf` CLI instead
+of being rejected by the guard.
+
+### Reviewed in depth on request — Flow builder and Agentforce agent/topic/action/planner creation
+
+Ajay asked specifically for closer attention here. Read both Flow XML generators
+(`buildFlowXml`/SOAP and `buildFlowDeployXml`/ZIP, ~800 lines combined) end to end and all four
+Agentforce tools (`sf_create_agent`, `sf_create_agent_topic`, `sf_create_agent_action`,
+`sf_create_agent_planner`) line by line, not just grep-sampled. Result: both Flow builders escape
+every free-text value correctly and consistently (verified their `buildFilterValue`/
+`typedResourceValue` helpers apply `x()` at every actual string-literal insertion point); the
+remaining raw interpolations are all zod-enum-constrained `dataType` fields or booleans, not user
+text, so no injection surface. Agentforce's XML construction is equally clean throughout.
+
+**Did find one real, separate bug while reading this closely, unrelated to injection**:
+`sf_create_agent_action`'s `inputs` parameter (input parameter mappings — `[{name, value}]`) is
+accepted by the schema and documented, but was never wired into the generated `GenAiFunction` XML at
+all — confirmed by grep, not a one-off oversight in this pass. Any caller who passed `inputs` had them
+silently discarded, with no error and no indication in the response. This went uncaught because
+`demo-org` cannot create `GenAiFunction` actions at all (a pre-existing, documented org-licensing
+limit), so this parameter has never been exercised against a live org — and this project's own rule is
+not to ship metadata XML shapes that haven't been verified that way. Rather than guess at the correct
+XML (a real risk of shipping a second, differently-wrong bug), the tool's success message now says
+explicitly when `inputs` was provided but not applied, so callers aren't silently misled. Implementing
+it for real is still blocked on the same thing blocking the rest of GenAiFunction action testing: an
+org where custom agent actions are actually licensed.
+
+**Full regression**, both directions of this round: `test-suite.mjs` 207/211 passed — the one new
+"failure" beyond the existing 2 pre-existing ones (`sf_share_report_folder`) is test-state
+accumulation (it selects an existing report folder from the org, and today's own repeated
+`test-suite.mjs` runs have created enough of them that one now has a too-long derived name), not a
+code regression — unrelated to any change in this release. `qa-agentforce.mjs`,
+`qa-agentforce-adjacent.mjs`, and `qa-flow-comprehensive.mjs` (142/142) all held their existing rates.
+
+## [2.8.8] - 2026-07-31
+
+### Security audit — one confirmed, exploitable command-injection vulnerability fixed, plus 13 more real findings across SOQL, generated-code, and credential-handling surfaces
+
+Ajay asked for a standing security review of this project, not tied to any specific bug report. Went
+through the codebase systematically rather than waiting for a report, and proved every finding below
+by actually attempting the attack through the real, compiled MCP tool handler — not just reading code
+and guessing. Everything here was found live against `demo-org`, the same standard this project holds
+itself to for functional bugs.
+
+**Command injection — CRITICAL, confirmed live-exploitable, now fixed.** Every `sf` CLI invocation in
+this codebase built a shell command by joining an args array with spaces and running it through
+`execSync`. Six tools passed unvalidated string parameters straight into that array:
+`sf_create_scratch_org`, `sf_delete_scratch_org`, `sf_create_package`, `sf_create_package_version`,
+`sf_install_package`, `sf_uninstall_package`, `sf_run_code_scanner`, `sf_scan_apex_antipatterns`.
+Proof of concept: a `devHubAlias` of `DevHub & echo INJECTED > marker.txt & echo x` actually created
+the marker file when run through `sf_create_scratch_org`'s real handler. Fixed by replacing every
+`execSync`/`exec` call with `cross-spawn`, which passes each argument as a genuine argv entry instead
+of shell text — re-verified the same payload no longer executes. **cross-spawn alone was not enough**:
+an argument combining a literal `"` with a shell metacharacter (e.g. `"x & ... & echo x"`) still
+reached a live shell even through cross-spawn 7.0.6's own escaping, because `sf` is a `.cmd` batch
+shim on Windows and its internal `%*` argument-forwarding to node.exe is a second, uncontrolled
+re-parsing step outside cross-spawn's reach — also proven live before being closed with an explicit
+character allowlist (`runSfCli` now rejects any argument containing `"`, `` ` ``, `$`, `&`, `|`, `;`,
+`<`, `>`, `^`, or a newline before it ever reaches cross-spawn; none of this codebase's CLI arguments —
+aliases, IDs, paths, keys, rule selectors — ever legitimately need one). Also deleted `createScratchOrg`,
+a second, entirely dead implementation of scratch-org creation with the same injection flaw plus
+broken shell quoting that would have failed on both POSIX and Windows — confirmed zero references
+anywhere before removing it.
+
+**SOQL injection — real, live, found across 9 call sites.** `sf_get_field_history` (`recordId` and
+`objectApiName`, the latter landing unquoted in a FROM-clause identifier position — no amount of
+quote-escaping fixes that, only an identifier allowlist does), `sf_get_setup_audit_trail` /
+`sf_get_login_history` / `sf_get_event_logs` (`startDate`/`endDate`, interpolated unquoted with zero
+format validation), `sf_get_apex_test_results` (`testRunId`), `sf_detect_devops_merge_conflict` /
+`sf_check_devops_commit_status` / `sf_list_devops_work_items` (`workItemId`/`projectId`/`stageId`),
+and `sf_create_field_dependency` (`objectName`/`dependentField` in a Tooling API query). Fixed with a
+new `soqlEscape()` helper (formalizing the backslash-quote pattern already used correctly at ~15 other
+call sites in this file) and a new `assertSoqlDateLiteral()` validator for the unquoted date-literal
+positions. `sf_query_records`'s raw `soql`/`whereClause`/`orderBy` and `sf_create_apex_batch`'s
+`queryFilter` were deliberately left alone — both are documented, intentional raw-SOQL-fragment
+parameters, the entire point of those tools, not an oversight.
+
+**Code injection into generated, later-executed source — found in both Apex and TypeScript
+generation.** `sf_create_invocable_action`'s `label`/`description` and its input/output variable
+labels landed unescaped inside `@InvocableMethod`/`@InvocableVariable` annotation string literals in
+generated Apex — an unescaped `'` breaks out of the literal and injects arbitrary class members into
+a class that gets deployed and can execute. Same pattern in the (dead, unwired — see below)
+`createApexScheduler`'s doc comment (a literal `*/` closes the comment early, turning the rest of the
+generated file back into live code) and `createRestResource`'s `urlMapping`. Fixed with the same
+`soqlEscape()` helper (Apex and SOQL use identical backslash-quote string-literal escaping) plus a
+comment-safe `*/`-stripping helper for the comment-only cases. **More seriously, this same class of
+bug was live and reachable** in `sf_create_mcp_server` and `sf_create_mcp_tool` (the tools that
+scaffold a brand-new MCP server project on disk): `serverName` and `toolName` were spliced unescaped
+into generated `.ts` source as string literals, and `sf_create_mcp_tool`'s `inputSchema` keys —
+`z.record(z.unknown())`, so literally any string — were spliced in as raw, unquoted object-property
+names with zero validation. Proof of concept: an `inputSchema` key of
+`x(){require("fs").writeFileSync("pwn2","x");return z.string()` was accepted by the old code and would
+have become live, executable code in the generated project the moment it was built and run. Fixed:
+`serverName`/`toolName` now go through `JSON.stringify()` (matching how `toolDescription` was already
+correctly handled in the same function — this was an inconsistency, not a from-scratch gap), and
+`inputSchema` keys are now validated against a strict identifier regex before generation, with a clear
+rejection instead of silent code smuggling.
+
+**Credential leak in the codebase's own default error-sanitization path — real, high-impact, silently
+broken since introduction.** `sanitizeError()` is called in essentially every one of this codebase's
+~100 catch blocks — it's what stands between an internal error and what gets returned to the calling
+LLM/user. Its only token-redaction rule was `[A-Fa-f0-9]{40,}` (pure hex, 40+ chars). Real Salesforce
+access tokens/session IDs look like `00Dxxxxxxxxxxxx!AQEAQ...` — base64url-ish with a literal `!`
+separator, never pure hex — so a real token embedded in any error message (a network client echoing a
+request URL, an API error quoting back session context) would have passed straight through
+completely unredacted. Proved this live with a realistic fake token before and after the fix. There
+was a second function, `redactSensitive()`, that had the right idea (a `Bearer` pattern, a `00D...`
+pattern) but its own character classes stopped at the first `!` or `.`, so it only partially redacted
+even the cases it targeted, and — separately — it was only ever called from 2 of the ~100 relevant
+sites, so almost nothing benefited from it regardless. Fixed by broadening the character classes to
+cover the actual token shape and having `sanitizeError()` call `redactSensitive()` internally, so
+every existing caller gets the protection retroactively with no call-site changes needed.
+
+**HTTP transport mode has no authentication and bound to all network interfaces by default.** This
+project supports `TRANSPORT=http` as an alternative to the default stdio transport. Its `/mcp` endpoint
+has no auth of its own — any request that reaches it executes MCP tools using whatever Salesforce
+credentials the server process is configured with — and `http.Server.listen(port)` with no explicit
+host binds to every interface, not just localhost, by Node's own default. Fixed: defaults to
+`127.0.0.1` now; set `HOST` explicitly (e.g. behind a reverse proxy that adds real auth) to opt into
+broader exposure instead of getting it by accident. This mode is opt-in and off by default (stdio is
+the default transport), so this was a foot-gun for anyone who did enable it, not an always-on gap.
+
+**Audited and confirmed clean, no action needed:** XML metadata builders (spot-checked ~60 candidate
+interpolation sites; every one was already either correctly wrapped in the existing `x()` escaper or a
+boolean/number field with no injection surface at all — the real gaps here were already closed in
+v2.8.2). `npm audit`: still exactly the 2 moderate findings already documented and deliberately left
+(a path-traversal bug in `@hono/node-server`'s `serve-static`, a transitive dependency of the MCP SDK
+that this project's own HTTP transport — a from-scratch, two-route implementation — never calls into
+regardless of transport mode; confirmed again this session, not just carried forward from memory).
+Secrets/credential files: confirmed `.gitignore` still covers `.env`, `.env.local`, `*.key`, and
+`CLAUDE.local.md`, and confirmed via `git log --all` that nothing secret-shaped has ever been committed.
+
+**Also found, not fixed (dead code, zero live exposure, hardened anyway for defense-in-depth):**
+`createInvocableAction`, `createApexScheduler`, and `createRestResource` are all exported from
+`services/salesforce.ts` but never imported by any tool file — confirmed via full-codebase grep before
+and after — so their injection fixes above protect nothing reachable today. Left in place rather than
+deleted (unlike `createScratchOrg`, which was both dead *and* had no legitimate salvage value) since
+these look like intended-but-never-wired functionality; flagging here so a future session that wires
+them up inherits the fix rather than reintroducing the bug.
+
+**Full regression confirmation:** `test-suite.mjs` (211 tests) — 208 passed, 2 failed (both pre-existing,
+unrelated, intentional negative-test probes), 1 skipped — no change from the pre-audit baseline.
+`qa-agentforce.mjs`, `qa-agentforce-adjacent.mjs`, and `qa-flow-comprehensive.mjs` all held their
+existing pass rates. Every fix above was also independently proven by re-attempting its specific
+exploit through the real, compiled tool handler and confirming it now fails cleanly instead of
+executing.
+
 ## [2.8.7] - 2026-07-31
 
 ### Added — `sf_create_external_client_app`, and it closes a gap `sf_create_connected_app` structurally cannot

package/README.md

@@ -5,7 +5,7 @@
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
 [![MCP Compatible](https://img.shields.io/badge/MCP-Compatible-green.svg)](https://modelcontextprotocol.io)
 
-**The only Salesforce MCP server that builds Agentforce agents, OmniStudio components, and DevOps Center pipelines** — alongside a complete daily developer loop (schema describe, Apex read, debug logs) and 222 tools total for building, configuring, and automating Salesforce orgs directly from Claude or any MCP client.
+**The only Salesforce MCP server that builds Agentforce agents, OmniStudio components, and DevOps Center pipelines** — alongside a complete daily developer loop (schema describe, Apex read, debug logs) and 223 tools total for building, configuring, and automating Salesforce orgs directly from Claude or any MCP client.
 
 ---
 
@@ -47,7 +47,7 @@ See [SETUP.md](SETUP.md) for all authentication methods and detailed setup instr
 
 ---
 
-## Tools — 222 total
+## Tools — 223 total
 
 Highlights below; see [TOOLS.md](TOOLS.md) for the complete reference with parameters and example prompts.
 
@@ -163,6 +163,7 @@ Highlights below; see [TOOLS.md](TOOLS.md) for the complete reference with param
 | `sf_deploy_metadata` | Deploy metadata via Metadata API (supports `testLevel`, inline XML) |
 | `sf_check_deploy_status` | Check deployment job status |
 | `sf_retrieve_metadata` | Retrieve metadata from the org |
+| `sf_delete_metadata` | Permanently delete metadata components (CustomObject, CustomField, Flow, GenAiFunction, Bot, etc.) |
 
 ### MCP Server Management
 | Tool | Description |
@@ -210,7 +211,7 @@ Highlights below; see [TOOLS.md](TOOLS.md) for the complete reference with param
 ## Documentation
 
 - [SETUP.md](SETUP.md) — Prerequisites, authentication, Claude configuration
-- [TOOLS.md](TOOLS.md) — All 222 tools with full parameter documentation
+- [TOOLS.md](TOOLS.md) — All 223 tools with full parameter documentation
 - [AGENTFORCE.md](AGENTFORCE.md) — Agentforce agent creation guide
 - [APEX_LWC.md](APEX_LWC.md) — Apex and LWC development guide
 - [CHANGELOG.md](CHANGELOG.md) — Version history

package/TOOLS.md

@@ -1,6 +1,6 @@
 # Tools Reference
 
-Complete documentation for all 222 tools in `salesforce-metadata-mcp`. (Highlights below cover the most commonly used tools in depth; see the README's full 222-tool table for every tool name.)
+Complete documentation for all 223 tools in `salesforce-metadata-mcp`. (Highlights below cover the most commonly used tools in depth; see the README's full 223-tool table for every tool name.)
 
 ---
 
@@ -323,4 +323,4 @@ Reads the current field-level security grants for a field across all Profiles an
 
 ---
 
-*For the complete list of all 222 tools, see [README.md](README.md).*
+*For the complete list of all 223 tools, see [README.md](README.md).*

package/dist/index.js

@@ -3,17 +3,24 @@ import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
 import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
 import { createServer } from "http";
+import { createRequire } from "module";
 import { registerTools } from "./tools/index.js";
+// Single source of truth for the version. Hardcoding it here drifted from package.json across
+// v2.11.0/v2.11.1 (the server advertised 2.10.0 to clients while the package said 2.11.1), so read
+// it at runtime instead. dist/index.js → ../package.json resolves correctly both in the repo and
+// when installed as node_modules/salesforce-metadata-mcp/dist/index.js.
+const require = createRequire(import.meta.url);
+const { version: VERSION } = require("../package.json");
 const server = new McpServer({
     name: "salesforce-metadata-mcp",
-    version: "2.5.8",
+    version: VERSION,
 });
 registerTools(server);
 // ─── Transport: stdio ─────────────────────────────────────────────────────────
 async function runStdio() {
     const transport = new StdioServerTransport();
     await server.connect(transport);
-    console.error("Salesforce Metadata MCP server v2.5.8 running on stdio");
+    console.error(`Salesforce Metadata MCP server v${VERSION} running on stdio`);
 }
 // ─── Transport: HTTP ──────────────────────────────────────────────────────────
 function readBody(req) {
@@ -34,11 +41,18 @@ function readBody(req) {
 }
 async function runHTTP() {
     const port = parseInt(process.env["PORT"] ?? "3000", 10);
+    // Defaults to localhost-only: this endpoint has no authentication of its own (any request that
+    // reaches /mcp executes tools using whatever Salesforce credentials this process is configured
+    // with), and Node's http.Server.listen(port) with no host binds to ALL interfaces by default —
+    // found during the 2026-07-31 security audit. Set HOST explicitly (e.g. "0.0.0.0") to opt into
+    // wider exposure — e.g. behind a reverse proxy that adds its own auth — rather than exposing this
+    // unauthenticated by accident.
+    const host = process.env["HOST"] ?? "127.0.0.1";
     const httpServer = createServer(async (req, res) => {
         const url = req.url ?? "/";
         if (url === "/health" && req.method === "GET") {
             res.writeHead(200, { "Content-Type": "application/json" });
-            res.end(JSON.stringify({ status: "ok", server: "salesforce-metadata-mcp", version: "2.5.8" }));
+            res.end(JSON.stringify({ status: "ok", server: "salesforce-metadata-mcp", version: VERSION }));
             return;
         }
         if (url === "/mcp" && req.method === "POST") {
@@ -63,8 +77,8 @@ async function runHTTP() {
         res.writeHead(404, { "Content-Type": "application/json" });
         res.end(JSON.stringify({ error: "Not found" }));
     });
-    httpServer.listen(port, () => {
-        console.error(`Salesforce Metadata MCP server v2.5.8 running on http://localhost:${port}/mcp`);
+    httpServer.listen(port, host, () => {
+        console.error(`Salesforce Metadata MCP server v${VERSION} running on http://${host}:${port}/mcp`);
     });
 }
 // ─── Entry point ──────────────────────────────────────────────────────────────

package/dist/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AACA,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AACjF,OAAO,EAAE,6BAA6B,EAAE,MAAM,oDAAoD,CAAC;AACnG,OAAO,EAAE,YAAY,EAA6C,MAAM,MAAM,CAAC;AAC/E,OAAO,EAAE,aAAa,EAAE,MAAM,kBAAkB,CAAC;AAEjD,MAAM,MAAM,GAAG,IAAI,SAAS,CAAC;IAC3B,IAAI,EAAE,yBAAyB;IAC/B,OAAO,EAAE,OAAO;CACjB,CAAC,CAAC;AAEH,aAAa,CAAC,MAAM,CAAC,CAAC;AAEtB,iFAAiF;AAEjF,KAAK,UAAU,QAAQ;IACrB,MAAM,SAAS,GAAG,IAAI,oBAAoB,EAAE,CAAC;IAC7C,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;IAChC,OAAO,CAAC,KAAK,CAAC,wDAAwD,CAAC,CAAC;AAC1E,CAAC;AAED,iFAAiF;AAEjF,SAAS,QAAQ,CAAC,GAAoB;IACpC,OAAO,IAAI,OAAO,CAAC,CAAC,OAAO,EAAE,MAAM,EAAE,EAAE;QACrC,MAAM,MAAM,GAAa,EAAE,CAAC;QAC5B,GAAG,CAAC,EAAE,CAAC,MAAM,EAAE,CAAC,KAAa,EAAE,EAAE,CAAC,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC;QACtD,GAAG,CAAC,EAAE,CAAC,KAAK,EAAE,GAAG,EAAE;YACjB,IAAI,CAAC;gBACH,MAAM,GAAG,GAAG,MAAM,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC;gBACpD,OAAO,CAAC,GAAG,CAAC,CAAC,CAAE,IAAI,CAAC,KAAK,CAAC,GAAG,CAAa,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;YACnD,CAAC;YAAC,MAAM,CAAC;gBACP,MAAM,CAAC,IAAI,KAAK,CAAC,mBAAmB,CAAC,CAAC,CAAC;YACzC,CAAC;QACH,CAAC,CAAC,CAAC;QACH,GAAG,CAAC,EAAE,CAAC,OAAO,EAAE,MAAM,CAAC,CAAC;IAC1B,CAAC,CAAC,CAAC;AACL,CAAC;AAED,KAAK,UAAU,OAAO;IACpB,MAAM,IAAI,GAAG,QAAQ,CAAC,OAAO,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,MAAM,EAAE,EAAE,CAAC,CAAC;IAEzD,MAAM,UAAU,GAAG,YAAY,CAAC,KAAK,EAAE,GAAoB,EAAE,GAAmB,EAAE,EAAE;QAClF,MAAM,GAAG,GAAG,GAAG,CAAC,GAAG,IAAI,GAAG,CAAC;QAE3B,IAAI,GAAG,KAAK,SAAS,IAAI,GAAG,CAAC,MAAM,KAAK,KAAK,EAAE,CAAC;YAC9C,GAAG,CAAC,SAAS,CAAC,GAAG,EAAE,EAAE,cAAc,EAAE,kBAAkB,EAAE,CAAC,CAAC;YAC3D,GAAG,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,EAAE,yBAAyB,EAAE,OAAO,EAAE,OAAO,EAAE,CAAC,CAAC,CAAC;YAC/F,OAAO;QACT,CAAC;QAED,IAAI,GAAG,KAAK,MAAM,IAAI,GAAG,CAAC,MAAM,KAAK,MAAM,EAAE,CAAC;YAC5C,IAAI,IAAa,CAAC;YAClB,IAAI,CAAC;gBACH,IAAI,GAAG,MAAM,QAAQ,CAAC,GAAG,CAAC,CAAC;YAC7B,CAAC;YAAC,MAAM,CAAC;gBACP,GAAG,CAAC,SAAS,CAAC,GAAG,EAAE,EAAE,cAAc,EAAE,kBAAkB,EAAE,CAAC,CAAC;gBAC3D,GAAG,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,EAAE,KAAK,EAAE,mBAAmB,EAAE,CAAC,CAAC,CAAC;gBACxD,OAAO;YACT,CAAC;YACD,MAAM,SAAS,GAAG,IAAI,6BAA6B,CAAC;gBAClD,kBAAkB,EAAE,SAAS;gBAC7B,kBAAkB,EAAE,IAAI;aACzB,CAAC,CAAC;YACH,GAAG,CAAC,EAAE,CAAC,OAAO,EAAE,GAAG,EAAE,CAAC,SAAS,CAAC,KAAK,EAAE,CAAC,CAAC;YACzC,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;YAChC,MAAM,SAAS,CAAC,aAAa,CAAC,GAAG,EAAE,GAAG,EAAE,IAAI,CAAC,CAAC;YAC9C,OAAO;QACT,CAAC;QAED,GAAG,CAAC,SAAS,CAAC,GAAG,EAAE,EAAE,cAAc,EAAE,kBAAkB,EAAE,CAAC,CAAC;QAC3D,GAAG,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,EAAE,KAAK,EAAE,WAAW,EAAE,CAAC,CAAC,CAAC;IAClD,CAAC,CAAC,CAAC;IAEH,UAAU,CAAC,MAAM,CAAC,IAAI,EAAE,GAAG,EAAE;QAC3B,OAAO,CAAC,KAAK,CAAC,qEAAqE,IAAI,MAAM,CAAC,CAAC;IACjG,CAAC,CAAC,CAAC;AACL,CAAC;AAED,iFAAiF;AAEjF,MAAM,SAAS,GAAG,OAAO,CAAC,GAAG,CAAC,WAAW,CAAC,IAAI,OAAO,CAAC;AACtD,IAAI,SAAS,KAAK,MAAM,EAAE,CAAC;IACzB,OAAO,EAAE,CAAC,KAAK,CAAC,CAAC,GAAY,EAAE,EAAE;QAC/B,OAAO,CAAC,KAAK,CAAC,eAAe,EAAE,GAAG,YAAY,KAAK,CAAC,CAAC,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC;QACjF,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IAClB,CAAC,CAAC,CAAC;AACL,CAAC;KAAM,CAAC;IACN,QAAQ,EAAE,CAAC,KAAK,CAAC,CAAC,GAAY,EAAE,EAAE;QAChC,OAAO,CAAC,KAAK,CAAC,eAAe,EAAE,GAAG,YAAY,KAAK,CAAC,CAAC,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC;QACjF,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IAClB,CAAC,CAAC,CAAC;AACL,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AACA,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AACjF,OAAO,EAAE,6BAA6B,EAAE,MAAM,oDAAoD,CAAC;AACnG,OAAO,EAAE,YAAY,EAA6C,MAAM,MAAM,CAAC;AAC/E,OAAO,EAAE,aAAa,EAAE,MAAM,QAAQ,CAAC;AACvC,OAAO,EAAE,aAAa,EAAE,MAAM,kBAAkB,CAAC;AAEjD,8FAA8F;AAC9F,mGAAmG;AACnG,iGAAiG;AACjG,wEAAwE;AACxE,MAAM,OAAO,GAAG,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AAC/C,MAAM,EAAE,OAAO,EAAE,OAAO,EAAE,GAAG,OAAO,CAAC,iBAAiB,CAAwB,CAAC;AAE/E,MAAM,MAAM,GAAG,IAAI,SAAS,CAAC;IAC3B,IAAI,EAAE,yBAAyB;IAC/B,OAAO,EAAE,OAAO;CACjB,CAAC,CAAC;AAEH,aAAa,CAAC,MAAM,CAAC,CAAC;AAEtB,iFAAiF;AAEjF,KAAK,UAAU,QAAQ;IACrB,MAAM,SAAS,GAAG,IAAI,oBAAoB,EAAE,CAAC;IAC7C,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;IAChC,OAAO,CAAC,KAAK,CAAC,mCAAmC,OAAO,mBAAmB,CAAC,CAAC;AAC/E,CAAC;AAED,iFAAiF;AAEjF,SAAS,QAAQ,CAAC,GAAoB;IACpC,OAAO,IAAI,OAAO,CAAC,CAAC,OAAO,EAAE,MAAM,EAAE,EAAE;QACrC,MAAM,MAAM,GAAa,EAAE,CAAC;QAC5B,GAAG,CAAC,EAAE,CAAC,MAAM,EAAE,CAAC,KAAa,EAAE,EAAE,CAAC,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC;QACtD,GAAG,CAAC,EAAE,CAAC,KAAK,EAAE,GAAG,EAAE;YACjB,IAAI,CAAC;gBACH,MAAM,GAAG,GAAG,MAAM,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC;gBACpD,OAAO,CAAC,GAAG,CAAC,CAAC,CAAE,IAAI,CAAC,KAAK,CAAC,GAAG,CAAa,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;YACnD,CAAC;YAAC,MAAM,CAAC;gBACP,MAAM,CAAC,IAAI,KAAK,CAAC,mBAAmB,CAAC,CAAC,CAAC;YACzC,CAAC;QACH,CAAC,CAAC,CAAC;QACH,GAAG,CAAC,EAAE,CAAC,OAAO,EAAE,MAAM,CAAC,CAAC;IAC1B,CAAC,CAAC,CAAC;AACL,CAAC;AAED,KAAK,UAAU,OAAO;IACpB,MAAM,IAAI,GAAG,QAAQ,CAAC,OAAO,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,MAAM,EAAE,EAAE,CAAC,CAAC;IACzD,+FAA+F;IAC/F,+FAA+F;IAC/F,+FAA+F;IAC/F,+FAA+F;IAC/F,kGAAkG;IAClG,+BAA+B;IAC/B,MAAM,IAAI,GAAG,OAAO,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,WAAW,CAAC;IAEhD,MAAM,UAAU,GAAG,YAAY,CAAC,KAAK,EAAE,GAAoB,EAAE,GAAmB,EAAE,EAAE;QAClF,MAAM,GAAG,GAAG,GAAG,CAAC,GAAG,IAAI,GAAG,CAAC;QAE3B,IAAI,GAAG,KAAK,SAAS,IAAI,GAAG,CAAC,MAAM,KAAK,KAAK,EAAE,CAAC;YAC9C,GAAG,CAAC,SAAS,CAAC,GAAG,EAAE,EAAE,cAAc,EAAE,kBAAkB,EAAE,CAAC,CAAC;YAC3D,GAAG,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,EAAE,yBAAyB,EAAE,OAAO,EAAE,OAAO,EAAE,CAAC,CAAC,CAAC;YAC/F,OAAO;QACT,CAAC;QAED,IAAI,GAAG,KAAK,MAAM,IAAI,GAAG,CAAC,MAAM,KAAK,MAAM,EAAE,CAAC;YAC5C,IAAI,IAAa,CAAC;YAClB,IAAI,CAAC;gBACH,IAAI,GAAG,MAAM,QAAQ,CAAC,GAAG,CAAC,CAAC;YAC7B,CAAC;YAAC,MAAM,CAAC;gBACP,GAAG,CAAC,SAAS,CAAC,GAAG,EAAE,EAAE,cAAc,EAAE,kBAAkB,EAAE,CAAC,CAAC;gBAC3D,GAAG,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,EAAE,KAAK,EAAE,mBAAmB,EAAE,CAAC,CAAC,CAAC;gBACxD,OAAO;YACT,CAAC;YACD,MAAM,SAAS,GAAG,IAAI,6BAA6B,CAAC;gBAClD,kBAAkB,EAAE,SAAS;gBAC7B,kBAAkB,EAAE,IAAI;aACzB,CAAC,CAAC;YACH,GAAG,CAAC,EAAE,CAAC,OAAO,EAAE,GAAG,EAAE,CAAC,SAAS,CAAC,KAAK,EAAE,CAAC,CAAC;YACzC,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;YAChC,MAAM,SAAS,CAAC,aAAa,CAAC,GAAG,EAAE,GAAG,EAAE,IAAI,CAAC,CAAC;YAC9C,OAAO;QACT,CAAC;QAED,GAAG,CAAC,SAAS,CAAC,GAAG,EAAE,EAAE,cAAc,EAAE,kBAAkB,EAAE,CAAC,CAAC;QAC3D,GAAG,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,EAAE,KAAK,EAAE,WAAW,EAAE,CAAC,CAAC,CAAC;IAClD,CAAC,CAAC,CAAC;IAEH,UAAU,CAAC,MAAM,CAAC,IAAI,EAAE,IAAI,EAAE,GAAG,EAAE;QACjC,OAAO,CAAC,KAAK,CAAC,mCAAmC,OAAO,sBAAsB,IAAI,IAAI,IAAI,MAAM,CAAC,CAAC;IACpG,CAAC,CAAC,CAAC;AACL,CAAC;AAED,iFAAiF;AAEjF,MAAM,SAAS,GAAG,OAAO,CAAC,GAAG,CAAC,WAAW,CAAC,IAAI,OAAO,CAAC;AACtD,IAAI,SAAS,KAAK,MAAM,EAAE,CAAC;IACzB,OAAO,EAAE,CAAC,KAAK,CAAC,CAAC,GAAY,EAAE,EAAE;QAC/B,OAAO,CAAC,KAAK,CAAC,eAAe,EAAE,GAAG,YAAY,KAAK,CAAC,CAAC,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC;QACjF,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IAClB,CAAC,CAAC,CAAC;AACL,CAAC;KAAM,CAAC;IACN,QAAQ,EAAE,CAAC,KAAK,CAAC,CAAC,GAAY,EAAE,EAAE;QAChC,OAAO,CAAC,KAAK,CAAC,eAAe,EAAE,GAAG,YAAY,KAAK,CAAC,CAAC,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC;QACjF,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IAClB,CAAC,CAAC,CAAC;AACL,CAAC"}