jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/pre-deployment-gotcha-review/evals/evals.json

@@ -0,0 +1,59 @@
+{
+  "skill_name": "pre-deployment-gotcha-review",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Review this MVP scope document for gotchas before we estimate it:\n\n# Customer Support AI Assistant MVP\n\n## Overview\nBuild an AI-powered customer support assistant that answers questions from internal knowledge base documents stored in SharePoint Online. The assistant will be deployed as a Teams bot accessible to all employees.\n\n## Technical Approach\n- Index SharePoint documents using Azure AI Search\n- Use GPT-4o for response generation\n- Deploy as a Teams bot using Bot Framework\n- Users will authenticate through existing SSO\n\n## Integrations\n- SharePoint Online (document source)\n- ServiceNow (ticket creation for escalation)\n- Microsoft Teams (UI channel)\n\n## Timeline\n- Sprint 1-2: Document ingestion and search\n- Sprint 3-4: Bot development and response generation\n- Sprint 5: UAT and deployment\n\n## Acceptance Criteria\n- Bot answers questions accurately using knowledge base\n- Users can escalate to human support\n- Response time under 5 seconds",
+      "expected_output": "A structured gotcha review report identifying issues including: underspecified identity/SSO, missing document permission model for SharePoint indexing, ServiceNow integration assumptions, vague acceptance criteria, no operational support model, no evaluation dataset, missing RAG access control design.",
+      "files": [],
+      "expectations": [
+        "Report includes an Executive Summary section",
+        "Report includes an Overall Readiness Rating (Yellow, Orange, or Red)",
+        "Report identifies that SSO/identity provider is underspecified",
+        "Report identifies that SharePoint document permissions may not survive indexing into Azure AI Search",
+        "Report identifies that ServiceNow integration details are missing (API, auth, ticket creation flow)",
+        "Report identifies that acceptance criteria are vague or subjective (what is 'accurately'?)",
+        "Report identifies that no evaluation dataset or ground truth exists",
+        "Report identifies that operational support is not defined",
+        "Report includes a Mitigation Backlog with prioritized actions",
+        "Report includes Clarifying Questions grouped by owner"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "I need you to review this architecture note for hidden gotchas before we commit to the scope. This is for a financial services client:\n\n# Loan Document Processing Agent\n\n## Purpose\nAutomate loan document review by extracting key fields from uploaded PDFs, classifying document types, and flagging missing information.\n\n## Architecture\n- Document upload through internal web portal\n- Azure Document Intelligence for extraction\n- GPT-4o for classification and gap analysis\n- Results stored in SQL Server (on-premises)\n- Notifications via internal email system\n- Agent can approve documents under $50K automatically\n\n## Data Sources\n- Loan applications (PDF)\n- Supporting documents (pay stubs, tax returns, bank statements)\n- Internal lending policies (Word docs in shared drive)\n\n## Security\n- Internal application only\n- Role-based access\n- Audit trail required\n\n## Deployment\n- Docker containers on internal Kubernetes cluster\n- CI/CD through Jenkins",
+      "expected_output": "A structured report flagging: on-prem SQL Server connectivity, the agent auto-approving loans (major risk in financial services), PII/PHI in loan documents, regulatory concerns (SR 11-7, fair lending), missing human-in-the-loop for financial decisions, vague 'role-based access', network connectivity for cloud AI services to on-prem data, shared drive access assumptions.",
+      "files": [],
+      "expectations": [
+        "Report identifies that the agent auto-approving loans under $50K is a critical risk in financial services",
+        "Report identifies regulatory implications (model risk management, fair lending, SR 11-7 or similar)",
+        "Report identifies that loan documents contain PII (SSN, income, bank details) requiring specific handling",
+        "Report identifies on-premises SQL Server connectivity challenges for cloud-based AI services",
+        "Report identifies that 'shared drive' access for lending policies may not be reachable from containers",
+        "Report identifies that 'role-based access' is undefined (what roles, what permissions, enforced where)",
+        "Report identifies that audit trail requirements need specific design (what is logged, retention, access)",
+        "Report rates readiness as Orange or Red due to the automated approval without human oversight",
+        "Report includes questions for compliance/legal about automated lending decisions",
+        "Report flags the absence of an evaluation strategy for extraction accuracy"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "We're doing a Jump Start workshop follow-up and the client wants to build a RAG system over their internal Confluence wiki and Jira tickets. Here are the rough notes from the workshop. Can you do a gotcha review before we write the SOW?\n\nWorkshop Notes:\n- Client: mid-size healthcare company (~3000 employees)\n- Goal: internal knowledge assistant for clinical operations staff\n- Sources: Confluence (5000+ pages), Jira (50K+ tickets), internal clinical protocols (PDFs on network share)\n- Users: ~200 clinical operations staff\n- Auth: they use Okta with MFA\n- Current pain: staff spend 2+ hours/day searching for answers across systems\n- They want it in Teams\n- Budget: they mentioned $150K for MVP\n- Timeline: 'as fast as possible, maybe 8 weeks'\n- Technical team: 2 developers, 1 PM on client side\n- They said data is 'pretty clean'\n- They want the AI to 'just know everything we know'\n- Hosting: Azure (they have an existing subscription)\n- Mentioned they need to be HIPAA compliant\n- The Confluence has different space permissions per department\n- Some Jira tickets reference patient cases",
+      "expected_output": "A comprehensive gotcha review identifying: HIPAA implications for Jira tickets with patient data, Confluence space permissions that must survive RAG ingestion, network share accessibility, 8-week timeline likely unrealistic for HIPAA-compliant RAG, budget may be tight for healthcare compliance, PHI in Jira tickets, permission-aware retrieval needed, Okta integration specifics needed, evaluation strategy missing, vague acceptance criteria ('just know everything').",
+      "files": [],
+      "expectations": [
+        "Report identifies HIPAA compliance as a critical concern given patient data in Jira tickets",
+        "Report identifies that Confluence space permissions must be preserved in RAG retrieval",
+        "Report identifies that Jira tickets containing patient case references are PHI",
+        "Report identifies that 8-week timeline is aggressive for HIPAA-compliant AI system",
+        "Report identifies that network share PDFs may not be accessible from Azure",
+        "Report identifies that 'just know everything we know' is not a testable acceptance criterion",
+        "Report identifies the need for BAA with Azure OpenAI for HIPAA",
+        "Report identifies that Okta MFA integration needs specific design for Teams bot",
+        "Report recommends resolving HIPAA and data classification before committing to fixed scope",
+        "Report includes a readiness rating of Orange or Red"
+      ]
+    }
+  ]
+}

