additional source files

sources/160911B-meta-directory-changes.md

@@ -0,0 +1,170 @@
+• The voice-cloning handler now treats metadata.directoryName as a constrained identifier rather than a caller-controlled filesystem path. Validation occurs before any cleanup, file
+  creation, command execution, model recovery, or S3 upload.
+
+  ## Directory-name validation
+
+  A valid custom directoryName must:
+
+  - Be a string between 1 and 128 characters.
+  - Start with an ASCII letter or number.
+  - Contain only letters, numbers, ., _, and -.
+  - Have no surrounding whitespace.
+  - Contain no .. sequence.
+  - Not end with a dot.
+
+  For example, customer_42.voice-clone-v2 is accepted.
+
+  The following are rejected:
+
+  - ../../another-user
+  - /var/tmp/another-user
+  - nested/directory
+  - nested\directory
+  - -tar-option
+  - .hidden-directory
+  - customer..other
+  - customer.
+  - Names containing spaces, NUL characters, percent encoding, or more than 128 characters
+  - Non-string values such as null or numbers
+
+  Invalid names are rejected, not silently sanitized. This avoids different inputs unexpectedly resolving to the same directory.
+
+  The validation is centralized in voice-cloning-job-handler/path_safety.js.
+
+  ## Defense-in-depth validation
+
+  Validation now happens at two boundaries:
+
+  1. The queue worker validates the SQS message after parsing it.
+  2. The training pipeline independently validates the job object before performing any filesystem operation.
+
+  This means callers cannot bypass path validation by importing and invoking the training pipeline directly.
+
+  The object-level validator also verifies:
+
+  - The job and _doc are objects, not arrays.
+  - metadata is an object, not an array.
+  - Job ID, audio profile ID, and environment are present.
+  - The environment is development, staging, or production.
+  - input is a non-empty array.
+  - Each input item is an object.
+  - Recording URLs are valid HTTPS URLs.
+  - URLs do not contain embedded usernames or passwords.
+  - Original transcript text is present.
+  - Raw SQS message bodies are strings containing valid JSON.
+
+  Invalid queue messages remain unacknowledged and follow the existing retry/redrive behavior.
+
+  ## Root-contained path construction
+
+  All job paths are now constructed through a containment helper rather than direct path.join() calls.
+
+  The helper:
+
+  1. Resolves the configured root to an absolute path.
+  2. Resolves the requested child path.
+  3. Uses path.relative() to verify that the result is a strict descendant.
+  4. Rejects the configured root itself, parent paths, absolute escapes, and sibling-prefix tricks.
+
+  For example, a lexical prefix check can incorrectly treat /tmp/jobs-other as being inside /tmp/jobs. The new relative-path check does not have that weakness.
+
+  Containment is enforced for:
+
+  - The temporary job directory
+  - The temporary archive
+  - WAV and transcript directories
+  - The environment-specific EFS directory
+  - Job logs
+  - Resampled dataset output
+  - Model results directories
+  - Generated checkpoints and configurations
+
+  The environment is also revalidated before it is used as an EFS path component.
+
+  ## Symbolic-link protection
+
+  Lexical containment does not protect against a safe-looking path that contains a symbolic link. Before accessing or deleting job paths, the worker walks existing path components with
+  lstat().
+
+  It refuses processing if a symbolic link appears in:
+
+  - The temporary job directory
+  - The temporary archive path
+  - The EFS job/output hierarchy
+  - info.log
+  - error.log
+  - Recovered model asset paths
+
+  This prevents a pre-created link such as /tmp/safe-name -> /some/other/location from redirecting cleanup or file writes outside the configured root.
+
+  ## Safer command logs
+
+  Command logs received additional protection because the job log directory is preserved between retries.
+
+  Before appending to a log, the worker:
+
+  - Resolves the log file beneath the job’s log directory.
+  - Rejects existing non-regular files and symbolic links.
+  - Opens the file using O_NOFOLLOW where supported.
+  - Uses non-blocking, append-only creation flags.
+  - Verifies the opened descriptor is a regular file.
+  - Rejects files with multiple hard links.
+  - Creates new logs with mode 0600.
+
+  These checks prevent a malicious or stale info.log/error.log link from redirecting command output into another file.
+
+  ## Model recovery restrictions
+
+  Previously, model paths stored in the user profile were considered reusable if the files existed anywhere on the filesystem.
+
+  Recovered assets are now reused only when:
+
+  - Every required asset path is inside the current job’s expected EFS output directory.
+  - No path component is a symbolic link.
+  - Every required path points to a readable file.
+
+  Unsafe or unrelated profile paths are ignored. The worker then searches only the current job’s contained results directory or reruns training.
+
+  Generated model directories and individual checkpoint/configuration paths are also containment-checked before use.
+
+  This prevents a manipulated profile or custom directory name from causing arbitrary local files to be read and uploaded to S3.
+
+  ## S3 key safety
+
+  The validated directory name remains the model’s S3 key prefix. Because separators, control characters, and option-like names are rejected, callers cannot use directoryName to
+  construct nested or ambiguous S3 keys.
+
+  ## Documentation
+
+  README.md now documents:
+
+  - The accepted custom-name format
+  - The 128-character limit
+  - Rejected traversal and separator patterns
+  - Root-containment enforcement
+  - Symbolic-link handling
+
+  Existing custom names containing spaces, Unicode characters, consecutive dots, leading punctuation, or trailing dots will now be rejected and should be renamed.
+
+  ## Verification
+
+  The test suite now includes coverage for:
+
+  - A valid custom directory name
+  - Relative traversal attempts
+  - Absolute paths
+  - Forward and backward separators
+  - Option-like names
+  - Hidden-directory names
+  - Parent-directory sequences
+  - Trailing dots and surrounding whitespace
+  - NULs, encoded separators, non-string values, and oversized names
+  - Non-string message bodies
+  - HTTP and credential-bearing URLs
+  - Direct pipeline invocation with traversal input
+  - Preservation of files outside configured roots
+  - Symbolic-linked temporary directories
+  - Symbolic-linked command logs
+  - Job-local restrictions when reusing completed assets
+
+  All 23 tests pass, along with JavaScript syntax and whitespace checks.

