Co-activation testing, new ways, vocabulary tuning

hooks/ways/softwaredev/architecture/design/way.md

@@ -1,6 +1,6 @@
 ---
 description: software system design architecture patterns database schema component modeling
-vocabulary: architecture pattern database schema modeling interface component modules factory observer strategy monolith microservice domain layer coupling cohesion abstraction singleton
+vocabulary: architecture pattern database schema modeling interface component modules factory observer strategy monolith microservice domain layer coupling cohesion abstraction singleton proposal rfc sketch deliberation whiteboard
 threshold: 2.0
 scope: agent, subagent
 ---
@@ -16,6 +16,14 @@ scope: agent, subagent
 
 When the design involves architectural trade-offs worth documenting, escalate to an ADR (see ADR Way).
 
+## RFCs and Proposals
+
+RFCs are the "before" to an ADR's "after" — they capture deliberation while the design is still open. Use them for changes that affect multiple teams or systems.
+
+- **RFC**: Proposes a change, invites feedback, converges on a decision
+- **ADR**: Records the decision after deliberation is complete
+- Start with a sketch or whiteboard session, formalize as an RFC if the scope warrants it
+
 ## Common Patterns
 
 | Pattern | When to Use | When NOT to Use |

hooks/ways/softwaredev/architecture/threat-modeling/way.md

@@ -0,0 +1,75 @@
+---
+description: threat modeling, STRIDE analysis, trust boundaries, attack surface assessment, security design review
+vocabulary: threat model stride attack surface trust boundary mitigation adversary dread spoofing tampering repudiation elevation
+threshold: 2.0
+scope: agent, subagent
+provenance:
+  policy:
+    - uri: governance/policies/operations.md
+      type: governance-doc
+  controls:
+    - id: OWASP Threat Modeling Cheat Sheet
+      justifications:
+        - STRIDE framework applied at design phase before code review
+        - Trust boundaries identified between components and external systems
+    - id: NIST SP 800-30 (Risk Assessment)
+      justifications:
+        - Risk register documents accepted risks with expiration dates
+        - Likelihood and impact assessed for each identified threat
+  verified: 2026-02-17
+  rationale: >
+    Security Way covers code-level detection (SQL injection, XSS, secrets).
+    Threat modeling operates at design altitude — understanding adversaries,
+    trust boundaries, and systemic risks before they become code bugs.
+---
+# Threat Modeling Way
+
+Threat modeling is security at design altitude. Where the Security Way catches code-level issues (injection, exposed secrets), this way maps adversaries, trust boundaries, and systemic risks.
+
+## When to Threat Model
+
+- New service or component with external-facing surface
+- Authentication/authorization redesign
+- Data flow changes crossing trust boundaries
+- Third-party integration adding new attack vectors
+
+## STRIDE Framework
+
+Analyze each component interaction for:
+
+| Threat | Question | Mitigation Pattern |
+|--------|----------|--------------------|
+| **S**poofing | Can an attacker impersonate a user or service? | Authentication, mutual TLS, signed tokens |
+| **T**ampering | Can data be modified in transit or at rest? | Integrity checks, HMAC, immutable logs |
+| **R**epudiation | Can actions be denied after the fact? | Audit trails, signed events, timestamps |
+| **I**nformation Disclosure | Can sensitive data leak? | Encryption, access controls, data classification |
+| **D**enial of Service | Can availability be degraded? | Rate limiting, circuit breakers, redundancy |
+| **E**levation of Privilege | Can an attacker gain higher access? | Least privilege, role separation, input validation |
+
+## Risk Register
+
+Document accepted risks with expiration — risks don't stay accepted forever.
+
+```markdown
+| Risk | Likelihood | Impact | Mitigation | Status | Expires |
+|------|-----------|--------|------------|--------|---------|
+| API rate limiting absent | Medium | High | Planned for Q2 | Accepted | 2026-06-01 |
+```
+
+Expired accepted risks must be re-evaluated or mitigated.
+
+## Trust Boundaries
+
+Identify where data crosses trust levels:
+- Browser to API gateway (untrusted → semi-trusted)
+- API to internal service (semi-trusted → trusted)
+- Service to third-party API (trusted → external)
+
+Each boundary crossing needs: authentication, input validation, output encoding.
+
+## Relationship to Security Way
+
+- **Threat modeling**: "What could go wrong?" (design phase)
+- **Security Way**: "Is this code safe?" (implementation phase)
+
+Both may fire on security-related prompts. Threat modeling adds the systemic view.

