Deploy staging fixes

[mottych]

Fix staging deploy blockers: langchain verbose guard, coverage config, aligned dev deps.

[pulumi]

🍹 The Update for mottych/purposepath-coaching-api/dev (at 5232ee4) was successful.

✨ Neo Explanation

A code update is being deployed to the coaching API Lambda function via a new Docker container image. This is a routine deployment that updates only the application code while preserving all infrastructure and data.

Root Cause Analysis

This deployment was triggered by a code change in the repository. The developer modified the application code in the coaching API, which triggered a rebuild of the Docker container image with a new build timestamp (2025-12-25T22:16:03).

Dependency Chain

1. Code changes in the repository caused the Docker image to be rebuilt with a new context digest
2. The new Docker image was pushed to ECR with a different SHA256 digest (55ab98895f... replacing c9c0200edc...)
3. The Lambda function automatically picked up the new container image URI to deploy the updated code

Risk analysis

Low Risk - This is a standard code deployment with no infrastructure changes. The Lambda function is being updated with new application code but retains all its configuration, permissions, and connections to other resources (DynamoDB table, API Gateway). No stateful resources are affected.

Resource Changes

    Name            Type                          Operation
~   coaching-image  docker:index/image:Image      update
~   coaching-api    aws:lambda/function:Function  update

[pulumi]

🍹 The Update for mottych/purposepath-coaching-infrastructure/staging (at 094b9b3) was successful.

✨ Neo Explanation

Refactoring the coaching conversations table to support multi-tenancy with snake_case naming, which requires replacing the DynamoDB table and will delete all existing conversation data.

Root Cause Analysis

This deployment was triggered by a code change in the repository that restructures the DynamoDB table schema for coaching conversations. The developer changed the attribute naming convention from camelCase to snake_case (conversationId → conversation_id, userId → user_id) and introduced a multi-tenant architecture by adding tenant_id as the new partition key with user_id as the range key.

Dependency Chain

The schema changes to the DynamoDB table are fundamental enough that AWS cannot modify the existing table in-place. When you change a table's hash key (partition key) or add/modify global secondary indexes in certain ways, DynamoDB requires a full table replacement. This means:

1. New table created with the updated schema (tenant_id as hash key, new GSI structure)
2. Old table deleted after the new one is provisioned
3. Point-in-time recovery enabled on the new table (previously disabled)
4. The S3 bucket receives minor tag updates but continues operating normally

Risk analysis

HIGH RISK - This operation will replace the DynamoDB table, resulting in permanent data loss. All existing conversation records in the coaching-conversations table will be deleted when the old table is removed. The replacement is necessary because you cannot change a table's partition key on an existing table. If you have production data in this staging environment that needs to be preserved, you must:

1. Export/backup the existing table data before applying this change
2. Apply the infrastructure change to create the new table
3. Migrate and transform the data to match the new schema (including populating the new tenant_id field)

Resource Changes

    Name                     Type                      Operation
+-  coaching-conversations   aws:dynamodb/table:Table  create-replacement
~   coaching-prompts-bucket  aws:s3/bucket:Bucket      update

[pulumi]

🍹 The Update for mottych/purposepath-coaching-api/staging (at 094b9b3) was successful.

✨ Neo Explanation

A code change triggered a new Docker image build and Lambda function update. The deployment updates the running application code without affecting infrastructure or data storage.

Root Cause Analysis

This deployment was triggered by a code change in the repository. The developer modified application code or dependencies, which triggered a Docker image rebuild with a new build timestamp (2025-12-23T18:49:12). The build context digest changed from the previous version, indicating actual file modifications rather than just a re-run of the same code.

Dependency Chain

1. Code changes triggered a new Docker image build (coaching-image)
2. The new image was pushed to ECR with a different SHA256 digest (4973c18... replacing ce80387...)
3. The Lambda function (coaching-api) is updated to reference the new container image URI
4. No downstream resources are affected - this is a contained deployment update

Risk Analysis

Risk Level: Low

This is a standard code deployment with no risky changes. The Lambda function is being updated in-place (not replaced), which means no downtime or resource recreation. Application state is stored in DynamoDB (not part of this update), so there's no risk of data loss.

Resource Changes

    Name            Type                          Operation
~   coaching-image  docker:index/image:Image      update
~   coaching-api    aws:lambda/function:Function  update