fix(ci): make shannon-scan workflow resilient to tool install failures

[Copilot]

The gau Go module fails to install in CI due to authentication issues, causing the entire workflow to abort and leaving ./results uncreated — which then cascades into SARIF write and upload failures.

Changes

• Resilient tool installation: Added continue-on-error: true to the "Install reconnaissance tools" step and appended || true to each go install command so bash's -e mode doesn't short-circuit remaining tool installs when one fails

- name: Install reconnaissance tools
  continue-on-error: true
  run: |
    go install github.com/tomnomnom/gau/v2/cmd/gau@latest || true
    go install github.com/projectdiscovery/katana/cmd/katana@latest || true
    go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest || true

• Guaranteed results directory: Added mkdir -p results at the top of the "Generate SARIF Report" step (already if: always()) so the SARIF write never hits ENOENT when upstream steps fail

Original prompt

Problem

The Shannon Security Scan workflow (.github/workflows/shannon-scan.yml) is failing with cascading errors. See the failing run: https://github.com/Steake/shannon-uncontained/actions/runs/23126056183/job/67169218331

Error 1 (Root Cause): gau Go module installation fails

In the "Install reconnaissance tools" step (line 71-80), go install github.com/tomnomnom/gau/v2/cmd/gau@latest fails with:

fatal: could not read Username for 'https://github.com': terminal prompts disabled

The Go module's upstream repository has authentication issues (likely moved or requires auth), causing the step to exit with code 1.

Error 2: SARIF file write fails with ENOENT

The "Generate SARIF Report" step (line 96-122) runs with if: always() but tries to write to ./results/shannon-results.sarif. Since earlier steps failed, the ./results directory was never created (the mkdir -p results on line 92 is in the "Run LSG Reconnaissance" step which also failed). This causes:

Error: ENOENT: no such file or directory, open './results/shannon-results.sarif'

Error 3: SARIF upload fails

The "Upload SARIF to GitHub Security" step fails because the SARIF file was never created:

Path does not exist: ./results/shannon-results.sarif

Required Fixes

Fix 1: Make reconnaissance tool installation resilient

Add continue-on-error: true to the "Install reconnaissance tools" step so that a single tool failure (like gau) doesn't break the entire workflow. Additionally, install each Go tool individually with || true so one failing tool doesn't prevent the others from installing:

- name: Install reconnaissance tools
  continue-on-error: true
  run: |
    # Install Go tools (continue even if individual tools fail)
    go install github.com/tomnomnom/gau/v2/cmd/gau@latest || true
    go install github.com/projectdiscovery/katana/cmd/katana@latest || true
    go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest || true
    echo "$HOME/go/bin" >> $GITHUB_PATH
    
    # Install system tools
    sudo apt-get update
    sudo apt-get install -y nmap whatweb

Fix 2: Ensure ./results directory exists before SARIF generation

Add mkdir -p results at the beginning of the "Generate SARIF Report" step so it works even when previous steps fail:

- name: Generate SARIF Report
  if: always()
  run: |
    mkdir -p results
    node -e "
      const fs = require('fs');
      ...
    "

Both fixes should be applied to the file .github/workflows/shannon-scan.yml.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Investigate and fix

Assistant:

I'll start by investigating the failing job to understand what went wrong.

Assistant: Let me look at the workflow file to understand the full configuration:

Assistant: Here's my investigation of the failing Shannon Security Scan workflow run.

---

Root Cause Analysis

There are 3 cascading errors, all stemming from a single root cause:

1. ❌ go install github.com/tomnomnom/gau/v2/cmd/gau@latest fails (Root Cause)

Step: "Install reconnaissance tools" (line 71–80)

fatal: could not read Username for 'https://github.com': terminal prompts disabled

The Go module gau is trying to access a private or moved Git repository, and the runner can't authenticate interactively. This causes the step to exit with code 1.

2. ❌ writeFileSync → ENOENT: no such file or directory, open './results/shannon-results.sarif'

Step: "Generate SARIF Report" (line 96–122)

Because the previous "Run LSG Reconnaissance" step also failed (it depends on the recon tools), the mkdir -p results on line 92 likely never executed. The node -e script on line 99 tries to write to ./results/shannon-results.sarif, but the ./results directory doesn't exist.

3. ❌ Path does not exist: ./results/shannon-results.sarif

Step: "Upload SARIF to GitHub Security" (line 124–128)

Since the SARIF file was never created, the CodeQL upload also fails.

---

Fixes Needed

There are two issues to address in .github/workflows/shannon-scan.yml:

Fix 1: gau installation failure

The gau Go module's upstream repo appears to have authentication issues (possibly moved or requires auth). Options:

• Pin to a known working version instead of @latest (e.g., @v2.2.3).
• Add continue-on-error: true to the recon tools step so a single tool failure doesn't break the entire workflow.
• Remove gau if it's not essential, or install it via a pre-built binary release instead of go install.

Fix 2: Ensure ./results directory exists before SARIF generation