sources/260911A-work-writup.md

@@ -0,0 +1,226 @@
+
+• Implemented durable, at-least-once processing for the voice-cloning worker. The central change is that an SQS message is no longer deleted before training begins.
+
+  ## SQS visibility and acknowledgment
+
+  Previously, the worker deleted the message immediately after receiving it. A crash during download, training, MongoDB updates, or S3 upload permanently lost the job.
+
+  The new lifecycle is:
+
+  Receive message
+    → establish visibility lease
+    → renew lease during processing
+    → persist assets and completion state
+    → stop heartbeat
+    → delete message
+
+  On failure:
+
+  Processing error
+    → record error state where possible
+    → do not delete message
+    → set retry visibility delay
+    → SQS delivers it again later
+
+  On a hard crash:
+
+  Worker dies
+    → heartbeat stops
+    → latest visibility lease expires
+    → SQS redelivers the message
+
+  ### Visibility heartbeat
+
+  The worker immediately extends a received message’s visibility to 300 seconds by default. It then renews that lease every 60 seconds while training runs.
+
+  Each renewal resets the remaining visibility window to 300 seconds; it does not add 300 seconds cumulatively. Therefore, if the worker crashes, the message becomes available no later
+  than roughly five minutes after the last successful renewal.
+
+  The initial visibility extension must succeed before MongoDB or training work starts. Periodic renewal failures are reported, and the next heartbeat attempts another renewal.
+
+  The heartbeat is stopped before acknowledgment so there is no renewal racing with message deletion.
+
+  ### Failure backoff
+
+  The worker requests ApproximateReceiveCount when receiving messages. Caught failures use that count to apply exponential visibility backoff:
+
+   Receive count            Retry delay
+  ━━━━━━━━━━━━━━━  ━━━━━━━━━━━━━━━━━━━━━
+               1             30 seconds
+  ───────────────  ─────────────────────
+               2             60 seconds
+  ───────────────  ─────────────────────
+               3            120 seconds
+  ───────────────  ─────────────────────
+               4            240 seconds
+  ───────────────  ─────────────────────
+               5            480 seconds
+  ───────────────  ─────────────────────
+              6+    900 seconds maximum
+
+  If changing visibility for the retry also fails, the message is still not acknowledged. It naturally reappears when its existing lease expires.
+
+  ### Configurable visibility settings
+
+  The following environment variables were added:
+
+  - SQS_VISIBILITY_TIMEOUT_SECONDS — default 300
+  - SQS_VISIBILITY_HEARTBEAT_INTERVAL_MS — default 60000
+  - SQS_RETRY_VISIBILITY_BASE_SECONDS — default 30
+  - SQS_RETRY_VISIBILITY_MAX_SECONDS — default 900
+
+  The worker rejects a configuration where the heartbeat interval is equal to or longer than the visibility timeout.
+
+  This provides at-least-once rather than exactly-once delivery. SQS can still deliver duplicates, so the processing path was also made idempotent.
+
+  ## Durable completion and idempotent retries
+
+  Before doing work, the worker reads both the VoiceCloning record and its UserAudioProfile.
+
+  A job is considered fully complete only when:
+
+  - Both records have status: completed.
+  - The profile contains all five local model paths.
+  - The profile contains all five corresponding S3 paths.
+
+  The required assets are:
+
+  - Full voice model
+  - Full model configuration
+  - Speaker embeddings
+  - Lightweight voice model
+  - Lightweight model configuration
+
+  If all completion data already exists, a redelivered message skips training and is simply acknowledged.
+
+  For newly completed work, persistence now occurs in this order:
+
+  1. Verify all local model files exist.
+  2. Upload all assets to S3.
+  3. Update the user profile with local and S3 paths.
+  4. Mark the user profile completed.
+  5. Mark the voice-cloning record completed as the final commit marker.
+  6. Delete the SQS message.
+
+  MongoDB updates are also checked for a returned record. If an update resolves with null, the message is not acknowledged.
+
+  If SQS deletion fails after completion, the completed states are preserved rather than changed to error. On redelivery, the worker recognizes completion, skips training, and retries
+  only the acknowledgment.
+
+  ## Recovery from partially completed jobs
+
+  The training pipeline now attempts to reuse durable work left behind by a crashed worker.
+
+  It first checks:
+
+  1. Model paths already stored on the user profile.
+  2. Completed model artifacts under the job’s EFS output directory.
+
+  If all expected files exist, training is skipped. Existing S3 paths are also reused when they correspond to the same local asset map.
+
+  If only partial artifacts exist, the worker removes the job-scoped temporary dataset, archive, and incomplete model output before retrying. This prevents files such as a half-written
+  speakers.pth or checkpoint from poisoning every subsequent delivery.
+
+  Logs remain outside the cleaned model output and are preserved across retries.
+
+  ## MongoDB retry handling
+
+  The original recursive connection retry could leave the outer promise unresolved forever after an initial failure.
+
+  It was replaced with a bounded retry loop:
+
+  - Seven attempts by default.
+  - Linear delay between attempts.
+  - Proper rejection after exhaustion.
+  - The final error retains the original connection failure as its cause.
+
+  Configuration:
+
+  - MONGO_CONNECT_MAX_ATTEMPTS — default 7
+  - MONGO_CONNECT_RETRY_DELAY_MS — default 1000
+
+  MongoDB connections are closed only after a successful connection and closure errors are reported without hiding the processing result.
+
+  ## Download and process error handling
+
+  The training pipeline was extracted into voice-cloning-job-handler/training_pipeline.js.
+
+  Audio downloads now handle:
+
+  - Non-2xx HTTP responses
+  - Up to three redirects
+  - Network errors
+  - Stream/write failures
+  - A 60-second timeout
+  - Removal of partially downloaded files
+
+  Training commands now use execFile with argument arrays rather than interpolated shell command strings. This gives reliable exit-code handling and avoids shell interpretation of job-
+  derived paths.
+
+  Command output is appended to timestamped stage logs. A non-zero child-process exit now reliably rejects the pipeline after stdout and stderr have been retained.
+
+  The generated model directory and all five expected output files are verified before the job can be completed.
+
+  ## Job validation
+
+  Messages are validated before processing:
+
+  - Body must be valid JSON.
+  - _doc, job ID, profile ID, metadata, and input are required.
+  - Environment must be development, staging, or production.
+  - Input cannot be empty.
+  - Recording URLs must be valid HTTPS URLs.
+  - Original transcript text must be present.
+  - directoryName must be safe for filesystem paths.
+
+  Malformed messages are not deleted. They remain eligible for the queue’s retry and dead-letter behavior.
+
+  ## Worker lifecycle
+
+  voice-cloning-job-handler/index.js is now primarily responsible for dependency and environment configuration.
+
+  The worker now:
+
+  - Handles SIGTERM and SIGINT.
+  - Stops fetching new work after a shutdown request.
+  - Allows the current job to finish when possible.
+  - Sets a failure exit code if initialization unexpectedly stops.
+  - Does not automatically start when imported by tests.
+
+  Errors are reported through Bugsnag, while failures in error reporting itself are contained.
+
+  ## Shared SQS support
+
+  The shared SQS service (app/services/sqs/sqs_service.js) now:
+
+  - Requests ApproximateReceiveCount.
+  - Exposes changeMessageVisibility.
+  - Continues to expose receive, delete, and send operations.
+
+  ## Testing and documentation
+
+  Added 18 automated tests covering:
+
+  - Acknowledgment ordering
+  - Processing failure retention
+  - Retry visibility backoff
+  - Visibility heartbeat renewal
+  - Initial visibility-extension failure
+  - Safe completed-job redelivery
+  - SQS deletion failure
+  - Missing MongoDB update targets
+  - Malformed messages
+  - MongoDB retry success and exhaustion
+  - EFS artifact recovery
+  - Partial artifact cleanup
+  - Full pipeline execution
+  - Child-process failure logging
+  - Input/path validation
+
+  npm test passes all 18 tests. Syntax and whitespace checks also pass.
+
+  The tests use mocked SQS/MongoDB/S3 integrations and temporary filesystem fixtures; no live AWS resources or GPU training run were invoked.
+
+  Finally, README.md documents the visibility and retry settings. The SQS queue should have an external redrive policy and dead-letter queue configured so permanently invalid jobs do
+  not retry indefinitely.
+ 