package/.github/skills/pre-deployment-gotcha-review/references/ai-agent-risk.md

@@ -0,0 +1,104 @@
+# AI, Agent, and Model Risk — Deep Dive
+
+## Why This Category Matters
+
+AI systems introduce a class of risk that traditional software does not have: non-determinism, hallucination, prompt injection, tool misuse, invisible decision-making, and behaviors that change when models are updated. When an AI agent can take actions (call tools, send messages, modify data), the blast radius of a failure expands dramatically.
+
+---
+
+## Questions the Review Must Ask
+
+### Behavioral Boundaries
+- What is the AI allowed to do? (Recommend, draft, classify, extract, approve, act)
+- What is explicitly forbidden?
+- Is the AI making decisions or supporting human decisions?
+- What happens when the AI encounters a request outside its scope?
+- Is there a defined "I don't know" behavior?
+- Is there a defined "I'm not confident" behavior?
+
+### Agent Capabilities
+- What tools can the agent call?
+- Can any tool create, modify, or delete data?
+- Can any tool send messages or notifications?
+- Can any tool access external systems?
+- Are tool calls logged and auditable?
+- Is there a maximum tool call depth or loop limit?
+- What happens if a tool call fails?
+
+### Human-in-the-Loop
+- Which operations require human approval before execution?
+- What is the approval mechanism?
+- What happens if no approver is available?
+- Can approvals be delegated?
+- Is there a timeout or auto-deny for unresolved approvals?
+- Are overrides logged with justification?
+
+### Prompt Injection and Adversarial Input
+- Can users inject instructions through their inputs?
+- Can retrieved documents contain adversarial content?
+- Are system prompts protected from extraction?
+- Are tool descriptions or capabilities exposed to users?
+- Is there input validation before prompts reach the model?
+- Is there output validation before responses reach users?
+
+### Data Exfiltration Risk
+- Can the AI be tricked into including sensitive data in outputs?
+- Can tool calls be manipulated to send data to unauthorized destinations?
+- Are outputs monitored for sensitive data leakage?
+- Is there a data loss prevention (DLP) layer on outputs?
+
+### Evaluation and Quality
+- Does an evaluation dataset exist?
+- What metrics are tracked? (Faithfulness, groundedness, relevance, task success)
+- Are there automated CI gates for prompt or model changes?
+- Is there a baseline for acceptable quality?
+- How is regression detected?
+- Is there a process for updating evaluations when requirements change?
+
+### Hallucination and Grounding
+- What is the grounding strategy? (RAG, function results, structured data)
+- What happens when no grounding information is available?
+- Are there confidence thresholds below which the AI should abstain?
+- Is the AI allowed to speculate or is it restricted to sourced information?
+- Are hallucinations in critical fields (amounts, dates, names) treated differently?
+
+### Model Management
+- Which model is used? (Version, provider, deployment)
+- What happens when the model is deprecated or updated?
+- Is there a fallback model?
+- How is model selection tested before production use?
+- Are model costs monitored and bounded?
+- Is there a cost circuit breaker?
+
+---
+
+## Common Gotcha Patterns
+
+### The "just a helper" trap
+The system is described as "AI-assisted" or "copilot" but its outputs directly drive operational decisions without meaningful human review.
+
+### The missing "I don't know"
+No behavior is defined for when the AI lacks sufficient context. It answers confidently regardless of evidence quality.
+
+### The unbounded agent
+The agent can call tools in loops without limit. A misinterpretation cascades into dozens of incorrect actions before anyone notices.
+
+### The evaluation-free deployment
+No evaluation dataset exists. Quality is assessed by vibes. Regression is discovered by users in production.
+
+### The trusted document assumption
+Retrieved documents are treated as trustworthy. An adversary places injection content in a document that gets indexed and executed by the agent.
+
+### The invisible decision
+The AI makes a classification or routing decision that is not logged. When something goes wrong, there is no trail to understand why.
+
+---
+
+## Mitigation Patterns
+
+1. **Decision Boundary Documentation** — Explicitly document what the AI can and cannot do. Make the boundary auditable.
+2. **Mandatory Eval Set** — Require an evaluation dataset before production. No eval, no deploy.
+3. **Approval Gates by Risk Tier** — Classify agent actions into risk tiers. High-risk actions require human approval; low-risk actions can be automated.
+4. **Input/Output Guardrails** — Apply content filtering on inputs and outputs. Check for prompt injection patterns, PII leakage, and policy violations.
+5. **Observability by Default** — Log every model call, tool invocation, and decision with enough context to reconstruct the reasoning.
+6. **Circuit Breakers** — Implement limits on tool call depth, cost per request, and actions per time window.

