Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Deliver a complete forward-deployment case study for a customer-embedded product integration. Requirements: (1) discovery brief and success metrics; (2) architecture and data-flow diagram covering trust boundaries, identity, secrets, audit logs, and failure modes; (3) production-quality implementation of the critical path, such as a connector plus workflow assistant or automation; (4) security/compliance notes with data minimization and access model; (5) observability and incident runbook; (6) adoption/change-management plan; (7) product feedback ticket(s) turning field learning into reusable product opportunities; (8) scope-control note explaining what was deferred, why, and who owns follow-up.
Discovery, architecture, data flow, trust boundaries, implementation, and acceptance metrics tell a coherent customer-deployment story.
Security/compliance, observability, incident response, rollback, handoff docs, and adoption plan are practical enough for customer and internal teams to operate.
Field learnings become high-quality product feedback, while deferred/custom work is classified with tradeoffs, ownership, and support impact.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# An end-to-end forward deployment package ## Goal Deliver a complete forward-deployment case study for a customer-embedded product integration. Requirements: (1) discovery brief and success metrics; (2) architecture and data-flow diagram covering trust boundaries, identity, secrets, audit logs, and failure modes; (3) production-quality implementation of the critical path, such as a connector plus workflow assistant or automation; (4) security/compliance notes with data minimization and access model; (5) observability and incident runbook; (6) adoption/change-management plan; (7) product feedback ticket(s) turning field learning into reusable product opportunities; (8) scope-control note explaining what was deferred, why, and who owns follow-up. ## Acceptance criteria - [ ] End-to-end deployment design: Discovery, architecture, data flow, trust boundaries, implementation, and acceptance metrics tell a coherent customer-deployment story. - [ ] Production readiness: Security/compliance, observability, incident response, rollback, handoff docs, and adoption plan are practical enough for customer and internal teams to operate. - [ ] Product and scope judgment: Field learnings become high-quality product feedback, while deferred/custom work is classified with tradeoffs, ownership, and support impact. ## Verification - [ ] Document installation and run commands. - [ ] Record automated checks and their exact commands. - [ ] Add representative output, screenshots, or a short demo where useful. - [ ] Confirm failure paths and known constraints. ## Decision log ### Decision title - Context: - Choice: - Alternatives considered: - Tradeoffs: ## Evidence - Link each rubric criterion to the file, test, or artifact that demonstrates it. ## Known limitations - List what is intentionally out of scope and what should be improved next.