Skip to main content

b2c-production-triage

Investigate B2C Commerce incidents using B2C MCP logs, SCAPI code-mode job/data reads, and CLI fallbacks. Route error spikes, stale data, or checkout failures to focused runbooks and produce a team or Support handoff.

소스 정보

저장소
SalesforceCommerceCloud/b2c-developer-tooling
최근 소스 활동
2026년 9월 14일 02:38
감지된 SKILL.md 언어
영어
스타
54
포크
21

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
b2c-production-triage
description
Investigate B2C Commerce incidents using B2C MCP logs, SCAPI code-mode job/data reads, and CLI fallbacks. Route error spikes, stale data, or checkout failures to focused runbooks and produce a team or Support handoff.
# Production triage Connect the toolkit's logs, job executions, business data, and configuration into an evidence-backed assessment and next action. Investigation does not authorize remediation. Use the symptom routes below rather than collecting every available signal. ## Scope and impact - Resolve the task's project/instance with `config_inspect`; CLI: `b2c setup inspect`. Preserve the resolved target across calls. Ask for missing site, time window, timezone, symptom, or expected behavior; never invent IDs or silently switch tenants. - Start with the reported interval; if unspecified, propose the last two hours and label that assumption. Use fixed UTC boundaries for comparisons and paging. - Record current impact (sites, checkout availability, order/data integrity, workaround) and the incident owner. Apply the team's severity policy; do not invent a priority or support SLA. Escalate active material impact early without waiting for root cause; agree who communicates and the next update time. ## Access and tools - Establish access: MCP, terminal/CLI, logs, data, source. Operator work does not require a cartridge checkout. Credentials/setup issues: MCP `mcp/b2c-config` section `setup-and-access`; native `b2c-config`/`b2c-auth`, or the [authentication guide](https://salesforcecommercecloud.github.io/b2c-developer-tooling/guide/authentication). Prefer dedicated MCP tools; discover available names once. Read `skill://mcp/scapi/SKILL.md` before using `scapi_search`/`scapi_execute`, as those tools require. Read only the matching runbook/reference, not every linked skill. Native assistants use the installed skill name; MCP can read these URIs or use `skills_read` with `collection: "b2c-ops"` and a task query. | Symptom | Toolkit path | Decision / detail | | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Error spike or integration errors | `logs_list_files` -> returned `prefix` -> `logs_get_recent` with `count: 20`, `since`, and a relevant `search` | Defaults cover error/customerror, not every `custom-*` integration log. CLI: `b2c logs list` / `b2c logs get`. | | Failed job or stale data | Code mode `codemode.describe("builtin/failed-job-triage")`, then run with fixed `from`/`to` -> execution IDs and `logFilePath` -> log tools | [Job health](skill://b2c-ops/b2c-job-health/SKILL.md) covers continuation, step details, exact WebDAV logs, and green-but-incomplete runs. | | Checkout failures or orders down | Custom logs -> determine whether failures produce order records -> relevant data/traffic evidence | [Checkout triage](skill://b2c-ops/b2c-checkout-triage/SKILL.md) distinguishes checkout symptoms from failed-order records. | | Find/count FAILED orders or investigate affected products | Verify Admin filter support; otherwise external OCAPI Shop order search -> safe IDs -> logs and selected Admin product reads | [Failed-order triage](skill://b2c-ops/b2c-order-failure-triage/SKILL.md) owns enumeration, count/sample limits, and the workaround. No OCAPI helper exists inside code mode. | | Suspected code change | Code mode `builtin/code-version-inspect`: active/rollback versions and activation/modification timestamps | Current metadata is not a complete activation history. Corroborate with release records. | | Runtime-only defect | [MCP debugger](skill://mcp/debugger/SKILL.md) on an authorized reproduction target | Operator handoff is valid without source access. Do not halt production requests for routine triage. | ## Checks and decisions 1. Carry the returned configuration `resolution` into the evidence record. `config_inspect` stays masked; do not read `dw.json` or request tokens merely to make managed MCP calls. Pass the same project/instance context to CLI fallbacks. 2. Join signals using execution IDs, log timestamps, and affected record IDs. For exact job logs, pass the returned `logFilePath` to `webdav_get`; use byte continuation or download locally. Recent-log tools remain preferred for filtered samples/watches. A bounded result is not full-interval coverage. 3. Reuse code-mode snippet totals/window/`nextOffset`; do not return entire schemas or records. The failed-job snippet omits step details and healthy runs: use `builtin/job-execution-inspect` / `builtin/job-execution-review` selectively. Compare expected business data with a healthy input before calling a green job healthy. 4. Preserve failed stages: HTTP `ok`/`status` and diagnostics, or thrown auth/transport/safety errors. An OCAPI fallback error may mask an earlier SCAPI rejection; CLI `--api-backend scapi` isolates it. POST searches can be blocked by Safety Mode despite being reads. Do not infer missing scopes from every 403 or treat unavailable counts as zero. ## Mitigation and recovery Recommend the smallest supported mitigation, its blast radius and rollback limit. The authorized owner decides; inspecting an incident is not permission to change it. Restore service when justified without waiting for a full causal explanation. After intervention, recheck business behavior and comparable signals over an agreed observation interval. Report recovered, partial, pending, or unknown; record follow-up prevention separately from immediate recovery. ## Escalation and handoff Report: target/site; UTC window; observed impact and denominator; evidence locations (execution IDs, log path/timestamps, minimal excerpts); suspected component/input/change; alternative explanations; access gaps; next owner/action. Exclude tokens, payment details, and unnecessary customer data. Route custom-code evidence to the developer/implementation partner, grant or schedule issues to the administrator, provider failures to the integration owner, and suspected platform failures to Salesforce Support. Read [escalation and case template](references/escalation.md) when preparing a handoff. Do not submit a case/message without authorization or claim a confirmed cause when evidence establishes only a lead.
GitHub에서 보기