@bridge_gpt/mcp-server 0.2.58 → 0.2.60

package/build/merge-workflow-config.js

@@ -0,0 +1,133 @@
+/**
+ * Configuration names and the command-fetch contract the RENDERED merge workflow
+ * consumes (BAPI-1136).
+ *
+ * ## Why these live here and not in `conductor/merge-execution-contract.ts`
+ *
+ * That module documents itself as the byte-for-byte TypeScript MIRROR of
+ * `api/library/epic_implementer/merge_execution_contract.py`: every constant in
+ * it has a Python twin whose spelling must match exactly. None of the values
+ * below has one. They are the workflow's OWN runtime configuration — a GitHub
+ * Actions secret name, a GitHub Actions variable name, a fallback base URL, and
+ * the shape of an endpoint the rendered YAML calls — so keeping them in the
+ * mirror would have made that module two things at once.
+ *
+ * There is also a mechanical reason, and it is a good one: a static invariant
+ * forbids any `conductor/*.ts` except `bridge-api-client.ts` from containing the
+ * literal `BAPI_BASE_URL`, because conductor code must reach the Bridge API only
+ * through its dedicated sanitized client. This module reaches the Bridge API not
+ * at all — it names a string that the CUSTOMER's workflow reads from its own
+ * repository variables — but the guard is textual, and the right response to it
+ * was to put these values where they belong rather than to work around it.
+ */
+import { MERGE_WORKFLOW_EXPECTED_VERSION } from "./conductor/merge-execution-contract.js";
+/** Re-exported so a consumer needs one import for the workflow's whole contract. */
+export { MERGE_WORKFLOW_EXPECTED_VERSION };
+/**
+ * The ONE repository-level GitHub Actions secret the rendered workflow reads.
+ *
+ * Only the NAME lives here, and only the name ever appears in a rendered
+ * template, an installer message, or the README. The customer provisions the
+ * value themselves through GitHub's own secret UI or API; the installer never
+ * accepts, transmits, prints, or writes it (ratified review decision E-18).
+ *
+ * Repository-scoped rather than organization-scoped on purpose: a repository
+ * reviewer can create a repository secret, while an organization secret needs a
+ * second actor the install command cannot name in advance.
+ */
+export const MERGE_WORKFLOW_API_KEY_SECRET_NAME = "BAPI_API_KEY";
+/**
+ * The repository-level Actions VARIABLE (not a secret) that overrides the Bridge
+ * base URL the workflow calls back into.
+ *
+ * A variable, not a dispatch input: the two dispatch inputs are fixed at
+ * `action_key` and `lease_owner` (BAPI-1134), and a base URL supplied by whoever
+ * triggered the dispatch would let the caller choose which server authorizes the
+ * merge. Absent, the workflow uses {@link MERGE_WORKFLOW_DEFAULT_BASE_URL}.
+ */
+export const MERGE_WORKFLOW_BASE_URL_VARIABLE_NAME = "BAPI_BASE_URL";
+/** The hosted Bridge API the rendered workflow falls back to. */
+export const MERGE_WORKFLOW_DEFAULT_BASE_URL = "https://bridgegpt-api.com";
+/**
+ * The durable merge-command fetch contract the rendered workflow consumes.
+ *
+ * ## Why a named contract rather than a live route
+ *
+ * The SERVER half of this contract is not in the tree. BAPI-1134 shipped the
+ * dispatch emitter with its durable-command persistence resolved lazily
+ * (`api/library/epic_implementer/reconciler.py`'s
+ * `_resolve_durable_merge_command_store`, which imports
+ * `api.library.vcs.epic_implementer_merge_command_store.persist_merge_command`
+ * and returns `None` today), and recorded that store as "a slice of its own"
+ * blocked on an unnamed sibling. The BAPI-1136 review ratified carving that
+ * store and its fetch endpoint out as a separate A2 child that lands FIRST
+ * (decision E-14), with this child writing the workflow's fetch step against the
+ * named contract below.
+ *
+ * ## What that means operationally
+ *
+ * Until the sibling child lands, the endpoint answers 404 and the rendered
+ * workflow refuses with `merge_command_unavailable` before touching the pull
+ * request — no retry, no merge, no completion report. The merge lane is
+ * therefore INERT by construction rather than by a flag someone could flip: no
+ * dispatch is emitted at all while the command store is absent, and a dispatch
+ * that somehow arrived would be refused at the first step. That is the block on
+ * operational enablement; {@link MERGE_WORKFLOW_EXPECTED_VERSION} exact equality
+ * remains the SEPARATE deploy-ordering refusal it already was, and neither
+ * substitutes for the other.
+ *
+ * ## Shape
+ *
+ * Keyed by `action_key`, NOT by pull request number: the workflow learns the
+ * pull request FROM the command, so a PR-scoped route could not be called. That
+ * is also why a fetch failure cannot be reported through
+ * `POST /vcs/pull-requests/{pr}/merge/complete` — the path parameter is not yet
+ * resolved — and the lease's own expiry is the reconciler's backstop for that
+ * one window.
+ */
+export const MERGE_COMMAND_FETCH_METHOD = "POST";
+/** Root-mounted, repo-authorized path of the durable command fetch. */
+export const MERGE_COMMAND_FETCH_PATH = "/vcs/merge-commands/fetch";
+/**
+ * The request fields the fetch accepts, in the contract's own spelling.
+ *
+ * `lease_owner` is the per-attempt secret BAPI-1134 mints; it is presented here
+ * as PROOF that this dispatch is the live attempt, never echoed, and never a
+ * response field.
+ */
+export const MERGE_COMMAND_FETCH_REQUEST_FIELDS = [
+    "repo_name",
+    "action_key",
+    "lease_owner",
+];
+/**
+ * The separator and field position the Bridge repository name occupies inside a
+ * merge action key (`merge:{repo}:{pr}:{head_sha}:{gate_identity}`, built by
+ * `makeMergeActionKey`).
+ *
+ * The workflow derives `repo_name` from the key it was dispatched with rather
+ * than accepting a third dispatch input, so the Bridge-side identity and the
+ * attempt identity cannot disagree.
+ */
+export const MERGE_ACTION_KEY_REPO_FIELD_INDEX = 1;
+/**
+ * The response projection the workflow consumes, in the contract's own spelling.
+ *
+ * `lease_owner` is deliberately ABSENT: a response that echoed the live
+ * per-attempt secret would hand it to every log that captured the body.
+ *
+ * `github_repository` is the provider-side `owner/name` the command was issued
+ * against. The workflow compares it with `github.repository` before reading the
+ * pull request, so a command minted for a different repository cannot actuate
+ * here even if its key and lease were presented correctly.
+ */
+export const MERGE_COMMAND_FETCH_RESPONSE_FIELDS = [
+    "action_key",
+    "repo_name",
+    "github_repository",
+    "pr_number",
+    "expected_head_sha",
+    "merge_method",
+    "execution",
+    "lease_expires_at",
+];