package/.github/skills/pre-deployment-gotcha-review/references/api-gateway.md

@@ -0,0 +1,81 @@
+# API Gateway — Deep Dive
+
+## Why This Category Matters
+
+Enterprise API gateways add layers of security, governance, rate limiting, and transformation that proposals often gloss over with "integrate with X API." The reality is that API access in large enterprises is gated by onboarding processes, policy enforcement, certificate management, and operational constraints that can add weeks to a timeline.
+
+---
+
+## Questions the Review Must Ask
+
+### Gateway Presence
+- Does an API gateway sit between the application and target APIs?
+- Which gateway? (Apigee, Azure API Management, AWS API Gateway, Kong, MuleSoft)
+- Is the gateway managed by a central team or the API owner?
+- Are there multiple gateways in the path?
+
+### API Availability
+- Do the required APIs actually exist?
+- Are they documented (OpenAPI spec)?
+- Are they in production or still in development?
+- Do they expose the specific fields/operations needed?
+- Are there planned breaking changes?
+
+### Onboarding Process
+- What is the process to get access to an API through the gateway?
+- Is developer portal registration required?
+- Who approves API access?
+- What is the typical SLA for onboarding?
+- Are there separate approvals for non-production and production?
+
+### Security Requirements
+- Is mTLS required?
+- Are client certificates needed?
+- Who provisions certificates?
+- What is the certificate rotation process?
+- Are API keys required in addition to OAuth tokens?
+- Are there IP allowlists?
+
+### Policies and Limits
+- Are rate limits enforced?
+- What are the quotas (per second, per day)?
+- Will the expected AI workload exceed quotas?
+- Are there payload size limits?
+- Are there request timeout limits?
+- Are there transformation policies that modify requests/responses?
+
+### Environments
+- Are sandbox/non-production endpoints available?
+- Do sandbox APIs return realistic data?
+- Do sandbox and production APIs have the same contract?
+- Are there environment-specific gateway policies?
+- Is there a promotion process from sandbox to production?
+
+---
+
+## Common Gotcha Patterns
+
+### The "integrate with X" assumption
+The proposal says "integrate with the CRM API" without acknowledging that the API is behind another system, requires mTLS, has a 3-week onboarding process, and returns different data in sandbox vs. production.
+
+### The quota surprise
+AI workloads make many API calls per user interaction. Rate limits designed for human-driven traffic throttle the AI agent within minutes.
+
+### The certificate procurement delay
+mTLS is required. Certificate provisioning requires a security review, key ceremony, and HSM configuration. This process takes 4-6 weeks and was not in the timeline.
+
+### The missing API
+The "API" that the proposal references is actually a scheduled batch export or a UI-only workflow. No real-time programmatic access exists.
+
+### The sandbox-production gap
+Development is done against a sandbox that returns mock data with a simplified schema. Production API has additional required fields, stricter validation, and different error codes.
+
+---
+
+## Mitigation Patterns
+
+1. **API Onboarding Checklist** — Create a per-API checklist: gateway, auth, certificates, quotas, sandbox access, OpenAPI spec, owner contact.
+2. **Spike: End-to-End API Call** — Validate one complete API call through the production gateway path (or production-equivalent) before committing scope.
+3. **Quota Analysis** — Calculate expected API call volume per user per day for the AI workload. Compare against published quotas. Request quota increases early if needed.
+4. **Certificate Timeline** — If mTLS is required, add certificate provisioning to the critical path with buffer.
+5. **Contract-First Development** — If no OpenAPI spec exists, create one collaboratively with the API owner before building integration code.

