PluginPublic

adobe/aem-cloud-service

All AEM as a Cloud Service skills: component development, Workflow model design, development, triggering, launchers, debugging, and triaging, Dispatcher config authoring, advisory, incident response, performance tuning, and security hardening, Rapid Development Environment (RDE) deployment, log inspection, snapshots, and troubleshooting via `aio aem rde`, Jackrabbit Oak query/index tuning (property, Lucene index definitions), and extracting/inventorying JCR queries (XPath, SQL2, QueryBuilder) across a codebase.

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Dispatcher Conversion — Decision Catalog (Branch E)

This is Branch E's decision catalog — the skill's knowledge center for dispatcher conversion, and the reference the agent consults during phase 5 (JUDGMENT + CROSS-BOUNDARY) of the flow in context.md, after Adobe's converter tool has run and its output has passed verification. For every AMS/on-premise construct still sitting in the config — because the tool doesn't touch it, only partially resolves it, or deliberately leaves it for a human — this catalog says what to do, why, and which Adobe doc backs the call.

The catalog is grounded in a real customer AMS→AEMaaCS dispatcher migration: every numbered row below reproduces a construct actually found in that config, not a hypothetical. Most rows apply regardless of standard vs flexible mode; a few — conf.d/whitelists/ in row 4 (a folder under conf.d/, a sibling of conf.dispatcher.d/, not nested inside it), and the farm-side items in the tool-handled bucket — are specific to the AMS v2.0 layout the tool's AMS-path executor (standard mode) expects. See context.md's mode taxonomy if you're unsure which mode applies to the config in front of you.

Primary Adobe references (cited per row below):

AMS transition guide — Transitioning to AEM as a Cloud Service — Dispatcher — the AMS→AEMaaCS dispatcher transition rules this whole conversion is based on.
Dispatcher overview — Dispatcher in AEM as a Cloud Service — allowed/disallowed directives, TLS terminating at the edge.
Author caching — Author caching in AEM as a Cloud Service — why dispatcher config is ignored on author.

How to use this catalog

Match what you find in the inventory (or in the tool's own conversion-report.md) against each row's Signal; apply the paired Action. Four things hold across every row:

Some rows happen before the tool runs, not after. The AMS-path tool's early passes — deleting conf.modules.d/, deleting every top-level conf.d/*.conf file, deleting conf.d/whitelists/ — are content-blind and run during phase 3 (EXECUTE), long before phase 5 (JUDGMENT) ever sees the output. If a deleted file or folder has content worth keeping, that has to be pulled out of the source before the tool runs, or re-added to the output afterward — phase 5 cannot "preserve" something the tool already deleted. Every row below is tagged with one of: Fully tool-handled (auto) (no agent action — just confirm it happened), Needs pre-tool handling (act on the source before running the tool), Needs post-tool handling (act on the tool's output afterward), or Cross-boundary hand-off (route to another branch).
A commented-out directive is not a resolved one. The tool's own non-whitelisted-directive pass (the last rule it runs, and the only one that touches the surviving vhost files) comments anything outside the dispatcher's supported directive set — it does not delete it, and it does not decide whether the underlying need still applies. Treat every directive the tool commented as open until this catalog (or the user) resolves it; never ship a "converted" config with #-commented AMS directives still sitting in it.
"Drop" and "preserve content" are different shapes of action, not different degrees of the same one. Most unsupported files are wholesale-deleted by the tool with nothing worth saving. Row 10 (security.conf) is the exception with content worth saving — but because the tool deletes the whole file automatically in the same first pass as rows 6/7/9/11/12, "preserving" it means extracting the supported directives from the source before/around the run and re-adding them to the output afterward, not editing the tool's output in place.
Cross-boundary items are handed off, not finished here. Branch E identifies and names the problem; it does not create Cloud Manager variables or author CDN configuration itself — see "Variables and the Cloud Manager hand-off" and "CDN candidates" below.

Decision catalog

Logging and custom directives

#	Signal	Action	Reason	Adobe reference
1	`LogLevel` set to a non-default/custom value (e.g. `LogLevel ... rewrite:info`), or a custom `LogFormat`/`ErrorLogFormat` inline in a vhost	Needs post-tool handling. Remove the directive; flag for confirmation	Custom log levels/formats sit outside the dispatcher's supported directive set — left in place, the Cloud Manager dispatcher validator fails the build. Note: because this lives inline in a vhost file (not a standalone `conf.d/.conf` file), it survives the tool's early deletes and only gets commented* by the tool's directive-whitelist pass; that is a flag for the agent to resolve, not a fix by itself.	Dispatcher overview

TLS/SSL — terminates at the CDN edge, not the dispatcher

