Audit — Stack Detection

When to use

• The user asks to analyze a project or codebase (analyze this repo, проанализируй проект, определи стек) before any findings can be gathered.
• The repository appears to mix frameworks (Laravel plus legacy Bitrix, Symfony plus raw PHP) and the audit must detect every framework present, not just the primary one.
• The user points at an existing PHP project or codebase and the audit must first discover which PHP version, framework(s), and Bitrix modules are in play.

When NOT to use

• Do not run stack detection when the user asks to fix one specific known bug or feature; jump straight to that file instead of surveying the whole stack.
• Skip detection when a fresh, trusted stack profile already exists; reuse it and proceed to the domain scans rather than re-running reconnaissance.

Core guidance

• Enumerate Bitrix modules and edition from bitrix/modules — For a Bitrix project, list the installed modules under bitrix/modules/ and read bitrix/modules/main/classes/general/version.php for the edition and version so legacy-versus-D7 findings are attributed to the right module.
• Read CI config, Dockerfiles, and .env for the runtime picture — Parse the CI workflow, Dockerfile/docker-compose.yml, and .env/.env.example to learn the real runtime PHP version, test matrix, extensions, and services, then reconcile them against the composer constraint.
• Read composer.json and composer.lock before guessing — Start from composer.json (declared PHP constraint, framework requires) and composer.lock (the resolved, installed versions) — the lock file is the source of truth for what actually runs, so trust it over the loose constraint.
• Identify each framework from its marker package and layout — Map marker packages to frameworks — laravel/framework means Laravel, symfony/framework-bundle means Symfony, bitrix/* or a bitrix/ directory means Bitrix — and record every framework found, not only the largest.

Decision Engine

Walk this section before choosing an implementation path.

What signal is available first — a committed composer.lock, only a loose
composer.json, or a framework directory with no composer at all?

├── composer.json only, no lock: → runtime-confirmed profile — treat the composer.json range as a hint, then confirm
the real version from the CI workflow and Dockerfile before emitting the profile.

├── composer.lock committed: → lock-based profile — read resolved versions from composer.lock, cross-check the
CI matrix, and emit a high-confidence stack-profile artifact.

└── No composer, framework tree only: → fingerprint profile — detect Bitrix from bitrix/modules and version.php, or legacy
PHP from directory layout, and emit a lower-confidence stack-profile flagged as such.

Full engine: references/decision-engine.md — Decision Tree, Priority Matrix, Decision Table.

Workflows

Workflow: Detect Stack

Progress:
- [ ] Open composer.json for the declared PHP constraint and requires, then open
composer.lock and record the resolved php version plus every framework package
- [ ] Read the CI workflow, Dockerfile, and .env to confirm the runtime version and
services, and for Bitrix list bitrix/modules and read version.php for the edition
- [ ] Compare the declared constraint, the resolved lock, and the runtime; every mismatch
becomes an audit finding with evidence pointers for each side of the gap

1. Open composer.json for the declared PHP constraint and requires, then open composer.lock and record the resolved php version plus every framework package.
   • Verify: You have a resolved PHP version and a list of framework packages with lock line numbers.
2. Read the CI workflow, Dockerfile, and .env to confirm the runtime version and services, and for Bitrix list bitrix/modules and read version.php for the edition.
   • Verify: The runtime version is reconciled with the lock and any Bitrix modules are listed.
3. Compare the declared constraint, the resolved lock, and the runtime; every mismatch becomes an audit finding with evidence pointers for each side of the gap.
   • Verify: Each version or framework drift you noticed has a finding with two evidence pointers.

Workflow: Handoff Profile

Progress:
- [ ] Collect the resolved php version, frameworks, Bitrix modules, CI matrix, and
services into one structured profile, attaching a `path:line` pointer to each field
- [ ] Stamp the profile with a confidence level based on its evidence source (lock is
high, CI is medium, fingerprint is low) and emit it as the stack-detected artifact
the domain scans consume

1. Collect the resolved php version, frameworks, Bitrix modules, CI matrix, and services into one structured profile, attaching a path:line pointer to each field.
   • Verify: The profile is one structured object where every field carries an evidence pointer.
2. Stamp the profile with a confidence level based on its evidence source (lock is high, CI is medium, fingerprint is low) and emit it as the stack-detected artifact the domain scans consume.
   • Verify: The emitted profile states its confidence and is consumed by project-analysis.

Best practices

• Produce a stack-detected profile — php version, frameworks with versions, Bitrix modules, CI matrix, key services — each field annotated with the evidence path (path:line) it came from, so the domain scans consume facts, not guesses
• Every detected fact must cite the file and line it came from (for example composer.lock:812); a claim with no evidence pointer is dropped, not recorded

Anti-patterns

See references/anti-patterns.md.

Debugging

1. Recording stack facts with no evidence pointer — Unsourced facts cannot be verified and quietly corrupt every finding built on them. Fix: Attach a path:line evidence pointer to every field; drop any fact you cannot cite rather than guessing it into the profile.
2. Stopping at the first framework found — The unaudited minority stack is usually where the oldest, riskiest code hides. Fix: Scan for every framework marker (packages and directories) and record each stack found before starting the domain scans.
3. Trusting the composer.json range as the real version — Every version-specific finding is then wrong — flagging fixed issues or missing real ones. Fix: Read the resolved version from composer.lock and the CI matrix; use the constraint only as a fallback hint when no lock or CI exists.

Production checklist

• All frameworks are listed, including secondary or legacy stacks, each with its own evidence pointer.
• The profile states a confidence level so downstream scans know whether facts came from a lock, from CI, or from a fingerprint guess.
• Each field in the stack profile carries a path or path-and-line evidence pointer to the file it came from.
• The PHP and framework versions in the profile are read from composer.lock, not the loose composer.json range.
• The CI and Docker runtime versions are reconciled with the composer constraint and any drift is flagged.

Version notes

• composer.lock and PHP platform config — composer.lock records platform-overrides and a content-hash; when a config.platform.php override is set, resolved versions may differ from the host PHP, so read the override before trusting the runtime for version-specific findings.

Security

• Not applicable — no I/O, auth, or untrusted input.

Testing

• Activation and decision behavior are verified in eval/scenarios/audit/stack-detection.yaml.

Additional resources

• references/anti-patterns.md
• references/core.md
• references/decision-engine.md
• references/examples.md
• references/pitfalls.md
• references/recipes.md
• references/version-differences.md

Knowledge graph

Related: audit/project-analysis

Skill contract

Produces: audit.stack-detected
Risk: low · Confidence: 0.9