package/.github/skills/pre-deployment-gotcha-review/references/authorization-access-control.md

@@ -0,0 +1,77 @@
+# Authorization and Access Control — Deep Dive
+
+## Why This Category Matters
+
+Authorization determines who can do what. In AI systems, this becomes especially complex because the AI itself needs access to data, the retrieval layer needs permission filtering, and the user-facing outputs must respect data entitlements that may originate from multiple source systems.
+
+---
+
+## Questions the Review Must Ask
+
+### Role Design
+- What roles exist in the system?
+- Where are roles defined — IdP, application database, source system, or multiple?
+- What is the source of truth for role assignment?
+- How are roles granted, changed, and revoked?
+- Is there a role hierarchy or inheritance model?
+
+### Permission Enforcement
+- Where is authorization enforced — UI, API, database, retrieval layer, or all?
+- Is there defense in depth (multiple enforcement points)?
+- Can a direct API call bypass UI-level restrictions?
+- Are database queries filtered by user context?
+
+### Data-Level Access
+- Is row-level security (RLS) needed?
+- Is document-level security needed?
+- Is field-level security needed (e.g., PII columns)?
+- Is tenant isolation required?
+- How is tenant context determined and enforced?
+
+### Separation of Duties
+- Can the same person submit and approve?
+- Are there four-eyes requirements?
+- Is maker-checker enforced for sensitive operations?
+- Are audit requirements met for segregation?
+
+### Admin and Emergency Access
+- What can admin users do?
+- Is admin access logged and reviewed?
+- Is there a break-glass process for emergency access?
+- Are admin permissions time-bound?
+- Can admins impersonate users?
+
+### Permission Lifecycle
+- How often are permissions reviewed/recertified?
+- What happens when users change roles or leave?
+- Are orphaned permissions detected and cleaned?
+- Is there automated deprovisioning?
+
+---
+
+## Common Gotcha Patterns
+
+### Frontend-only authorization
+The UI hides buttons based on roles, but the API accepts any authenticated request. A direct API call bypasses all access controls.
+
+### Source system permissions lost in transit
+Data is extracted from a system with fine-grained permissions (SharePoint, SAP, ServiceNow) and loaded into a flat store where original entitlements are not preserved.
+
+### Tenant isolation assumed
+Multi-tenant architecture is described but no mechanism prevents one tenant's data from appearing in another tenant's queries or AI responses.
+
+### Over-privileged admin
+Admin users can see all data, modify all records, and impersonate all users with no audit trail or justification requirement.
+
+### AI bypasses authorization
+The AI has broad data access for retrieval/generation, but returns information to users who should not have access to the underlying source data.
+
+---
+
+## Mitigation Patterns
+
+1. **Permission Matrix** — Document who can perform each action on each resource type. Validate with stakeholders before build.
+2. **Enforcement at Every Layer** — Require authorization checks at API gateway, service layer, and data layer. Never rely on UI alone.
+3. **Retrieval-Time Filtering** — In RAG systems, apply user permissions as filters during vector search, not after results are returned.
+4. **Tenant Isolation Testing** — Include specific test cases that attempt cross-tenant data access.
+5. **Permission Audit Trail** — Log all permission grants, changes, and access decisions for compliance.