hooks/ways/softwaredev/docs/standards/way.md

@@ -0,0 +1,54 @@
+---
+description: establishing team norms, coding conventions, testing philosophy, dependency policy, accessibility requirements
+vocabulary: convention norm guideline accessibility style guide linting rule agreement philosophy
+threshold: 2.0
+scope: agent, subagent
+---
+# Standards Way
+
+Standards define how a team works. They're distinct from quality metrics (the Quality Way measures adherence) — this way is about establishing and documenting the norms themselves.
+
+## When Standards Come Up
+
+- Starting a new project and defining conventions
+- Onboarding context: "what are our standards?"
+- Policy decisions: dependency criteria, accessibility requirements
+- Resolving disagreements about style or approach
+
+## Writing Standards Documents
+
+Structure standards as actionable rules, not aspirational prose:
+
+```markdown
+## [Category] Standards
+
+### Rule: [Concise directive]
+**Rationale**: Why this matters.
+**Example**: What compliance looks like.
+**Exception**: When this doesn't apply (if any).
+```
+
+Keep them scannable. A standard nobody reads is a standard nobody follows.
+
+## Common Standards Areas
+
+| Area | Covers | Not |
+|------|--------|----|
+| Coding style | Formatting, naming, file structure | Architecture patterns (Design Way) |
+| Testing philosophy | When to test, coverage expectations | Test mechanics (Testing Way) |
+| Dependency policy | Evaluation criteria, update cadence | Package management (Deps Way) |
+| Accessibility | WCAG compliance level, testing requirements | UI implementation details |
+| Documentation | What to document, where, format | How to write docs (Docs Way) |
+
+## Establishing vs Enforcing
+
+This way helps **establish** standards. Enforcement belongs elsewhere:
+- Linters and formatters for style rules
+- CI checks for coverage thresholds
+- Review checklists for process compliance
+
+## Avoid
+
+- Standards without rationale (rules need "why")
+- Standards that duplicate tooling (if the linter catches it, don't write a standard for it)
+- Aspirational standards nobody plans to enforce

hooks/ways/softwaredev/environment/debugging/way.md

@@ -1,5 +1,5 @@
 ---
-description: debugging code issues, troubleshooting errors, investigating broken behavior, fixing bugs
+description: debugging code issues, troubleshooting failures, investigating broken behavior, fixing bugs
 vocabulary: debug breakpoint stacktrace investigate troubleshoot regression bisect crash error fail bug log trace exception segfault hang timeout
 threshold: 2.0
 scope: agent, subagent

tests/README.md

@@ -13,7 +13,7 @@ Three layers, from fast/automated to slow/interactive. See [way-match/results.md
 
 ### 1. Fixture Tests (BM25 vs NCD scorer comparison)
 
-Runs 54 test prompts against a fixed 18-way corpus (all softwaredev ways with BM25 semantic matching). Compares BM25 binary against gzip NCD baseline. Reports TP/FP/TN/FN for each scorer.
+Runs 70 test prompts against a fixed 20-way corpus (all softwaredev ways with BM25 semantic matching). Compares BM25 binary against gzip NCD baseline. Reports TP/FP/TN/FN for each scorer. Includes co-activation fixtures that validate multi-way triggering.
 
 ```bash
 tests/way-match/run-tests.sh fixture --verbose
@@ -23,13 +23,13 @@ bash tools/way-match/test-harness.sh --verbose
 
 Options: `--bm25-only`, `--ncd-only`, `--verbose`
 
-**What it covers**: Scorer accuracy, false positive rate, head-to-head comparison. Tests direct vocabulary matches, synonym/paraphrase variants, and negative controls.
+**What it covers**: Scorer accuracy, false positive rate, head-to-head comparison. Tests direct vocabulary matches, synonym/paraphrase variants, negative controls, and co-activation (multi-way expected sets).
 
-**Current baseline**: BM25 48/54, 0 FP.
+**Current baseline**: BM25 63/70, 0 FP. Co-activation: 6/6 FULL.
 
 ### 2. Integration Tests (real way files)
 
-Scores 31 test prompts against actual `way.md` files extracted from the live ways directory. Tests the real frontmatter extraction pipeline.
+Scores 34 test prompts (including 3 co-activation) against actual `way.md` files extracted from the live ways directory. Tests the real frontmatter extraction pipeline.
 
 ```bash
 tests/way-match/run-tests.sh integration
@@ -39,7 +39,7 @@ bash tools/way-match/test-integration.sh
 
 **What it covers**: End-to-end scoring with real way vocabulary, multi-way discrimination (does the right way win?), threshold behavior with actual threshold values.
 
-**Current baseline**: BM25 27/31 (0 FP), NCD 15/31 (3 FP).
+**Current baseline**: BM25 28/34 (0 FP), NCD 16/34 (3 FP).
 
 ### 3. Activation Test (live agent + subagent)
 

tools/way-match/test-fixtures.jsonl

@@ -52,3 +52,19 @@
 {"prompt": "what time zone is Tokyo in", "expected": null, "match": false, "category": "negative"}
 {"prompt": "summarize this document for me", "expected": null, "match": false, "category": "negative"}
 {"prompt": "translate this paragraph to Spanish", "expected": null, "match": false, "category": "negative"}
+{"prompt": "create a migration to alter the users table and add an index on email", "expected": ["softwaredev-delivery-migrations", "softwaredev-delivery-patches"], "match": true, "category": "coactivation", "note": "delivery domain overlap: migrations schema + patches diff"}
+{"prompt": "write tests to verify the exception handling works correctly", "expected": ["softwaredev-code-testing", "softwaredev-code-errors"], "match": true, "category": "coactivation", "note": "testing verify + errors exception handling"}
+{"prompt": "audit our dependencies for security vulnerabilities", "expected": ["softwaredev-environment-deps", "softwaredev-code-security"], "match": true, "category": "coactivation", "note": "shared vulnerability and audit terms"}
+{"prompt": "debug the unhandled exception and add proper error handling", "expected": ["softwaredev-environment-debugging", "softwaredev-code-errors"], "match": true, "category": "coactivation", "note": "debugging investigate + errors exception handling"}
+{"prompt": "design the database schema for the new microservice", "expected": ["softwaredev-architecture-design", "softwaredev-delivery-migrations"], "match": true, "category": "coactivation", "note": "shared schema/database terms across architecture and delivery"}
+{"prompt": "refactor this module to reduce coupling and improve cohesion", "expected": ["softwaredev-code-quality", "softwaredev-architecture-design"], "match": true, "category": "coactivation", "note": "shared coupling/cohesion between quality metrics and design patterns"}
+{"prompt": "perform a STRIDE analysis on the authentication flow", "expected": "softwaredev-architecture-threat-modeling", "match": true, "category": "direct"}
+{"prompt": "document the trust boundaries between services", "expected": "softwaredev-architecture-threat-modeling", "match": true, "category": "direct"}
+{"prompt": "update the risk register with the new attack surface", "expected": "softwaredev-architecture-threat-modeling", "match": true, "category": "direct"}
+{"prompt": "establish coding standards for the team", "expected": "softwaredev-docs-standards", "match": true, "category": "direct"}
+{"prompt": "write a dependency policy with evaluation guidelines", "expected": "softwaredev-docs-standards", "match": true, "category": "direct"}
+{"prompt": "define accessibility guidelines for the frontend", "expected": "softwaredev-docs-standards", "match": true, "category": "direct"}
+{"prompt": "write an RFC for the new caching architecture", "expected": "softwaredev-architecture-design", "match": true, "category": "direct", "note": "RFC vocabulary expansion"}
+{"prompt": "sketch out a proposal for the event-driven refactoring", "expected": "softwaredev-architecture-design", "match": true, "category": "synonym", "note": "design way RFC/proposal expansion"}
+{"prompt": "what are the risks of going to the beach today", "expected": null, "match": false, "category": "negative", "note": "risk is in threat-modeling but context is non-technical"}
+{"prompt": "follow the standard operating procedure for checkout", "expected": null, "match": false, "category": "negative", "note": "standard is in standards way but context is non-technical"}