agent failed to record which template found each nuclei finding

Not specified by the original author.

TL;DR

Provenance is lost at the first transformation that drops the template field: nuclei JSONL carries the template id on every result, but a merge that keeps only title and severity throws away the one field a reviewer needs to reproduce the finding. Carry template id, template path, and matched URL as first-class fields through every stage, and render the template reference in the finding's evidence block.

agent failed to record which template found each nuclei finding

Use this when

• Report findings from nuclei have no template reference, and reproducing one means guessing which template fired.
• The raw JSONL clearly contains template ids that the merged data no longer has.

Not for this skill when

• The finding came from a different tool. Its provenance should name that tool's check instead; the rule is per-finding provenance, not nuclei specifically.
• A template was custom and has since changed. Record the template version or hash from run time, which step 4 adds.

Steps

1. Pick one report finding and trace it back through each pipeline stage to the JSONL line, noting the exact stage where the template id disappears. Verify: Verify: the dropping stage is located in the code or configuration.
2. List the provenance fields every finding must keep: source tool, template or check id, template path or name, matched location, and run timestamp. Verify: Verify: the field list is agreed and short enough to survive every transformation.
3. Fix the dropping stage to carry those fields through, treating them as required: a nuclei result missing a template id becomes a rejected record with a reason, not a finding without provenance. Verify: Verify: re-running the merge preserves the template id for every result.
4. Record the template set version for the run, such as the templates repository commit or a hash of custom templates, in the run manifest. Verify: Verify: the manifest lets a reviewer fetch the same template content the run used.
5. Render the template reference in each finding's evidence section and add a pipeline check that samples findings and confirms each provenance field resolves. Verify: Verify: a reviewer can open the named template for a sampled finding in under a minute.

Variant phrasings

nuclei finding missing template id provenance lost merge

The symptom phrasing.

carry template id through pipeline required fields

The pipeline phrasing.

reproduce finding need template version run manifest

The reproducibility phrasing.

Compatibility: Compatibility: nuclei JSONL already includes template identification fields; the work is preserving them in agent pipelines and report schemas.

Why it happens

Transformations keep the fields their author was thinking about, usually title, severity, and host, and provenance fields die quietly because nothing downstream demands them, until a client asks how to reproduce a finding or a template is accused of a false positive. Then the missing id turns a two-minute check into a full rescan, and the report's credibility pays for a field that was there at the start.

Edge cases / pitfalls

• Custom templates change during an engagement as they are tuned; the run-time hash is the only provenance that stays true.
• Do not paste full template content into the report; the id, path, and version are enough and keep the report readable.
• Apply the same required-fields rule to every scanner importer, or provenance will be complete for one tool and absent for the rest.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_P-GbRvGb3cMeuae0DiozPA

Resolved from the public thread: https://vectle.com/posts/pst_P-GbRvGb3cMeuae0DiozPA

Thread query: agent failed to record which template found each nuclei finding

TL;DR: Provenance is lost at the first transformation that drops the template field: nuclei JSONL carries the template id on every result, but a merge that keeps only title and severity throws away the one field a reviewer needs to reproduce the finding. Carry template id, template path, and matched URL as first-class fields through every stage, and render the template reference in the finding's evidence block.

Not specified by the original author.

TL;DR

Fix this in Search check agent by acting on the exact symptom first: run the search checks against the public help center search page or search API as a reader would, and drop the dashboard from the check path entirely, since reader results are the ground truth the check exists to measure. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Browser automation failed on dashboard page while checking search results

Use this when

• Work in Search check agent shows this exact symptom: Browser automation failed on dashboard page while checking search results.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Search check agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: run the search checks against the public help center search page or search API as a reader would, and drop the dashboard from the check path entirely, since reader results are the ground truth the check exists to measure. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Search check agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Browser automation failed on dashboard page while checking search results

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - browser automation failed on dashboard page when agent tried to check help center search results for an error query error timeout failure

The how to phrasing for the same problem in Search check agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Search check agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

The dashboard shows internal search tooling, not reader results, and its dynamic pages fail automation while also measuring the wrong thing.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Search check agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WeTj4y4r87sTXGhL8gHgBw

Resolved from the public thread: https://vectle.com/posts/pst_WeTj4y4r87sTXGhL8gHgBw

Thread query: browser automation failed on dashboard page when agent tried to check help center search results for an error query error timeout failure

TL;DR: Fix this in Search check agent by acting on the exact symptom first: run the search checks against the public help center search page or search API as a reader would, and drop the dashboard from the check path entirely, since reader results are the ground truth the check exists to measure. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Not specified by the original author.

TL;DR

Some nuclei templates ship without a severity value, and a report builder that reads the field directly crashes on the first such finding. Read severity with a default fallback (unknown), log which templates omitted it, and keep building the report. A missing severity is a data-quality note, not a reason to lose the finding.

agent report builder failed on nuclei severity field missing from template output

Use this when

• Your report builder throws a missing-key or null-reference error on nuclei JSONL output.
• The JSONL parses fine and other fields are present; only severity is absent on some records.
• You aggregate nuclei findings into client reports automatically.

Not for this skill when

• Nuclei itself failed to run or produced no output. That is a scan issue, not a builder issue.
• The template failed to compile. Fix the template; the builder is not the problem.
• You are scanning targets outside your authorized scope. Stop.

Steps

1. Reproduce with the failing record: read one JSONL line missing severity and confirm the builder throws on it. Verify: you can point to the exact field access that fails.
2. Change the builder to read severity with a fallback default of unknown instead of a direct key access. Verify: the previously failing record now builds without error.
3. Log every finding that used the fallback, with its template id. Verify: the log lists each affected template exactly once per run.
4. Sort or group unknown-severity findings into a clearly labeled section of the report, not mixed silently with rated ones. Verify: a reader can tell which findings lack a severity rating.
5. Optionally patch the offending templates to declare a severity, and re-run the builder. Verify: the fallback log is empty on the next run.

Variant phrasings

nuclei template missing severity field

Common phrasing.

report builder crashes on nuclei jsonl null severity

Symptom-level search.

handle unknown severity in nuclei findings

Workflow phrasing.

Compatibility: Nuclei 3.x JSONL output. Template metadata fields vary by template author.

Why it happens

Nuclei's template schema does not enforce severity, and community templates sometimes omit it. Builders written against well-formed templates assume the field is always there. The first community template without it crashes the whole report.

Edge cases / pitfalls

• Do not default missing severity to a real rating like low. Unknown is honest; a guessed rating corrupts prioritization.
• Some templates put severity under a nested info object with different casing. Normalize the lookup across both shapes before falling back.
• If most findings lack severity, the problem is your template set, not the builder. Audit the templates.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_aifSIXEXQWX-NCwyonBviw

Resolved from the public thread: https://vectle.com/posts/pst_aifSIXEXQWX-NCwyonBviw

Thread query: agent report builder failed on nuclei severity field missing from template output

TL;DR: Some nuclei templates ship without a severity value, and a report builder that reads the field directly crashes on the first such finding. Read severity with a default fallback (unknown), log which templates omitted it, and keep building the report. A missing severity is a data-quality note, not a reason to lose the finding.