Initial commit

skills/steerings-generator/interview-packs.md

@@ -0,0 +1,126 @@
+# 🧠 Interview Questions Pack
+
+> Purpose: structured interviews to elicit tacit development rules that later become `steerings/` documents.
+> Audience: senior engineers, leads, or architects who already maintain part of the repo and its delivery flow.
+
+---
+
+## 1. Codebase Topology & Ownership
+
+**Goal:** clarify how the repo is organized, what "ownership" means, and when to reuse vs. create new code.
+
+- Where do shared types, schemas, and business logic live?
+- What files or directories are considered "do-not-touch" zones?
+- When is it acceptable to add a new module vs. reuse an existing one?
+- How do you decide ownership of a package or folder?
+- What are the boundaries for editing shared libraries or common utilities?
+- How do versioning and `workspace:*` dependencies affect this structure?
+
+---
+
+## 2. Architecture & Design Invariants
+
+**Goal:** surface the invisible structure that keeps the system stable.
+
+- What architectural layering patterns are enforced (controller/service/repo, hexagonal, CQRS, etc.)?
+- Which dependency directions are allowed or forbidden?
+- What naming or import alias rules exist (`@core/*`, `@features/*`, etc.)?
+- What design patterns are mandatory or discouraged (events vs. sync calls, DTOs, decorators)?
+- What are your caching, concurrency, or idempotency expectations?
+- How do you define acceptable performance budgets (latency, memory, N+1 queries)?
+- What are the conventions for APIs (REST, GraphQL, gRPC) and versioning/compatibility?
+
+---
+
+## 3. Business Domain Contracts
+
+**Goal:** capture business logic invariants that constrain code behavior.
+
+- What are the key domain entities and their invariants?
+- How are permissions, roles, and entitlements enforced?
+- Are there licensing tiers or feature flags that affect code paths?
+- What money-handling or compliance rules shape the design (audit logs, consent, retention)?
+- Are there region-specific or client-specific quirks?
+- What are the naming or event rules for domain models?
+
+---
+
+## 4. Quality & Style Assurance
+
+**Goal:** uncover what "high-quality" and "mergeable" mean in this context.
+
+- What naming, formatting, and readability standards are non-negotiable?
+- What must be true before merging a PR ("Definition of Done")?
+- How do you enforce dependency discipline (adding/removing libs)?
+- What are the rules for logging, error handling, and observability?
+- What steps are included in a quality check (`pnpm qc`, lint, type-check, tests)?
+- What are examples of commits or PRs that would be rejected outright?
+
+---
+
+## 5. Testing & Verification Strategy
+
+**Goal:** understand how the team proves code correctness and stability.
+
+- What test types are required for each layer (unit, integration, e2e, contract)?
+- How are test folders and fixtures structured?
+- What is your coverage target or philosophy (e.g. 70% meaningful coverage vs. 100%)?
+- How do you treat flaky or brittle tests?
+- What are "known fragile" modules or flows that require extra attention?
+- How are test data and mocks handled (real DB, Docker, fake API, etc.)?
+
+---
+
+## 6. Risk & Historical Landmines
+
+**Goal:** map the organization's collective memory of past failures.
+
+- What modules or flows are risky or easy to break?
+- What parts of the system "look wrong but are intentional"?
+- Are there legacy shims, vendor workarounds, or design debts everyone should know?
+- Which incidents led to new "never again" rules?
+- What kind of changes are considered dangerous or need special review?
+
+---
+
+## 7. Security, Data & Compliance
+
+**Goal:** surface hidden security expectations that engineers internalize but rarely document.
+
+- What are the authentication/authorization boundaries?
+- How should secrets and tokens be stored and accessed?
+- What patterns are unsafe (direct DB access, unvalidated inputs, inline secrets)?
+- How is PII or PHI classified and protected?
+- What redaction or anonymization rules apply to logs and metrics?
+- What are allowed inbound/outbound service communications?
+- How are incidents, breaches, or audit events handled?
+
+---
+
+## 8. Delivery Lifecycle & Change Flow
+
+**Goal:** make implicit shipping rules explicit.
+
+- What is the preferred branching model and commit message format?
+- How should PR templates and changelogs be filled out?
+- What artifacts are required for a feature (migration plan, rollout doc, flag plan)?
+- What is the usual rollout → canary → rollback flow?
+- How is configuration managed (`.env` → validated config → injected)?
+- What approvals or sign-offs are required before deploy?
+
+---
+
+## 📘 Outcome Mapping
+
+Each interview section contributes to a steering document:
+
+| Interview Section | Derived Steering |
+|--------------------|------------------|
+| Codebase Topology & Ownership | `steerings/code-ownership.md` |
+| Architecture & Design Invariants | `steerings/architecture-invariants.md` |
+| Business Domain Contracts | `steerings/domain-invariants.md` |
+| Quality & Style Assurance | `steerings/quality-and-style.md` |
+| Testing & Verification Strategy | `steerings/testing-strategy.md` |
+| Risk & Historical Landmines | `steerings/risk-registry.md` |
+| Security, Data & Compliance | `steerings/security-and-compliance.md` |
+| Delivery Lifecycle & Change Flow | `steerings/delivery-lifecycle.md` |