Project Platform Diagnose
This overlay can stand alone for environment-only triage. Add matching language
or discipline guidance when the diagnosis reaches source code or a specialized
implementation boundary.
When to use
The problem differs by operating system, architecture, terminal, shell, CI,
container, headless mode, installed runtime, service environment, or another
platform fact.
Not for
Do not use this as primary for a reproducible logic bug (use the matching
principle skill and add project-core-dev only when repository-specific
completion evidence is not concrete), a known config-contract defect
(project-config-and-tests), Playwright harness or browser installation repair
(setup-playwright), vendored dependency ownership (project-vendor-boundary),
or release artifact layout (project-release-maintainer). Start here only while
the environment remains a plausible cause, then hand off when the failure is
isolated.
Diagnostic Workflow
- Inspect the failing command's side effects before rerunning it. Reproduce it
within existing authority, using an isolated or check-only variant when
needed, and capture exit status and relevant output. A failed install,
migration, or deployment is not automatically safe to repeat. Separate build
or install failures from startup and runtime failures.
- Record only relevant non-secret facts: OS, architecture, runtime and tool
versions, shell or terminal mode, local versus CI or container, filesystem
and permission assumptions, and required services. Never dump the full
environment or expose credentials.
- Compare a working and failing environment when both exist. Build the smallest
difference set and change one plausible variable at a time.
- Prefer built-in diagnostics and reproducible smoke checks. Use temporary
directories, disposable containers, or other reversible probes when
available; clean up created state.
- Classify direct observations separately from hypotheses. Distinguish an
environment limitation, missing dependency, install defect, unsupported
platform, config defect, and app regression before recommending a fix.
- Report whether the issue reproduced, the discriminating evidence, remaining
unknowns, and the next smallest probe. Implement a code, config, setup, or
release fix when the request includes repair, using the matching skill and
existing authorization; otherwise report the diagnosis.
Do not make permanent machine changes, install system dependencies, or start
external services or GUI applications merely to test a hypothesis without the
required authorization.
1---2name: project-platform-diagnose3description: Diagnostic project overlay for environment-dependent build, install, startup, CI, container, headless, terminal, or runtime failures. Not for ordinary logic bugs or known release packaging changes.4---56# Project Platform Diagnose78This overlay can stand alone for environment-only triage. Add matching language9or discipline guidance when the diagnosis reaches source code or a specialized10implementation boundary.1112## When to use1314The problem differs by operating system, architecture, terminal, shell, CI,15container, headless mode, installed runtime, service environment, or another16platform fact.1718## Not for1920Do not use this as primary for a reproducible logic bug (use the matching21principle skill and add `project-core-dev` only when repository-specific22completion evidence is not concrete), a known config-contract defect23(`project-config-and-tests`), Playwright harness or browser installation repair24(`setup-playwright`), vendored dependency ownership (`project-vendor-boundary`),25or release artifact layout (`project-release-maintainer`). Start here only while26the environment remains a plausible cause, then hand off when the failure is27isolated.2829## Diagnostic Workflow30311. Inspect the failing command's side effects before rerunning it. Reproduce it32 within existing authority, using an isolated or check-only variant when33 needed, and capture exit status and relevant output. A failed install,34 migration, or deployment is not automatically safe to repeat. Separate build35 or install failures from startup and runtime failures.362. Record only relevant non-secret facts: OS, architecture, runtime and tool37 versions, shell or terminal mode, local versus CI or container, filesystem38 and permission assumptions, and required services. Never dump the full39 environment or expose credentials.403. Compare a working and failing environment when both exist. Build the smallest41 difference set and change one plausible variable at a time.424. Prefer built-in diagnostics and reproducible smoke checks. Use temporary43 directories, disposable containers, or other reversible probes when44 available; clean up created state.455. Classify direct observations separately from hypotheses. Distinguish an46 environment limitation, missing dependency, install defect, unsupported47 platform, config defect, and app regression before recommending a fix.486. Report whether the issue reproduced, the discriminating evidence, remaining49 unknowns, and the next smallest probe. Implement a code, config, setup, or50 release fix when the request includes repair, using the matching skill and51 existing authorization; otherwise report the diagnosis.5253Do not make permanent machine changes, install system dependencies, or start54external services or GUI applications merely to test a hypothesis without the55required authorization.
n-n-code