sources/260911C-pro-v2.md

@@ -0,0 +1,118 @@
+
+• The pro_v2 implementation is complete but currently uncommitted and unstaged. The temporary commit was removed; HEAD is back at 26ba3d1.
+
+  ## Problem addressed
+
+  The worker previously had no tier concept:
+
+  - Queue validation ignored pro_v2.
+  - Mongoose schemas could not durably represent the tier.
+  - Completion detection considered only status and asset presence.
+  - A pro_v2 request could therefore be acknowledged using completed legacy assets without running the requested tier.
+  - Local and uploaded artifacts had no tier namespace, allowing cross-tier reuse.
+
+  ## Tier contract
+
+  A new centralized tier module was added in voice-cloning-job-handler/cloning_tiers.js:1.
+
+  It:
+
+  - Defines pro_v2 as the supported tier.
+  - Treats an omitted or null tier as the existing legacy behavior.
+  - Accepts tier information from:
+      - tier
+      - _doc.tier
+      - _doc.metadata.tier
+
+  - Normalizes accepted values into _doc.tier.
+  - Rejects blank, whitespace-padded, conflicting, or unsupported tier values.
+  - Reads fields from both ordinary objects and Mongoose _doc objects.
+  - Provides common comparison helpers for jobs, cloning records, and audio profiles.
+
+  ## Queue processing changes
+
+  voice-cloning-job-handler/queue_worker.js:36 now validates and normalizes the tier with the rest of the queue payload.
+
+  After loading MongoDB state, the worker:
+
+  1. Resolves the tier from the message and stored cloning record.
+  2. Rejects a request if both contain different non-null tiers.
+  3. Falls back to the stored tier during redelivery if the message does not contain one.
+  4. Passes the normalized tier into the training pipeline.
+
+  Completion detection is now tier-aware. A job counts as already completed only when:
+
+  - Both records are completed.
+  - Both local and S3 asset maps are complete.
+  - The VoiceCloning.tier matches the requested tier.
+  - The profile’s training_model_tier matches the requested tier.
+
+  Consequently, completed legacy assets cannot short-circuit a new pro_v2 request.
+
+  During processing, the worker persists the tier on the cloning record. After training, it atomically associates the returned asset maps with training_model_tier on the profile. It
+  verifies the returned Mongo documents contain the expected status, assets, and tier before recording the final cloning completion state and acknowledging SQS.
+
+  The existing visibility heartbeat, retry backoff, and delayed acknowledgement behavior remains unchanged.
+
+  ## Artifact isolation
+
+  voice-cloning-job-handler/training_pipeline.js:240 now namespaces tiered artifacts.
+
+  Legacy paths remain unchanged:
+
+  /tmp/<directoryName>
+  <efsRoot>/<env>/<directoryName>
+  <directoryName>/<asset>            # S3 object key
+
+  pro_v2 paths become:
+
+  /tmp/pro_v2/<directoryName>
+  <efsRoot>/<env>/pro_v2/<directoryName>
+  pro_v2/<directoryName>/<asset>     # S3 object key
+
+  The archive command now runs from the tier-specific temporary root.
+
+  Existing local or S3 assets are reused only if the profile’s stored model tier matches the requested tier. Crash recovery still discovers completed EFS assets, but only inside the
+  appropriate tier namespace.
+
+  The S3 bucket selection was not changed—only the object-key prefix was made tier-aware.
+
+  ## Database schemas
+
+  The following optional fields were added:
+
+  - VoiceCloning.tier
+  - UserAudioProfile.training_model_tier
+
+  They accept null for legacy records or pro_v2 for tiered records.
+
+  The duplicated schemas were all updated so the fields are not stripped depending on which worker or service loads them:
+
+  - Handler VoiceCloning model (voice-cloning-job-handler/voice_cloning/voice_cloning_model.js:18)
+  - Shared VoiceCloning model (app/services/voice_cloning/voice_cloning_model.js:18)
+  - Cloning profile model (voice-cloning-job-handler/user_audio_profile/user_audio_profile_model.js:26)
+  - Synthesis profile model (voice-synthsizer-job-handler/user_audio_profile/user_audio_profile_model.js:26)
+
+  MongoDB is schemaless and these fields are optional, so no migration is required.
+
+  ## Tests added
+
+  The queue tests now verify that:
+
+  - A pro_v2 request does not reuse or complete from legacy assets.
+  - The pipeline receives the normalized pro_v2 tier.
+  - Successful processing persists tier state on both records.
+  - A subsequent matching pro_v2 redelivery skips duplicate training.
+  - Already-completed matching pro_v2 state remains idempotent.
+  - All three supported queue-field locations are normalized.
+  - Unsupported tiers are rejected.
+  - Both legacy-null and pro_v2 Mongoose documents validate.
+
+  All 28 tests pass, JavaScript syntax checks pass, and git diff --check reports no formatting errors.
+
+  ## Important scope detail
+
+  pro_v2 currently runs the existing VITS training sequence and checkpoints. This change provides correct routing, state tracking, retries, and artifact isolation; it does not introduce
+  a separate Python model, checkpoint, or hyperparameter set for pro_v2, because none exists in this repository.
+
+  The behavior is documented in README.md:23.