Row 11 (a whole ssl.conf-style file) and row 3 (a PUBLISH_FORCE_SSL <If> block in a vhost) are removed automatically by the tool. Row 2 (the same class of directive written inline in a vhost that otherwise survives) is not — the tool only comments it out.

#	Signal	Action	Reason	Adobe reference
2	`SSLEngine On`, `SSLCertificateFile`, `SSLCertificateKeyFile` (any `mod_ssl` directive) written inline in a vhost	Needs post-tool handling. Remove; flag as a CDN-configuration concern	The AEMaaCS dispatcher only ever receives plain HTTP — TLS terminates at the Adobe CDN edge, not at the dispatcher. These directives also sit outside the supported directive set, so the tool's directive-whitelist pass comments them out (it does not delete them, and it does not decide whether a CDN-side equivalent is needed).	Dispatcher overview
3	`<If "${PUBLISH_FORCE_SSL} == 1"> Include ...xforwarded_forcessl... </If>` (or an equivalent force-SSL rewrite include) in a vhost	Fully tool-handled (auto) — no agent action. The tool strips every `<If>` block gated on `PUBLISH_FORCE_SSL` (and `DISP_ID`, `PUBLISH_WHITELIST_ENABLED`) out of vhost files early in its run, well before phase 5. Confirm it's gone; don't redo it.	Redundant once TLS is enforced at the CDN edge — HTTP→HTTPS redirection is handled there, not by a dispatcher-side rewrite. This is exactly the kind of AMS-only conditional the transition guide has the tool remove mechanically, which is why it is not a phase-5 decision.	AMS transition guide
11	`conf.d/ssl.conf`, `000__ssl.conf` (per-vhost SSL config as its own top-level `conf.d/.conf` file)	Fully tool-handled (auto) — no agent action. The tool deletes every top-level `conf.d/*.conf` file unconditionally in its first pass, `ssl.conf` included. Confirm it's gone in the output; there's nothing left to delete by phase 5.	Same TLS-at-edge reasoning as row 2: SSL config has no valid role on a cloud dispatcher and would fail validation regardless of content — which is why the tool removes the whole file automatically rather than leaving it for a human.	Dispatcher overview

Includes and modules

The tool deletes both conf.modules.d/ (row 5) and conf.d/whitelists/ (row 4) automatically and unconditionally, in the same early, content-blind pass. Row 5 needs no agent action. Row 4 does — but only before the tool runs, and only if there is content worth keeping.

#	Signal	Action	Reason	Adobe reference
4	Any file `$include`d/`Include`d from a folder literally named `conf.d/whitelists/`	Needs pre-tool handling. Before running the tool: relocate `conf.d/whitelists/` → `conf.d/includes/` in the source* and repoint every referencing `$include`/`Include`. Do this regardless of what you think the content is worth — the SDK validator also fails on a folder literally named `whitelists`.	The AMS-path tool deletes the entire `conf.d/whitelists/` folder unconditionally, in an early pass — long before phase 5 ever runs. Waiting until after conversion to "relocate" this content is too late; it is already gone from the tool's output. This is a `standard`/AMS-path concern specifically: for `flexible`/on-premise configs, equivalent content lives in the httpd/vhost inputs and is handled there instead (see context.md's mode taxonomy).	AMS transition guide
5	`conf.modules.d/*` — loading additional/third-party Apache modules (e.g. a `mod_pagespeed` `.load`/`.conf` pair)	Fully tool-handled (auto) — no agent action. The tool deletes the whole `conf.modules.d/` directory unconditionally in the same first pass that removes top-level `conf.d/*.conf` files (rows 6/7/9/11/12). Confirm it's gone; don't redo it.	AEMaaCS dispatcher does not support loading additional Apache modules — the module binary can't be installed into the managed container, so there is nothing here worth extracting even before the tool deletes it (unlike `conf.d/whitelists/` or `security.conf`, which can carry salvageable content).	Dispatcher overview

Files the validator rejects outright (tool-deleted automatically, except row 8)