package/.github/skills/pre-deployment-gotcha-review/references/data-readiness.md

@@ -0,0 +1,103 @@
+# Data Readiness — Deep Dive
+
+## Why This Category Matters
+
+AI systems are only as good as the data they operate on. A beautifully designed agent architecture is worthless if the underlying data is stale, incomplete, unlabeled, duplicated, sensitive, or unreachable. Data readiness issues are the most common silent killer of AI MVPs.
+
+---
+
+## Questions the Review Must Ask
+
+### Availability
+- What data sources are required?
+- Are they available for development today?
+- Are they available for production?
+- Is there a difference between dev and prod data access?
+- Are there access approval processes?
+- What is the latency of data availability (real-time, hourly, daily, weekly)?
+
+### Quality
+- Is the data complete (few missing values in critical fields)?
+- Is the data accurate (validated against ground truth)?
+- Is the data consistent (same entity represented the same way)?
+- Is the data current (refreshed at the needed frequency)?
+- Are there known quality issues documented by the data owner?
+- Is there a data quality SLA?
+
+### Ownership
+- Who owns each data source?
+- Who can grant access?
+- Who is responsible for quality?
+- Who handles incidents when data is wrong or missing?
+- Is there a data steward or governance body?
+
+### Structure and Format
+- Is the data structured, semi-structured, or unstructured?
+- What format? (SQL tables, JSON, CSV, PDF, images, audio, video)
+- Is there a schema? Is it stable?
+- Are there unique identifiers for records?
+- Are there foreign keys or relationships between sources?
+- Is there a data dictionary or catalog?
+
+### Volume and Scale
+- How much data exists? (rows, documents, GB)
+- Is the volume growing? At what rate?
+- Can the AI system handle the full volume or is sampling needed?
+- Are there performance implications of processing the full dataset?
+
+### Ground Truth and Labeling
+- Does labeled data exist for the AI task?
+- Who created the labels?
+- Are labels consistent and high-quality?
+- Is there ground truth for evaluation?
+- If no labels exist, how will the AI be evaluated?
+- Is synthetic data generation feasible for bootstrapping?
+
+### Sensitivity and Classification
+- Does the data contain PII (names, emails, addresses, SSNs)?
+- Does it contain PHI (health records, diagnoses)?
+- Does it contain PCI (credit card numbers)?
+- Is it ITAR or export-controlled?
+- What is the data classification level?
+- Are there data residency requirements?
+- Can the data be used for AI/ML under current policies and terms?
+
+### Duplication and Conflict
+- Are there multiple sources for the same data?
+- Which is the system of record?
+- How are conflicts resolved?
+- Is there a master data management (MDM) strategy?
+- Are duplicates present within individual sources?
+
+---
+
+## Common Gotcha Patterns
+
+### Demo vs. production quality
+Development uses clean, curated sample data. Production data has missing fields, inconsistent formats, duplicates, and outliers that break the AI.
+
+### The missing ground truth
+There is no labeled dataset against which to evaluate the AI. "We'll know it when we see it" is the evaluation strategy.
+
+### The permissions wall
+The data exists and the team knows what it looks like, but the access approval process takes 6 weeks and involves a data governance committee.
+
+### The "single source of truth" myth
+Three systems claim to be the source of truth for customer records. They disagree on 12% of entries.
+
+### The legal blocker
+The data can technically be accessed, but using it for AI model training or inference violates the data use agreement, privacy policy, or regulatory requirement.
+
+### The staleness surprise
+The data is refreshed nightly, but the AI use case requires near-real-time responses. Users see yesterday's data presented as current facts.
+
+---
+
+## Mitigation Patterns
+
+1. **Data Inventory** — Create a data source inventory with: source, owner, access method, quality assessment, sensitivity classification, and current availability.
+2. **Ground Truth First** — Invest in evaluation data before building the AI. Even 50-100 labeled examples enable meaningful quality measurement.
+3. **Data Quality Profile** — Run profiling on the actual production data (not sample data) to surface nulls, duplicates, and anomalies.
+4. **Access Approval Early** — Submit data access requests in sprint 0. These often have long lead times.
+5. **Sensitivity Scan** — Run automated PII/PHI/PCI detection on the data before building features that surface it through AI.
+6. **Production Data in Dev** — If possible, use anonymized production data in development to catch quality issues early.

