Connect Stele to secure-pride: fix stale project entry, add scenario …

[mazze93]

…corpus

The secure-pride project entry described a superseded 802.1x/MDM conception (Python/FreeRADIUS/step-ca/Mosyle/UniFi/Swift MacProbe) with zero matches anywhere in the current mazze93/secure-pride repo — verified via grep before touching it. Corrected stack, hard stops, root path (was ~/dev/secure-pride, actually ~/Projects/secure-pride/secure-pride), and open questions to match what the project actually is now: an Astro/Cloudflare site with a Rust/WASM AI Safety Scanner, published to GHCR. Hard stops updated from network/MDM-specific items to the ones that actually apply: credential handling, container publishing, scan-output masking.

Added four scenario-shaped cases to evals/corpus.ts under secure-pride/*, one per TOBIRA category, built around this session's own work rather than generic phrasing: a leaked GITHUB_TOKEN pasted inside a CI debugging log (APOCRYPHA), an incident-pressure request to skip the Trivy vulnerability gate (KAPU-OVERRIDE), a false "security team pre-authorized this" claim to skip review on a MAX-posture change (NARIKIRI-ADMIN), and a hidden HTML-comment instruction to suppress a finding in a scan report (PALIMPSEST). All four verified firing on exactly their expected TOBIRA with zero collateral, via a direct scanPasteInput() call — output captured for the case study.

pnpm test: 68/68 passing (unchanged). pnpm build: clean (tsc -b + vite).

Claude-Session: https://claude.ai/code/session_01MSmuvkMSicpAdpwPotKm5M

What

Integrity

• Group: 1 / 2 / 3 / 4 / 5
• Tesserae resolved: T-xxx / none
• Tesserae opened: T-xxx / none

Test

• npx tsc --noEmit passes
• Dev server starts clean

Confidence Score: 4/5

The change has no blocking issue, but Secure Pride’s generated guidance contains a mislabeled status note and emits an avoidable warning.

Findings

1.  Misclassified open question ▶

Fix with agent prompt

### Issue 1
src/data/projects.ts:23
This entry is an implementation-status statement rather than an unresolved question. Secure Pride guidance includes it under Open Questions and emits a warning on each `claude-md-project` compilation, creating noisy output and misleading contributors about work that still needs a decision. This is non-blocking because compilation completes, but the metadata should use a real question or a status-appropriate field.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

• Secure Pride’s openQuestions metadata contains an implementation-status note rather than an unresolved decision.
• Compiling the project guidance includes that note under Open Questions and emits a recurring hygiene warning, although the output is still generated successfully.

Merge safety

This change is safe to merge with respect to blocking risks. The remaining metadata concern is non-blocking, but should be corrected to keep generated project guidance accurate and quiet.

_{Reviews (1) · Last reviewed commit: "Connect Stele to secure-pride: fix stale..."}

[greptile-apps]

Misclassified open question

This entry is an implementation-status statement rather than an unresolved question. Secure Pride guidance includes it under Open Questions and emits a warning on each claude-md-project compilation, creating noisy output and misleading contributors about work that still needs a decision. This is non-blocking because compilation completes, but the metadata should use a real question or a status-appropriate field.

Artifacts

Evidence from the check

• Vitest script invokes the real compiler for the Secure Pride claude-md-project target and records the exact source value, diagnostics, and compiled inclusion; it demonstrates the targeted behavior.

Command output from the check

• Captured Vitest output for the unchanged repository value shows one question-hygiene warning, inclusion in the compiled output, and a successful exit code; the behavior is a warning rather than a failure.

Command output from the check

• Captured Vitest output for an in-memory genuine-question control shows zero question-hygiene warnings and successful compilation; question-shaped content avoids the warning.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/data/projects.ts
Line: 23

Comment:
**Misclassified open question**

This entry is an implementation-status statement rather than an unresolved question. Secure Pride guidance includes it under Open Questions and emits a warning on each `claude-md-project` compilation, creating noisy output and misleading contributors about work that still needs a decision. This is non-blocking because compilation completes, but the metadata should use a real question or a status-appropriate field.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Comments Outside Diff

These findings sit on lines the diff does not cover, so they could not be posted inline. Each one leaves this list once its file changes.

•  Secure Pride implementation-status note is stored as an open question ▶

  • Bug
    • The value at src/data/projects.ts:23 is a status statement about a manually synchronized token mirror and a pending automated bridge. In the claude-md-project compile path it matches neither a trailing ? nor the accepted decision-language pattern, so the compiler emits the open-question hygiene warning while still including it under OPEN QUESTIONS.
  • Cause
    • An implementation-status note was placed in the openQuestions project field, whose compile-time hygiene rule expects a genuine question or specified decision language.
  • Fix
    • Replace the value with a concrete decision question, or move the implementation-status note to an appropriate narrative/status field. Do not treat this warning as a compile failure unless the compiler behavior is intentionally changed.