All of rows 6, 7, 9, 11, and 12 are top-level conf.d/*.conf files — the AMS-path tool deletes them unconditionally in its first pass, before phase 5 ever runs. These rows are reference/confirmation entries, not action items. Row 8 is the deliberate exception: its .rpmsave suffix means the tool's conf.d/*.conf glob does not match it, so nothing else removes it either.

#	Signal	Action	Reason	Adobe reference
6	`conf.d/logformat.conf` (custom log format definitions)	Fully tool-handled (auto) — no agent action. Same first-pass `conf.d/*.conf` deletion as row 5.	Same custom-log-format constraint as row 1: unsupported, and would fail validation if it somehow survived — which is exactly why the tool removes it automatically rather than leaving it for a human.	Dispatcher overview
7	`conf.d/autoindex.conf` (`IndexOptions`, `AddIconByType`, hardcoded `/usr/share/httpd/icons/...`)	Fully tool-handled (auto) — no agent action. Same first-pass `conf.d/*.conf` deletion as row 5.	The validator would fail on these directives, and the hardcoded container-filesystem path is Adobe-managed and isn't guaranteed stable across environments anyway — the tool removes the whole file rather than leaving stale, unusable content behind.	Dispatcher overview
8	`conf.d/mod_security.conf.rpmsave`	Needs post-tool handling. Drop it by hand — the tool will not.	An RPM-preserved backup file, never loaded by Apache in the first place — dead weight, not active config. Unlike its `.conf`-suffixed siblings in this section, its `.rpmsave` extension does not match the tool's `conf.d/*.conf` deletion glob, so it survives the tool run untouched and needs an explicit manual delete.	Dispatcher overview
9	`conf.d/mod_security.conf` (`SecPcreMatchLimit`, `SecPcreMatchLimitRecursion`, `SecDebugLog`, `SecAuditLog`; its `modsecurity.d/*` includes are missing)	Fully tool-handled (auto) — no agent action. Same first-pass `conf.d/*.conf` deletion as row 5.	`mod_security` directives sit outside the dispatcher's supported set, and the file's own includes point at a `modsecurity.d/*` tree that was never present — already broken before conversion, and gone after it without any agent involvement.	Dispatcher overview
12	`conf.d/welcome.conf`	Fully tool-handled (auto) — no agent action. Same first-pass `conf.d/*.conf` deletion as row 5.	References container-filesystem paths (the default Apache "It works" page under `/usr/share/httpd/...`) — same path-fragility concern as row 7, removed the same way.	Dispatcher overview

Preserving content the tool deletes wholesale

#	Signal	Action	Reason	Adobe reference
10	`conf.d/security.conf` mixing supported content with unsupported directives (`ServerTokens Prod`, `<Limit> ... </Limit>`)	Needs pre-tool extraction + post-tool re-add — not an in-place strip. Before/around the run: pull whichever directives in `security.conf` are actually supported out of the source, and re-add them to the output after conversion (e.g. folded into an appropriate vhost or include). Drop `ServerTokens Prod` and `<Limit>...</Limit>` entirely — never re-add those.	The AMS-path tool deletes every `conf.d/*.conf` file — `security.conf` included — unconditionally in its first pass, the same rule that removes rows 6/7/9/11/12. There is no surviving file in the tool's output to "strip directives from" by the time phase 5 runs; if the file has real, supported content worth keeping, that decision and the extraction have to happen around the tool run, not after it.	Dispatcher overview

Non-publish tiers (author, health, flush, license-control) — mostly tool-handled

#	Signal	Action	Reason	Adobe reference
13	Author-targeted vhosts (`author_*.vhost`, or any vhost file whose name/content targets the author tier)	Fully tool-handled (auto); confirm via report. The tool deletes any enabled/available vhost file whose name contains `author` automatically (same mechanism as row 14). Check `conversion-report.md` for a WARNING on this file rather than deleting it yourself — a WARNING (instead of a silent removal) means the entry isn't shaped like a standard AMS enabled/available symlink pointer and needs a manual look.	AEMaaCS has no dispatcher in front of author at all — dispatcher configuration is simply ignored on author, so removing author-targeted config is always correct; the only open question is whether the automatic removal actually fired for this particular file.	Author caching
14	Non-publish vhosts/farms — filenames containing `author`, `unhealthy`, `health`, `lc`, or `flush` (e.g. `aem_flush.vhost`, `aem_health.vhost`, `aem_lc.vhost`)	Mostly tool-handled (auto); needs post-tool review for one gap. The keyword-based file deletion is automatic — don't redo it, just confirm via `conversion-report.md` (see row 13). What is not automatic: a CGI `ScriptAlias` (e.g. `ScriptAlias /var/www/cgi-bin/health/`) serving health-check traffic from a vhost that the keyword match didn't catch — a shared/catch-all vhost, or a differently-named file. Hunt for that separately and drop it.	Per the transition guide, all non-publish virtual hosts are removed — AEMaaCS's dispatcher is publish-only. Custom CGI execution has no place on the cloud dispatcher regardless of how it's wired in — and because `ScriptAlias` is itself an otherwise-ordinary, commonly-whitelisted directive, the tool's generic non-whitelisted-directive scan will not flag it even when it's serving CGI. That gap is why this row still needs deliberate review even though the file-level deletion is automatic.	AMS transition guide

Variables and the Cloud Manager hand-off

#	Signal	Action	Reason	Adobe reference
15	`${DISP_ID}` used to set a response header (e.g. an `X-Dispatcher` header in `conf.d/includes/global_header.conf`) and other AMS/`.tmpl`-only `${...}` environment variables	Cross-boundary hand-off. Map each surviving variable to a Cloud Manager environment variable and route it to the migration skill's Branch A (`osgi-cfg-json-cloud-manager.md`); also add it to the tool's own `variablesToReplace` list (see config-generation.md) so the conversion run substitutes it instead of leaving a dangling `${VAR}` in the output.	This is a genuine cross-boundary hand-off, not something Branch E finishes alone — and it is distinct from row 3's tool-handled `DISP_ID` removal. The tool's automatic `DISP_ID` cleanup (row 3) only touches usage inside vhost files (a whole line, or an `<If>` block); a `${DISP_ID}` reference used to set a header value inside a surviving include file like `global_header.conf` is a different file, a different mechanism, and the tool does not touch it at all. Branch E's inventory names the candidates (`cmVarCandidates`) and feeds the substitution into the tool's `config.yaml`; only Branch A's OSGi/Cloud-Manager workflow actually creates the Cloud Manager variable or secret.	AMS transition guide

Tool-handled mechanics (reference only — don't redo these)

Adobe's converter already performs the following as standard, mechanical steps of its own AMS-transition rule set — most of the rows above are cross-referenced into this list, not exceptions from it. This is not a judgment call — do not re-apply these by hand, and don't flag them as residue in phase 5.

#	Signal	Action	Reason	Adobe reference
16	Standard AMS→AEMaaCS transition mechanics already executed automatically by the tool — unconditional early-pass deletes, vhost variable/conditional stripping, non-publish-tier removal, farm renaming, and rule consolidation (see breakdown below)	Fully tool-handled (auto). Confirm it happened (check the tool's own `conversion-report.md` — watch for WARNING entries, which mean a file wasn't shaped as the tool expected and needs a manual look); never redo it by hand.	These are mechanical, deterministic steps straight out of Adobe's own AMS-transition rule set — the tool executes them on every run. Re-applying them manually risks duplicate or conflicting edits, and second-guesses a tool that already got it right.	AMS transition guide

Breakdown of what row 16 covers:

Unconditional folder/file deletes (first pass, content-blind) — the whole conf.modules.d/ directory (row 5); every top-level conf.d/*.conf file, including logformat.conf, autoindex.conf, mod_security.conf, ssl.conf/000_*_ssl.conf, welcome.conf, and security.conf (rows 6, 7, 9, 11, 12 — security.conf still needs pre/post-tool content extraction, see row 10); and the whole conf.d/whitelists/ directory, after stripping its Includes from vhosts (row 4 — any content worth keeping still needs pre-tool relocation).
Vhost variable/conditional removal — strips all usage of DISP_ID, PUBLISH_FORCE_SSL, and PUBLISH_WHITELIST_ENABLED from vhost files, including entire <If>...</If> blocks gated on them (row 3); renames PUBLISH_DOCROOT → ${DOCROOT}.
Non-publish tier removal — deletes farm/vhost files whose names contain author, unhealthy, health, lc, or flush (rows 13, 14). This assumes the standard AMS enabled/available symlink-pointer shape; a non-conforming entry gets a WARNING in the report instead of a silent delete — confirm success, don't just assume it.
Farm renaming — *_farm.any → *.farm (drops the _farm infix, normalizes the extension).
AMS artifact removal — deletes files prefixed ams_*.
Port stripping — removes <VirtualHost> sections not bound to :80 (TLS-only sections go; the edge terminates TLS).
Rule consolidation — collapses customer rewrite/filter/cache/clientheader rule files down to Adobe's canonical single file per concern (rewrite.rules, filters.any, rules.any, clientheaders.any), repointing includes to match. Rewrite/redirect rules the tool keeps on the dispatcher are consolidated this way — content survives, only the file layout changes. This is not a blanket guarantee that every redirect carries over: on AEMaaCS, TLS/host redirects and large vanity-URL / redirect maps commonly belong at the CDN edge, not the dispatcher (see CDN candidates below and the rewrite-drop warning in output-verification.md). Read a large source→output rewrite drop as consolidation + an expected CDN move and confirm against the tool's conversion-report.md — don't assume either total preservation or total loss.

CDN candidates: flagged, not authored

A few of the constructs above — force-SSL redirection (row 3, auto-removed by the tool), some redirect rules, security-header directives — look like they belong in the CDN configuration once gone from the dispatcher. Branch E only flags these as CDN candidates for the user; it does not author CDN configuration. Authoring CDN-side config is out of scope for this branch: say what was removed and why it might need a CDN-side equivalent, then stop.