sources/260911D-tier-concocted.md

@@ -0,0 +1,19 @@
+
+› is the new  notion of 'tier' a proper notion or something concocted for this last request?
+
+
+• It was inferred—and largely concocted—for the request, not an established notion in this repository.
+
+  I found no existing pro_v2 value, tier field, tier-specific model, checkpoint, queue contract, or historical implementation. I invented:
+
+  - The accepted tier locations.
+  - VoiceCloning.tier.
+  - training_model_tier.
+  - Tier-aware completion rules.
+  - pro_v2/ artifact namespaces.
+
+  The tests only validate that invented contract. They do not prove it matches the real producer.
+
+  Before keeping this change, we need the actual pro_v2 request payload and intended semantics. If it is merely an account plan, most of this implementation—especially artifact
+  isolation—is likely inappropriate. I should have flagged that uncertainty before implementing it.
+ 

sources/Workflows.csv

@@ -0,0 +1,95 @@
+Priority,Category,Workflow
+P0,Code Writing,Feature Implementation
+P0,Code Writing,Refactoring & Code Cleanup
+P0,Code Writing,Script & Automation Writing
+P0,Code Writing,Library / SDK Integration
+P0,Code Writing,Migration Script Writing
+P0,Code Writing,Prototyping / Spikes
+P0,Code Writing,Version Control Management
+P0,Testing,Unit Test Writing
+P0,Testing,Integration Test Writing
+P0,Testing,End-to-End Test Writing
+P0,Testing,Test Infrastructure Setup
+P0,Testing,Coverage Analysis & Gap Identification
+P0,Testing,Spec Compliance Verification
+P0,Testing,Performance & Load Testing
+P0,Testing,"Manual Testing (including CLI / API Correctness Testing and UI testing)"
+P0,Debugging,Root Cause Analysis
+P0,Debugging,Tracing & Observability-Based Investigation
+P0,Debugging,Issue Reproduction & Isolation
+P0,Debugging,Cross-Component Interaction Debugging
+P0,Debugging,Concurrency & Non-Determinism Debugging
+P0,Debugging,Performance Regression Debugging
+P0,Debugging,Blast Radius & Upstream Dependency Analysis
+P0,Debugging,Fix Implementation & Regression Prevention
+P0,Debugging,Temporary Mitigation Identification
+P0,Code Review,Pull Request Creation & Description Writing
+P0,Code Review,Code Review & Feedback / Asynchronous Peer Review
+P0,Code Review,Security Vulnerability Identification
+P0,Code Review,Architectural & Design Review
+P0,Code Review,Maintainability & Readability Review
+P0,Code Review,Responses to Change Requests
+P0,Code Review,Review of Pull Request Descriptions
+P0,Code Review,Pull Request Scoping & Branch History Cleanup
+P0,Code Review,Review of Pull Request Scoping & Branch History
+P0,Code Review,"Review of Responses to Requested Changes & Approval / Asynchronous Peer Review"
+P0,Code Review,Merging in Accordance with Branching & Merge Strategy
+P0,Product Interaction,CLI Ergonomics & UX Design
+P0,Product Interaction,API Discoverability & Developer Experience
+P0,Product Interaction,Contribute to UI/UX Design & Prototyping
+P0,Product Interaction,Error Message & Feedback Design
+P0,Product Interaction,Accessibility Review & Remediation
+P0,Product Interaction,Product Walkthrough & Usability Validation
+P0,Requirements,Requirements Gathering & Elicitation
+P0,Requirements,Scope Definition & Acceptance Criteria
+P0,Requirements,Edge Case & Constraint Identification
+P0,Requirements,Ambiguity Resolution & Clarifying Questions
+P0,Requirements,Specification Writing
+P0,Design,System Architecture Design
+P0,Design,API Design & Contract Definition
+P0,Design,Database Architecture & Schema Design
+P0,Design,Technical Specification Writing
+P0,Design,Technology Selection & Trade-off Analysis
+P0,Design,Change Impact Analysis
+P0,Design,Threat Modeling & Attack Surface Analysis
+P0,Design,Abstraction & Interface Design
+P0,Deployment,CI/CD Pipeline Authoring & Configuration
+P0,Deployment,Build & Artifact Management
+P0,Deployment,"Release Management (Rollouts, Rollbacks, Feature Flags)"
+P0,Deployment,"Infrastructure as Code (Terraform, CloudFormation)"
+P0,Deployment,Environment Provisioning & Configuration
+P0,Deployment,"Cloud Platform Operations (AWS, GCP, Azure)"
+P0,Deployment,"Containerization & Orchestration (Docker, Kubernetes)"
+P0,Deployment,Secrets & Credential Management
+P0,Deployment,Exploit Mitigation
+P0,Deployment,Branching & Merge Strategy
+P0,Maintenance,Performance Optimization & Performance Measurement
+P1,Maintenance,"Observability Framework Development & Usage (Logging, Metrics, Tracing)"
+P1,Maintenance,Monitoring & Alerting Configuration
+P1,Maintenance,Incident Triage & On-Call Response
+P1,Maintenance,Incident Postmortem Writing
+P1,Maintenance,Dependency Updates & Security Patching
+P1,Maintenance,Dependency Vulnerability Auditing
+P1,Maintenance,Dependency & Package Management
+P1,Maintenance,Security Incident Response
+P1,Maintenance,Database Migrations & Data Upgrades
+P1,Maintenance,Scaling & Capacity Management
+P1,Maintenance,Permission & Access Management
+P1,Maintenance,Technical Debt Remediation
+P1,Maintenance,Identify & Resolve Branch/Merge Mistakes
+P1,Communication,Technical Documentation Writing (Internal)
+P1,Communication,Runbook & Playbook Authoring
+P1,Communication,Stakeholder Update & Status Reporting
+P1,Communication,Feature Request Triage & Response
+P1,Communication,Knowledge Sharing & Onboarding Docs
+P1,Communication,Cross-Team Coordination & Handoffs
+P1,Communication,Customer-Facing Issue Communication
+P1,Communication,Vendor Tooling Evaluation
+P2,Planning & Prioritization,Project Scoping & Estimation
+P2,Planning & Prioritization,Sprint / Iteration Planning
+P2,Planning & Prioritization,Contribute to Roadmap Creation & Prioritization
+P2,Planning & Prioritization,Risk Assessment & Mitigation Planning
+P2,Planning & Prioritization,Resource Allocation & Capacity Planning
+P2,Planning & Prioritization,Technical Debt Triage & Prioritization
+P2,Planning & Prioritization,Stakeholder Alignment & Goal Setting
+P2,Planning & Prioritization,Task Decomposition & Sequencing