Support and Issue Reporting

Support and Issue Reporting

Language: English · 简体中文

A useful LWC issue states what was expected, what canonical state actually contains, which derived capability disagrees, and whether recovery is safe. Remove secrets and customer data before sharing any evidence.

Choose the right channel

Need	Channel
Reproducible defect	GitHub Issues
Documentation correction	GitHub issue naming the Wiki page and exact claim
Feature or compatibility request	GitHub issue with the user problem and official host evidence
Sensitive vulnerability	Repository security policy
Upstream MarkItDown, AnyDoc, or Agent-host failure	Confirm the boundary, then report to the responsible upstream project

Do not publish a suspected secret, exploitable path, private Source body, or customer dataset in a public issue.

Diagnose before reporting

Run only against the affected scope:

lwc --version
lwc --scope project config show
lwc --scope project lint --limit 100
lwc --scope project work list
lwc --scope project graph status
lwc --scope project graph verify
lwc --scope project cg status
lwc agent status --target auto --location global

If a command failed, preserve its complete structured error. If it reported canonical partial success, do not repeat the business mutation; follow the returned recovery contract first.

Minimum bug report

Include:

1. a one-sentence expected result;
2. the exact command and scope;
3. LWC version, operating system, architecture, and installation channel;
4. complete error.code and sanitized error.details;
5. whether the command targeted live or --changeset state;
6. canonical readback proving what changed or did not change;
7. Work ID and terminal state, when present;
8. document-graph and CodeGraph readiness reported separately;
9. the smallest reproduction from a clean temporary project;
10. whether cleanup, retry, or rollback is safe.

“It does not work” is not enough. A screenshot can supplement structured output but should not replace copyable JSON and commands.

Reproduction template

### Expected

### Actual

### Environment

- LWC version:
- OS and architecture:
- Install channel:
- Scope and current directory:

### Reproduction

1.
2.
3.

### Structured error and canonical readback

### Recovery and cleanup status

Prefer an isolated project with invented content. If the defect requires an old Store or checkpoint, share the smallest sanitized fixture that still reproduces the same error code.

Redaction rules

Before posting, remove or replace:

• access tokens, cookies, passwords, private keys, and environment values;
• Source and Page bodies not needed to reproduce the defect;
• customer names, emails, identifiers, and private repository paths;
• Agent provider request bodies and hidden reasoning;
• conversion arguments containing credentials;
• complete host configuration when a minimal owned fragment is sufficient.

Keep structural facts that matter: path shape, byte size, file type, scope, error code, version, and ordering. State what was redacted so maintainers do not mistake placeholders for real input.

Agent integration reports

Name the exact target and location, for example codex/global or copilot-vscode/local. Include install, status, and refresh results plus the capability mode that disagrees.

An official user_managed, configured_preview, or unsupported result is not itself a defect. Report a defect when LWC writes an undocumented host surface, misreports support, breaks foreign content, or fails a surface the current official host documentation supports.

Do not submit paths from AMC, a maintainer's private HOME, local plugin caches, or an absolute private lwc binary as public requirements.

Graph and retrieval reports

For document graph defects, attach graph status, graph verify, and the exact node identifiers. For CodeGraph, attach cg status and distinguish runtime installation from project index initialization.

For retrieval defects, provide a minimal Source/Page set, the fixed query, --explain output, expected Page, and ranking requirement. Do not change the query after observing results.

For Word Graph, include the query terms, pagination parameters, returned request_limits, and whether the issue is missing data, excessive density, or rendering.

Feature requests

Describe the job, not only the proposed command. Include:

• who encounters the problem and how often;
• why existing search, tags, graph, changesets, or Agent integration cannot solve it;
• the smallest useful behavior;
• safety, compatibility, and performance boundaries;
• acceptance evidence;
• current official documentation for any external Agent or protocol surface.

Avoid speculative general frameworks. A concrete recurring workflow is stronger evidence than a future flexibility argument.

After a fix

Reproduce with the fixed build, repeat canonical readback, wait for any Work, and run the relevant lint, retrieval, graph, Viewer, or Agent acceptance. Close the issue only when the original failure path—not merely a neighboring unit test—passes.

Start with Troubleshooting and FAQ. Recovery procedures are in Maintenance and diagnostics.