package/build/merge-workflow-drift.js

@@ -0,0 +1,66 @@
+/**
+ * Canonical byte identity for the Epic Implementer merge workflow (BAPI-1136).
+ *
+ * The merge workflow is the one file in a customer repository that can perform a
+ * privileged write on Bridge's behalf, so "is the installed copy the copy Bridge
+ * ships?" has to be answerable cheaply, in more than one place, and with one
+ * answer. This module is that one place.
+ *
+ * It follows `claude-review-workflow-drift.ts`'s shape deliberately: a leaf
+ * module with NO filesystem, network, or subprocess access, importing only the
+ * shared Git blob hash so two workflow-identity implementations cannot drift
+ * apart about what "the same file" means. Callers acquire bytes however their
+ * own layer already does and hand them in.
+ *
+ * Nothing here logs file content: a classification carries a path, a pair of
+ * SHAs, and a closed-vocabulary state — never bytes, never provider text.
+ */
+import { computeGitBlobSha } from "./claude-review-workflow-drift.js";
+import { MERGE_WORKFLOW_PATH } from "./conductor/merge-execution-contract.js";
+import { renderEpicImplementerMergeWorkflow } from "./merge-workflow.js";
+export { MERGE_WORKFLOW_PATH };
+/**
+ * The Git blob SHA-1 of the workflow this build renders.
+ *
+ * Computed, never hardcoded. A checked-in literal would be a second byte source
+ * the renderer could silently diverge from — exactly the drift this module
+ * exists to make impossible.
+ */
+export function canonicalMergeWorkflowSha() {
+    return computeGitBlobSha(Buffer.from(renderEpicImplementerMergeWorkflow(), "utf8"));
+}
+/**
+ * Every Bridge-published historical rendering of the merge workflow, by Git blob
+ * SHA, with the contract version it declared.
+ *
+ * Empty at contract version 1: there is no earlier published version to upgrade
+ * FROM. A future contract version adds its predecessor's SHA here, and only
+ * then can {@link classifyMergeWorkflowContent} return `managed_version_older`.
+ */
+export const MANAGED_MERGE_WORKFLOW_HISTORY = new Map();
+/**
+ * Classify an installed copy against the canonical bytes.
+ *
+ * `existing` is `null` for an absent file. The comparison is on RAW BYTES, not
+ * normalized text: a copy that differs only in line endings is still a copy this
+ * installer did not write, and treating it as identical would let a rewrite hide
+ * behind a whitespace-insensitive compare.
+ */
+export function classifyMergeWorkflowContent(existing) {
+    if (existing === null)
+        return "not_installed";
+    const canonical = renderEpicImplementerMergeWorkflow();
+    if (existing === canonical)
+        return "identical";
+    const sha = computeGitBlobSha(Buffer.from(existing, "utf8"));
+    if (MANAGED_MERGE_WORKFLOW_HISTORY.has(sha))
+        return "managed_version_older";
+    return "modified_or_unrecognized";
+}
+/** Operator-facing gloss for each classification. Secret-free and path-only. */
+export const MERGE_WORKFLOW_CLASSIFICATION_TEXT = {
+    not_installed: `${MERGE_WORKFLOW_PATH} is not installed`,
+    identical: `${MERGE_WORKFLOW_PATH} already matches the version this build ships`,
+    managed_version_older: `${MERGE_WORKFLOW_PATH} is an older Bridge-managed version and can be upgraded`,
+    modified_or_unrecognized: `${MERGE_WORKFLOW_PATH} has been modified or is not a version Bridge published`,
+};