SC4SAP Configuration → Document

Reads the module's IMG structure and configuration tables from the live system and writes one HTML file: an IMG tree with search and status filters on the left, one page per IMG activity (screen drawing with the real values, the full value table, customer changes, checks, SAP documentation) and a checklist panel on the right.

<Response_Prefix>Every response triggered by this skill MUST begin with [Model: <main-model> · Dispatched: <sub-summary>] per ../../common/model-routing-rule.md § Response Prefix Convention.</Response_Prefix> <Cost_Mode>Resolve the cost mode per ../../common/cost-mode.md (standard default; eco → Skill("sc4sap:eco", "--attach") first and on every continuation turn, plus this skill's eco recipe in § lever C).</Cost_Mode>

<Team_Mode>No teamMode integration. Extraction and drawing are scripted; agents only write and review the consultant notes (Step 4).</Team_Mode>

<Use_When>

• "설정 문서", "컨피그 리스트", "configuration list", "IMG 설정 정리", "SPRO 설정 문서화", "설정 점검", "config audit", "how is MM configured in this system"
• Go-live / handover / audit: the configuration must be written down as it is
• Before a rollout or a system copy: what did the project change in the IMG </Use_When>

<Do_Not_Use_When>

• One program's behaviour → /sc4sap:program-to-spec or /sc4sap:program-to-manual
• A question about one setting → /sc4sap:ask-consultant (answers in chat)
• Business-process documentation of a module's custom development → /sc4sap:module-to-process </Do_Not_Use_When>

<Decisions_Fixed> Settled when the skill was designed — do not ask again:

• Real values, as they are. The document shows the table values exactly as read (organisation names included). It is an internal document; say so once in the closing message.
• Read-only. Only customizing / system tables (delivery class C, G, E, S, W), DDIC metadata and the transport key tables are read — on ECC through ZMCP_ADT_DISPATCH TABLE_READ, which refuses everything else. The MCP blocklist still applies; a refused table shows as "Not readable" in the document, never as a failure.
• Customer change = customer transport. A row counts as customer-changed when a non-SAP transport (E071K, TRKORR NOT LIKE 'SAP%') recorded its key, in any client.
• Language. Texts (IMG titles, field labels, value texts) in the document language when the system has them, else English. SAP documentation is mostly English.
• One file. HTML with data and drawings embedded; works offline; prints. </Decisions_Fixed>

Step 1 — Module and preflight. Take the module from the arguments; if missing, ask with AskUserQuestion (MM first, recommended). Confirm the active profile (.sc4sap/active-profile.txt) in one line.

Step 2 — Areas. Run

node scripts/config/extract-config.mjs --module <M> --list-areas

Show the areas (document language + English) and ask with one AskUserQuestion (multiSelect: true, first option "All areas (Recommended)"). A full MM run reads about 1,300 tables (15–25 minutes on ECC); say so when the user picks all.

If the command fails with TABLE_READ: table … is not allowed on an IMG table (TNODEIMG, CUS_IMGACH), the system's ZMCP_ADT_DISPATCH predates the customizing allow rule: stop and tell the user to update it from abap/zmcp_adt_dispatch_ecc.abap (setup Step 9) — never work around the dispatcher.

Step 3 — Extract. Run in the background (run_in_background: true):

node scripts/config/extract-config.mjs --module <M> [--areas "<Area 1>,<Area 2>"] [--lang <lang>]

It prints progress (tables n/N) on stderr and one JSON line at the end: { ok, file, counts }. An interrupted run resumes from its read cache; --fresh starts over (use it when the user asks for a refresh of an earlier document). Report the counts when it finishes. The run also reads the SAP F1 documentation of every column's data element (fieldDocs); a snapshot extracted before that feature gets it with --field-docs (only those reads, the snapshot is kept). A table with more rows than --max-rows (1000) — per-plant tables on a system with many plants — is read again up to the 5000-row read cap and split by its key fields, text tables in the document language and English only; --no-full keeps the old limit.

Step 4 — Consultant notes and reference material (written, then reviewed). Per IMG activity the notes card (purpose, effect of this system's values, cautions, references) and the reference panel (SAP documentation summarised in the document language, 2–3 setup cases with flow diagrams and which one this system follows, comparison table, decision checklist, decision criteria, official SAP sources — Help Portal, Notes / KBAs, Learning — opened and cited) are written by the module consultant agent and reviewed by sap-critic; never by the main thread. In cost mode standard the notes-writer dispatch passes effort: "medium" (writer and revision); in eco it runs with the consultant and critic on Sonnet · low (common/cost-mode.md lever A). Prompts: notes-prompts.md — use them verbatim with the placeholders filled. 0. Terms first. node scripts/config/notes.mjs terms --module <M> → terms/_in/tNNN.json (names SAP has no document-language text for: IMG folders, activity titles, field labels; 150 per batch; translated terms are reused by later runs). Per batch: writer then reviewer, prompt § 4. Skip when it reports 0 terms.

1. Scope — ask on every run. node scripts/config/notes.mjs scopes --module <M> prints activities and batches per scope (activities with reviewed notes from earlier runs are left out). Ask with one AskUserQuestion, each option labelled with its numbers from that output and the cost (one batch ≈ 12 activities, a writer, a reviewer and usually a revision run with web research — measured on MM: about 750k tokens and 40 minutes per batch):
   • custom — activities customer transports changed (Recommended)
   • values — also standard and empty ones (every activity with a table)
   • all — every activity, including transaction-only ones
   • none — no notes this run; the document is built without new notes Then node scripts/config/notes.mjs batches --module <M> --scope <scope> --size 12 → notes/_in/bNNN.json (numbered after existing batches; --redo rewrites reviewed activities too, only when the user asks).
2. Write — per batch, Agent(subagent_type: "sc4sap:sap-<m>-consultant") with prompt § 1 (saves --kind draft). Batches run in parallel, at most 4 at a time.
3. Review — per batch, prompt § 2: (a) notes-lint.mjs on the main thread (sources, transactions, counts, check findings — no tokens), (b) sc4sap:sap-critic judges SAP meaning with the lint facts in hand and opens only sources the lint marks new / changed (saves --kind review, prints the fix list). Saving a review adds the sources of every ok activity to the verified-source cache, which later batches receive as knownSources; notes.mjs sources --module <M> seeds that cache from batches reviewed before it existed.
4. Revise — for a batch with fix items, the writer agent again with prompt § 3 (saves --kind revised). One round; findings still open after it stay visible in the document ("Review findings open").
5. node scripts/config/notes.mjs status --module <M> must show draft + review for every batch of this run before Step 5 (skip this step with scope none). 5a. Korean polish (document language ko). Per common/humanize-korean.md, <dir> = notes/_humanize: texts = node scripts/lib/humanize.mjs texts-json <the newest note file of each batch of this run: notes/bNNN.revised.json, else bNNN.draft.json> --skip refs,sources --out <dir>/texts.json, apply = node scripts/lib/humanize.mjs apply-json <dir>/texts.json <dir>/humanized.json (or fixed.json). Only the consultant's notes — never review files, SAP texts or SAP documentation quoted as is. Before the knowledge base, so it keeps the polished text.
6. Knowledge base. node scripts/config/notes.mjs kb --module <M> copies the general part of every reviewed note (purpose, SAP documentation summary, cases without the verdicts, comparison, checklist, criteria, official sources) to ~/.sc4sap/kb/config/<M>/<lang>/. Later runs — this system again or any other system — mark those activities "mode": "system" in their batches: the writer adds only impact, cautions and one verdict per case, with no web research, and the reviewer checks only that part. On MM this cuts a batch to a fraction of the first-run cost.
7. Column meanings. node scripts/config/fields.mjs batches --module <M> → fields/_in/fNNN.json (100 data elements per batch: label, domain values, F1 text, where used, samples) for every column that shows values and has no meaning in ~/.sc4sap/kb/fields/<lang>.json yet. Per batch the module consultant writes one business meaning per data element and sap-critic saves corrections only (prompt § 5, no web research; measured on SD: 24 batches, about 2 corrections per 100). fields.mjs status must show draft + review for every batch, then fields.mjs kb --module <M> adds them to the knowledge base, shared by every module — a later module writes only the data elements it does not share. Independent of the notes scope; skip it only when the user declines.
8. BAdI implementations. The extraction reads every customer implementing class of the module's BAdIs (GetClass, then the Z includes it branches into, two levels deep): per method code or empty, size and the objects it calls. node scripts/config/badi-notes.mjs batch --module <M> → badi/_in.json; the module consultant writes a summary and one line per method with code, sap-critic checks them against the source (reading called Z function modules), the writer revises once (prompt § 6). System-specific: nothing goes to the knowledge base.
9. Value meanings. node scripts/config/values.mjs batches --module <M> → values/_in/vNNN.json (40 domains per batch) for every domain with two or more fixed values behind a shown column (flag domains X / blank skipped) that is not yet in ~/.sc4sap/kb/values/<lang>.json or queued by another module: per value the document-language and English SAP text and the rows using it, plus F1 and where used. Per batch the module consultant writes one line per value, sap-critic saves corrections only (prompt § 7). Document-language texts are often wrong (literal, swapped, untranslated, typos) — the meaning calls that out. values.mjs status, then values.mjs kb --module <M>; the ⓘ value list shows them in a "Meaning" column. Needs a snapshot with English domain texts (domainsEn, extract again if missing).

Step 5 — Build.

node scripts/config/build-config-doc.mjs --module <M> [--lang <lang>] [--import <edited.html>]

Output: <artifactBase>/config-docs/<M>/<M>-config-v<n>-<lang>.html (status counts, checks with findings and edited notes in the JSON line). When the user hands back a page saved from edit mode, build with --import <file>: its edits merge into notes/edits.json (per activity or view the newer edit wins; a page from another system or module is refused) and every later build keeps them — edited views replace their values, card title and history and are drawn again. Edits never enter the knowledge base.

Step 6 — Close. Report in the user's language:

• the file path, IMG activities by status (customized / standard / not set / no values / not readable),
• the check findings by severity, error ones by title,
• tables that could not be read, and why (blocklist, dispatcher),
• one line: the document holds the system's real configuration values — share it internally only.

Do not paste table contents into chat. </Workflow>

<Document_Contents> Per IMG activity: IMG path, title (document language + English), status badge, T-codes, consultant notes with their review state, objects (view / view cluster / table), row and customer-row counts; for each view an SM30 overview drawn with the first rows (customer rows first) and, for wide views, a detail screen of one row; the full value table (an ⓘ on each column header and a folded "column meanings" list above the table: business meaning and SAP F1 text per column; key columns bold, fixed-value texts next to codes, customer rows highlighted with their transports, filter and "customer rows only"); the customer transports that touched the table (date, request, user, description); checks for the activity; SAP's IMG documentation. Overview: counts by status, areas with status bars, recent customer transports. Right panel: all check findings, click to jump.

Edit mode ("Edit" in the top bar, nothing installed): the consultant notes and the reference panel become editable plain text — add or delete list items, add notes to an activity without them, delete a source — and so do the views: card title, value-table cells (rows added or deleted) and the change-history rows. Edited notes and views carry an "Edited · author · date" badge, so readers see where the page differs from the system; an edited view's SM30 drawing is drawn again from the edited rows at the next --import build. Any drawing (overview or detail) can be replaced by a real screenshot — "Use screenshot", or click the drawing and Ctrl+V; "Original screen" brings the drawing back; captures wider than 1800 px are scaled down. Undo (Ctrl+Z / button), autosave to the browser with "continue editing" on reopen. "Save" asks for author and change note and downloads the page with every edit embedded (<script id="config-edits">) — the file to hand back for --import. </Document_Contents>