Wiki — write 'Forking the playbook' guide for SOC analysts

[Juwon1405]

Goal

The dart-playbook wiki page documents v2 well, but SOC analysts who
want to fork v2 for their environment need a step-by-step guide.

Proposed content

Forking-the-playbook (Wiki page)
================================

1. When to fork
   - Your case class is not covered by v2
   - Your environment has unique contradiction patterns
   - Your team has specific TTPs they want prioritized

2. Step-by-step
   - cp senior-analyst-v2.yaml my-team-v1.yaml
   - Update target_case_classes
   - Review every next_call_decisions rule for relevance
   - Add team-specific contradiction_triggers
   - Test in deterministic mode first (no API key needed)
   - Promote to live mode only after deterministic passes

3. What you cannot change (architectural guarantees)
   - The MCP function surface (60 functions: 35 native + 25 SIFT adapters, no expansion)
   - The audit chain requirement
   - The contradiction enforcement
   - The path safety boundary
   - The serializer's audit_id citation requirement

4. Real-world fork examples
   - Healthcare: HIPAA-conscious additions
   - Financial: PCI-DSS additions
   - Critical infrastructure: ICS/OT additions

Acceptance

• New wiki page Forking-the-playbook created
• Linked from sidebar under Project section
• Linked from dart-playbook wiki page
• At least 2 worked fork examples

[Tanayqq]

"Hi! I'd like to work on this. I'll study the existing dart-playbook wiki and the v2 YAML before drafting the page. I'll open a draft for feedback before finalizing."

[Juwon1405]

Thanks @Tanayqq, and apologies for the slow reply — and for the mixed signal you walked into here.

You'll see this issue carries a post-sans label alongside good-first-issue. The post-sans flag means I'm intentionally deferring the work until after the SANS FIND EVIL! 2026 deadline (June 15) — this wiki page documents an architectural guarantee that's part of the competition submission, so I need to keep the wiki content single-authored through judging for IP cleanliness. Having both labels on at once was my mistake; that's a contradictory signal and I shouldn't have left it that way.

I'm taking the good-first-issue label off this issue (and the four others in the same state — #4, #30, #35, #38) so contributors aren't sent into the same trap. After June 15 I'll re-add the label and ping back here — if you're still interested at that point, I'd genuinely welcome the contribution.

Thanks for the well-formed comment and for offering to draft for feedback first; that's the right way to approach a contribution. Sorry for the friction in the meantime.

[Tanayqq]

I've drafted the Forking-the-playbook wiki page on my fork here: https://github.com/Tanayqq/agentic-dart/wiki/Forking-the-playbook
It covers all 4 sections — when to fork, step-by-step guide, architectural constraints, and two worked examples (Healthcare/HIPAA and Financial/PCI-DSS). Could you assign this to me and let me know how you'd like me to submit it to the main wiki?

[Juwon1405]

@Tanayqq — thank you for putting that much work into the draft. I genuinely appreciate the effort, and the HIPAA and PCI-DSS worked examples are exactly the kind of domain-specific framing this page needs. That's substantive thinking, not boilerplate.

That said, I have to hold the line on what I said in the previous comment, and I want to be specific about why so the path forward is clear:

Why I can't accept it now (or even start review)

This project is an active SANS FIND EVIL! 2026 submission. Hackathon Rule §8 requires the submission to be "solely owned by [the entrant] with no other person or entity having any right or interest in it." A wiki page of this size and originality (~200 lines, two original worked domain examples) is well above the de minimis threshold under copyright — it would create a real co-authorship claim on documentation that ships with the submission. The earlier 1-line CI PR (#42) was below that threshold; a substantive wiki page is not.

I also can't start review-and-feedback before June 15. "Reviewed-by" / "co-authored-by" attribution still creates an entanglement on the submission while judging is open (Submission window: through 2026-06-15; Judging: 2026-06-19 to 2026-07-03). I have to keep all wiki content single-authored through that window.

This is not a quality issue. The draft is good — better than I'd expect from a first contribution.

What I'm committing to

• I will not read your draft, fork your wiki, or apply any of its content before 2026-06-19 (post-judging window). I want to be able to honestly say "no external content was reviewed during the submission window."
• On 2026-06-19 (judging window opens, IP-clean date), I will:
  1. Re-add good-first-issue to this issue
  2. Ping you here with a @Tanayqq mention
  3. Ask you to open a PR against the wiki repo (Juwon1405/agentic-dart.wiki) with the page
  4. Review it on its merits and merge with a Co-authored-by: Tanayqq trailer crediting you in the git log
• If by then the page has drifted out of date (the wiki currently uses senior-analyst-v3.yaml as the default, not v2 as your draft references; MCP surface is 60 tools = 35 native + 25 SIFT adapters, not 35), I'll point out the diffs in the PR review rather than rewriting it for you.

What not to do in the meantime

• Please do not open a PR against the main repo or the wiki repo before 2026-06-19. I would have to close it without reading it, and that's a worse outcome for both of us than waiting.
• Please do not assign yourself to this issue (and I won't be assigning it). An assignee on an open issue in this repo during the judging window is one more thing a judge might ask about.
• Keep the draft on your fork's wiki — that's the right place for it for now.

Updated CONTRIBUTING.md

I just merged a competition-period contribution policy (commit 106826c) that codifies all of the above. After 2026-06-15 the policy reverts to standard OSS, this issue gets re-labeled good-first-issue again, and your draft is exactly the kind of contribution I want to land first.

Holding the line on this is not about your work — it's about the IP cleanliness obligation I signed up to when I entered the hackathon. I hope you'll come back on June 19. Genuinely.

— Juwon

[Tanayqq]

Understood, thanks for the detailed explanation. I appreciate the transparency. I'll keep the draft on my fork and revisit this after June 19. Best of luck with the competition.