package/.github/skills/pre-deployment-gotcha-review/references/delivery-commercial-risk.md

@@ -0,0 +1,119 @@
+# Delivery, Scope, and Commercial Risk — Deep Dive
+
+## Why This Category Matters
+
+The gap between "plausible solution concept" and "estimatable, deliverable scope" is where most commercial risk lives. Proposals that read well but contain unvalidated assumptions create fixed-fee traps, scope disputes, and delivery failures. This category focuses on whether the scope is actually ready for commitment.
+
+---
+
+## Questions the Review Must Ask
+
+### Scope Boundaries
+- Is the MVP scope clearly bounded?
+- Is there an explicit "in scope" and "out of scope" list?
+- Are edge cases addressed or explicitly excluded?
+- Is the definition of "done" objective and testable?
+- Could a reasonable person read this scope and estimate it?
+
+### Integration Validation
+- Have integrations been validated (not just listed)?
+- Has someone made a successful API call to each integration point?
+- Are integration dependencies on the critical path?
+- Are there integration dependencies owned by other teams?
+- What happens if an integration is harder than assumed?
+
+### Access and Approvals
+- Are all access approvals included in the timeline?
+- Is security review included in the timeline?
+- Are environment provisioning times accounted for?
+- Are data access requests submitted?
+- Are there approvals that require committee meetings (which meet monthly)?
+
+### Environments
+- Are development environments available?
+- Are they representative of production?
+- Is production deployment in scope or separate?
+- Are there environment-specific configurations to manage?
+- Is CI/CD in scope or assumed to exist?
+
+### Testing
+- Is UAT in scope?
+- Who performs UAT? Are they assigned and available?
+- Is test data available?
+- Are acceptance tests defined objectively?
+- Is performance/load testing in scope?
+- Is security testing (pen test) in scope?
+
+### Change Management
+- Is user training in scope?
+- Is documentation in scope?
+- Is communication planning in scope?
+- Are there role or process changes required?
+- Who manages organizational change?
+
+### Client Dependencies
+- Are client responsibilities enumerated?
+- Are there client-side tasks on the critical path?
+- What happens if the client is late on dependencies?
+- Is there a RACI or responsibility matrix?
+- Are SME availability and response time expectations set?
+
+### Commercial Terms
+- Is this fixed-fee, T&M, or outcome-based?
+- If fixed-fee, is the scope bounded enough to price safely?
+- Is there a change request process?
+- What happens when scope changes are identified mid-delivery?
+- Is hypercare included? What is its scope?
+- Are travel, licenses, and infrastructure costs included or separate?
+
+---
+
+## Common Gotcha Patterns
+
+### The "simple integration" hiding weeks of work
+The proposal says "integrate with ServiceNow" but ServiceNow requires a custom scoped application, OAuth setup, an Apigee onboarding, and a security review.
+
+### The unavailable UAT team
+UAT is in the plan, but the business users who should test are in quarter-end close, on leave, or not assigned.
+
+### The security review outside the timeline
+The security review takes 4 weeks. The project timeline assumes it happens in parallel with nothing. In reality, it creates a hard gate before production deployment.
+
+### The production data wall
+Development uses synthetic data. Production deployment requires real data access that needs a separate approval process nobody started.
+
+### The subjective acceptance criteria
+"The AI should provide helpful responses" is not testable. When is the project done? When someone says it "feels good enough"?
+
+### The POC-to-production confusion
+Stakeholders expect production readiness from what was scoped as a proof of concept. The POC uses hardcoded credentials, no error handling, and sample data.
+
+---
+
+## Estimation Readiness Checklist
+
+Before declaring scope "ready to estimate," verify:
+
+| Check | Status |
+|-------|--------|
+| All integrations have confirmed access method and contact | |
+| Identity and access approach is validated | |
+| Data sources are confirmed accessible | |
+| Environments are available or provisioning is in timeline | |
+| Acceptance criteria are objective and testable | |
+| Client dependencies are listed with owners | |
+| Security review timeline is included | |
+| Out-of-scope items are explicit | |
+| Assumptions are documented with "risk if wrong" | |
+| Change request process is defined | |
+
+---
+
+## Mitigation Patterns
+
+1. **Scope Freeze Gate** — Do not commit to fixed-fee until the estimation readiness checklist passes.
+2. **Integration Spikes First** — Run technical spikes on the riskiest integrations in sprint 0 before committing to delivery estimates.
+3. **Assumption Language** — Include explicit assumption language in the SOW: "This estimate assumes X. If X is not true, a change request will be required."
+4. **Client Responsibility Register** — Enumerate every client dependency with expected delivery date. Include in SOW for mutual accountability.
+5. **Acceptance Criteria Workshop** — Run a 1-hour session with the product owner to define testable acceptance criteria before build starts.
+6. **Parallel Security Track** — Submit security review requests at project start rather than at the end. Run security in parallel with build.