The "Generate SARIF Report" step runs with if: always() but depends on the ./results directory being created. Add `mkdir -p re...

This pull request was created from Copilot chat.

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[Steake]

@copilot
You are working on PR KeygraphHQ#65 in BraveNewCapital/GodelOS_StrangeDevLoop.

Read first and treat as authoritative:

• docs/architecture/GODELOS_ARCHITECTURAL_CHARTER.md
• docs/architecture/GODELOS_REPO_IMPLEMENTATION_CHARTER.md
• docs/repo_architect/OPERATOR_GUIDE.md
• repo_architect.py
• .github/workflows/repo-architect.yml
• .github/workflows/repo-architect-execution.yml
• .github/workflows/repo-architect-reconcile.yml

Your task is to harden the closed-loop repo-architect execution system so it is operationally trustworthy rather than merely plausible.

Do not stop at analysis.
Do not leave TODOs where concrete implementation is possible.
Do not weaken the issue-first model.
Make targeted repo changes now.

Current weak points to fix

1. Copilot delegation may be ceremonial rather than a real trigger.
   The current live path appears to add in-progress, assign @copilot+claude-opus-4.6, and post a delegation comment.
   You must make delegation explicit, observable, and verifiable.

2. PR reconciliation is too brittle.
   The current matching appears to rely on #issue_number references in PR text.
   You must implement stronger issue-to-PR linkage.

3. Lifecycle semantics are too interpretive.
   The current mapping of:

• PR closed/unmerged -> superseded
• stale/no PR -> blocked
  is not reliably true.
  You must replace these with factual states.

Required implementation changes

A. Make delegation verifiable

Implement delegation so the system can prove what happened.

Required behavior:

• record a delegation event in work state with timestamp, mechanism, target issue, and outcome
• distinguish:
  • delegation_requested
  • delegation_confirmed
  • delegation_failed
• if the repository’s actual supported trigger is assignment to Copilot, keep that path but record explicit confirmation of the API response
• if a comment trigger is used, record the exact comment URL/id returned by GitHub
• if both assignment and comment are used, record both separately
• if there is no reliable trigger confirmation, mark the delegation state as unconfirmed rather than pretending execution has started

Do not treat “label added” alone as proof of actual execution.

Update docs and tests accordingly.

B. Strengthen issue-to-PR linkage

Implement stronger PR association than plain #issue_number text matching.

Use as many reliable signals as are available and practical, in priority order:

1. explicit issue fingerprint in PR body
2. explicit machine marker or metadata block in PR body
3. branch naming convention linked to issue/fingerprint
4. closing keywords / linked issue references
5. fallback text mention of #issue_number

When repo-architect delegates an issue, ensure the issue body/comment includes the machine-readable linkage material Copilot should carry into the PR.

When reconciling, prefer exact machine linkage over loose textual inference.

Update tests for:

• exact fingerprint match
• branch-name-only match
• fallback issue-number match
• ambiguous/multiple PR cases
• no-match case

C. Replace interpretive lifecycle states with factual states

Do not encode assumptions as labels or state names.

Replace or refactor lifecycle/state handling so facts are represented directly, for example:

• ready-for-delegation
• delegation-requested
• in-progress
• pr-open
• pr-draft
• merged
• closed-unmerged
• stale
• blocked-by-dependency
• superseded-by-issue
• superseded-by-pr
• failed-delegation

The exact naming can differ, but it must separate:

• objective facts
  from
• inferred planning meaning

Do not label a closed unmerged PR as superseded unless there is explicit evidence of a superseding issue/PR.
Do not label stale as blocked unless there is explicit blocking evidence.

Planning may infer that stale work should be deprioritized, but the stored state must remain factual.

D. Tighten reconciliation rules

Update reconcile_pr_state() so it:

• records why a PR was matched
• records the evidence type used for the match
• records whether the match confidence is exact / strong / weak
• avoids silently overwriting a stronger match with a weaker one
• handles multiple PRs referencing the same issue
• handles reopened PRs or reopened issues if practical

Persist reconciliation evidence in work state.

E. Update work state schema

Extend .agent/work_state.json and any in-memory models to include:

• delegation_mechanism
• delegation_requested_at
• delegation_confirmed_at
• delegation_confirmation_evidence
• delegation_comment_url or id if applicable
• delegation_assignment_evidence if applicable
• pr_match_method
• pr_match_confidence
• pr_match_evidence
• lifecycle_fact_state
• lifecycle_inferred_state if needed separately

Keep the schema machine-readable and documented.

F. Update operator docs

Document:

• what counts as confirmed delegation
• what counts as PR linkage evidence
• factual lifecycle states versus inferred planning interpretations
• how reconciliation decides match strength
• how to inspect work state for proof of delegation and PR association

G. Update tests

Add or update hermetic tests for:

• delegation requested vs confirmed vs failed
• reconciliation by fingerprint marker
• reconciliation by explicit linkage block
• fallback reconciliation by issue number
• ambiguous multiple PR references
• factual lifecycle state transitions
• no false superseded on closed-unmerged PR
• no false blocked on mere staleness

Constraints

• Preserve issue-first planning as default
• Do not reintroduce autonomous code mutation
• Prefer targeted changes over broad rewrites
• Keep the loop auditable
• Keep scheduling/concurrency behavior intact unless a change is required to support the stronger execution contract

Success condition

This task is complete only when:

• delegation has explicit, machine-readable proof rather than optimistic assumption
• PR reconciliation is stronger than naive #issue_number matching
• lifecycle states represent facts, not stories
• work state records enough evidence for later planning and debugging
• docs and tests reflect the new contract

When done, output a concise summary with these headings:

• Delegation hardening
• PR linkage hardening
• Lifecycle/state changes
• Work state schema changes
• Workflow/doc changes
• Test changes
• Remaining limitations

[Copilot]

@copilot
You are working on PR KeygraphHQ#65 in BraveNewCapital/GodelOS_StrangeDevLoop.

...

This request is for PR KeygraphHQ#65 in BraveNewCapital/GodelOS_StrangeDevLoop, which is a different repository. I'm scoped to this PR in Steake/shannon-uncontained and cannot make changes to other repositories. Please open this request directly on that PR or repo instead.