Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.sigilix.ai/llms.txt

Use this file to discover all available pages before exploring further.

This page covers the most frequent failure modes and what to do about them.

​
”No review appears on my PR”

A few things to check, in order:

​
1. Is Sigilix installed on this repo?

Open GitHub App settings → click Configure on Sigilix → confirm the repo is in the selected list. If not, add it and trigger a re-review by pushing an empty commit.

​
2. Did the webhook deliver?

Open the GitHub App webhook log: Settings → Developer settings → GitHub Apps → Sigilix → Advanced → Recent Deliveries. Look for the most recent pull_request event matching your PR number. If it’s red (delivery failed), click Redeliver.

​
3. Is the PR a draft?

Sigilix doesn’t review draft PRs by default. Convert to ready and Sigilix re-reviews automatically.

​
4. Is the file ignored?

If the PR only touches files matching your sigilix.yaml ignore.paths, Sigilix posts no review. Check the Recent Deliveries for a webhook_skipped log entry.

​
5. Did you hit the rate limit?

If your tier’s rate limit is exhausted, Sigilix posts a small “rate limit reached” comment instead of a full review. Check your usage at the dashboard or in any recent review’s footer.

​
6. Is the diff too large?

Sigilix has a 5MB diff cap. PRs with diffs larger than that get a “diff too large to review” comment. Split the PR.

​
”Review posted but a specialist is missing”

If a Sigilix review’s footer says _3 of 4 specialists succeeded._, one specialist failed. This usually means:
  • The specialist’s primary model returned a 5xx (overloaded) and the cross-provider fallback also failed
  • The specialist hit its per-call timeout (60s default)
The review still posts with the available specialists. Sigilix doesn’t retry the missing specialist on the same SHA — push a new commit to trigger a fresh review. If a specific specialist is consistently failing, contact us — there may be a regional outage at the model provider.

​
”Inline anchors are missing — everything is in the body”

This is the anchorless fallback. It happens when GitHub rejects Sigilix’s inline-anchor positions (typical 422 — line numbers don’t match the diff). The verdict is still posted; the findings are rolled into the review body as markdown grouped by file. Look for the footer: 
_Inline anchoring unavailable for this review; findings grouped above._
This is rare — Sigilix’s pre-validation should catch bad positions before submission. If you see it consistently on a particular repo, contact us.

​
”Sigilix re-reviews on every push but my PR has hundreds of pushes”

Each push fires a pull_request.synchronize webhook, but Sigilix coalesces synchronize events: it waits ~30s for additional pushes before starting the review. So a rapid push-fix-push-fix-push sequence costs one review, not multiple. If you push a single commit slowly (one every minute), you’ll burn budget faster. Batch your pushes when possible.

​
”I’m getting 401 Unauthorized when I post a comment”

This is a webhook-signature mismatch. Sigilix verifies the X-Hub-Signature-256 header on every incoming GitHub webhook against GITHUB_WEBHOOK_SECRET. If you’ve rotated the GitHub App’s webhook secret, you need to update the secret on the Sigilix deployment side. Reach out to support@arcanchor.com and we’ll re-sync.

​
”Sigilix is reviewing but my custom rules aren’t firing”

Custom rules are appended to the relevant specialist’s system prompt. Check:
  1. Is sigilix.yaml at the repo root? Sigilix only reads it from the root. Subfolder configs are ignored.
  2. Is the YAML valid? Sigilix logs validation warnings in the review footer. Look for _⚠️ sigilix.yaml validation: ..._.
  3. Is the rule too vague? The model can’t enforce “Code should be readable.” Rewrite to something concrete.
  4. Does the rule scope to the right specialist? A security rule under glyph: won’t fire — security rules go under warden:.
See Custom Rules for guidance on writing effective rules.

​
Still stuck?

Email us at support@arcanchor.com with:
  • Your GitHub org name
  • The PR URL where the issue occurred
  • The expected behavior vs. observed
  • Recent webhook deliveries (screenshot from GitHub App webhook log)
We typically reply within 24 hours during US business days.