@devtrack-solution/codesdd 1.2.2

package/.sdd/skills/curated/devtrack-api/references/architecture-governance.md

@@ -0,0 +1,219 @@
+# Architecture And Governance
+
+## Mission
+
+This file defines the governance contract for engineering agents working in the DevTrack API. It protects architecture, quality, safety, and continuity across different assistants and automation hosts.
+
+A good result is not only a working patch. A good result is scoped, validated, explainable, secure, reversible when practical, and aligned with the repository architecture.
+
+## Authority
+
+Use this precedence when context conflicts:
+
+1. Current repository files for implementation facts.
+2. Nearest `AGENTS.md` / `AGENT.md` for local agent instructions.
+3. `.sdd/state/*.yaml` for operational state, planning, progress, dependencies, blockers, quality, and handoff.
+4. `.sdd/core/*.md`, `.sdd/planning/*.md`, `.sdd/AGENT.md`, and `.sdd/README.md` as OpenSDD operational views and guides.
+5. Skill reference files as architecture and quality policy.
+6. Historical notes, generated summaries, or legacy docs only when confirmed by current repository evidence.
+
+Do not let old notes override the codebase or OpenSDD. If useful legacy material exists, repatriate the decision into OpenSDD and remove or ignore the legacy artifact.
+
+## Model Neutrality
+
+Keep this skill portable across capable coding assistants and automation hosts.
+
+- Do not depend on a specific model, vendor, chat product, IDE, proprietary runtime, or hidden tool.
+- Do not encode assumptions about model capabilities, context windows, browsing, memory, or private scratchpads.
+- Prefer repository commands, file paths, architecture rules, local configs, tests, and validation evidence over assistant-specific behavior.
+- Treat files under `agents/` as packaging metadata only; do not make architecture guidance depend on them.
+- If an assistant cannot perform a required command, it must report the limitation and use the smallest safe substitute. It must not fabricate output.
+
+## Evidence And Truthfulness
+
+Agents must be conservative with facts.
+
+- Do not invent files, APIs, commands, flags, DTOs, classes, database columns, migrations, package scripts, environment variables, or cloud resources.
+- Verify version-sensitive behavior from local files such as `package.json`, lockfiles, framework configs, migrations, source code, or official documentation when available.
+- When evidence is incomplete, state the assumption and keep the implementation reversible and narrow.
+- Never claim a command passed unless it was actually executed and completed successfully.
+- Never hide failed checks. Either fix the issue or report the failure with the likely cause and impact.
+
+## Required Operational Flow
+
+Before edits:
+
+```bash
+opensdd sdd onboard system
+opensdd sdd next
+```
+
+If `opensdd sdd next` returns a ready or active feature id:
+
+```bash
+opensdd sdd context <FEAT-ID>
+```
+
+Also before edits:
+
+```bash
+git status --short
+```
+
+Rules:
+
+- Read nearest `AGENTS.md` and `AGENT.md` before editing.
+- Inspect nearby files before introducing new patterns.
+- If there is no feature id but the user explicitly asked for work outside SDD, state the exception in the final handoff.
+- Create an OpenSDD insight or feature only when durable follow-up is required.
+- Do not create external context notes, workflow state, backlog, project memory, scratchpads, or handoff stores.
+- Do not use BRV.
+
+The handoff must include command outputs that matter, why no SDD context was loaded when applicable, target files or external directory, key architecture decisions, validation evidence, skipped checks, and residual risk.
+
+## Repository Safety
+
+Protect the worktree and user changes.
+
+- Never overwrite unrelated user changes in a dirty worktree.
+- Do not run broad destructive commands such as `rm -rf`, `git reset --hard`, `git clean -fd`, force pushes, table drops, queue purges, or cloud deletion unless the user explicitly requested that exact class of action and the scope is clear.
+- Prefer precise patches over wholesale rewrites unless replacing the file is safer and the file is fully owned by the task.
+- Do not change generated, vendored, or dependency files unless the task requires it.
+- Do not commit changes unless the user explicitly asks.
+
+## Security And Privacy Baseline
+
+- Never commit real secrets or credentials.
+- Do not print `.env` values, tokens, private keys, connection strings, cookies, authorization headers, or provider credentials in handoff text.
+- Update `.env.example` names when environment variable names change; do not copy real values.
+- Keep authentication, authorization, tenancy, encryption, PII, audit logging, and retention changes explicitly validated.
+- Avoid adding logs that expose personal data, secrets, prompts with sensitive content, internal lifecycle payloads, or full provider responses.
+- Treat LLM prompts, tool schemas, vector-store payloads, and conversation transcripts as sensitive when they can contain business or personal data.
+
+## Project Layers
+
+Canonical folders:
+
+```text
+src/domain
+src/application
+src/presentation
+src/infrastructure
+src/shared
+```
+
+Dependency rules:
+
+- `domain` is the innermost layer. It contains business logic only.
+- `domain` must not import from `application`, `presentation`, or `infrastructure`.
+- `application` orchestrates domain logic. It must not import from `presentation` or concrete infrastructure.
+- `presentation` receives and validates transport input. It depends on `application`; keep it thin.
+- `infrastructure` implements ports and integrates frameworks, TypeORM, AWS, queues, cache, HTTP, LLMs, vector stores, Temporal, and settings.
+- `shared` is for stable cross-cutting primitives, not a dumping ground.
+
+## Application Module Shape
+
+Every module under `src/application/<context>/<module>/` should follow this shape:
+
+```text
+ports/in
+ports/out
+use-cases
+services
+handlers
+agents
+tools
+```
+
+The folders may start empty when the module does not need implementations yet. Do not create ad-hoc `ports` folders outside `ports/in` or `ports/out`.
+
+Current contexts include:
+
+- `src/application/business/*`
+- `src/application/intelligence/*`
+
+## Intelligence Architecture
+
+The canonical intelligence boundary is:
+
+- `src/application/intelligence/conversation/`: omnichannel boundary.
+- `src/application/intelligence/report-chat/`: specialized capability.
+- `src/application/intelligence/common/agent-runtime/`: generic runtime ownership.
+- `src/domain/intelligence/`: single domain aggregate with `business-objects/`, `value-objects/`, and `types/`.
+
+Compatibility only:
+
+- `src/application/intelligence/agents/`
+- `src/shared/agent/`
+
+Do not add new ownership to compatibility layers.
+
+Provider and model rules:
+
+- Provider-specific SDKs, credentials, transport settings, retries, and rate-limit handling belong in infrastructure.
+- Application owns provider-neutral ports, use cases, tool orchestration, and conversation semantics.
+- Domain owns durable business concepts, not prompt mechanics.
+- Prompt templates and tool schemas must not bypass domain or application invariants.
+- Internal agent/tool failures must be handled explicitly and must not leak secrets or internal payloads to presentation.
+
+## AWS Internal Lifecycle Rules
+
+Internal AWS lifecycle integrations stay in:
+
+```text
+src/infrastructure/adapters/aws
+```
+
+They are consumed through application use cases and ports, not public endpoints.
+
+EventBridge Scheduler, EventBridge, SNS, SQS, S3, Secrets Manager, and CloudWatch are infrastructure resources. Do not leak canonical internal lifecycle payloads into `presentation`.
+
+The public EventBridge laboratory may live in:
+
+```text
+src/presentation/rest/aws-integrations
+```
+
+It must use its own test envelope and must not share the canonical internal lifecycle payload.
+
+SQS lab processing belongs in `application`; polling, ack, retry, and DLQ handling belong in `infrastructure/adapters/aws/sqs`.
+
+## Environment Governance
+
+Development AWS uses:
+
+- region: `us-east-1`
+- profile: `devtrack`
+
+Keep `.env` and `.env.example` names synchronized for:
+
+- `AWS_ACCESS_KEY_ID`
+- `AWS_SECRET_ACCESS_KEY`
+- `AWS_S3_BUCKET`
+- `AWS_EVENTBRIDGE_BUS_NAME`
+- `AWS_ORCHESTRATION_SECRET_ID`
+- `AWS_SNS_*`
+- `AWS_SQS_*`
+- `AWS_CLOUDWATCH_NAMESPACE`
+
+Never commit real secrets.
+
+## ORM Decision
+
+Use TypeORM exclusively.
+
+- Do not introduce Prisma.
+- Do not use Prisma templates, migrations, clients, or schema files.
+- Keep domain and application ORM-agnostic.
+- Put ORM decorators and repositories only in infrastructure.
+
+## Change Scope
+
+Keep changes narrowly scoped:
+
+- Add abstractions only when they reduce real duplication or match existing local patterns.
+- Do not refactor unrelated modules while implementing a feature.
+- Preserve user changes in a dirty worktree.
+- When touching docs as part of SDD, update only docs affected by the feature.
+- Prefer simple, observable changes over broad rewrites.
+- Do not change public contracts unless the task requires it and tests/docs are updated accordingly.

package/.sdd/skills/curated/devtrack-api/references/domain-modeling.md

@@ -0,0 +1,359 @@
+# Domain Modeling
+
+## Domain Intent
+
+Domain code expresses business language, invariants, state transitions, and persistence contracts for aggregates. It must remain framework-free and portable.
+
+Domain is the last place where business truth should be guessed. When a rule is unclear, inspect existing domain objects, tests, use cases, and SDD context before adding a new invariant.
+
+## Domain Folder Choices
+
+Use these folders by intent:
+
+```text
+src/domain/<context>/types
+src/domain/<context>/business-objects
+src/domain/<context>/value-objects
+src/domain/<context>/entities
+src/domain/<context>/validators
+src/domain/<context>/events
+src/domain/<context>/repository-ports
+src/domain/<context>/constants
+```
+
+Use `business-objects/` and `value-objects/` for new canonical aggregate work, especially intelligence. Use `entities/` when extending a context that already uses domain entities, such as `pessoas` or `wallets`.
+
+Do not create domain folders for transport, database, provider, prompt, SDK, queue, cache, HTTP, or UI concerns.
+
+## Domain Decision Rules
+
+Before adding a domain artifact, decide:
+
+- Is this a durable business concept or just transport/persistence shape?
+- Does it own invariants or only type information?
+- Is it an aggregate/business object, value object, legacy entity, validator, event, constant, or repository port?
+- Does existing domain language already cover it?
+- Which tests should prove normalization, invalid paths, and immutability?
+
+Keep names in domain language. Avoid DTO, HTTP, ORM, GraphQL, provider, LLM, queue, or database naming unless the business term itself requires it.
+
+## Type Files: `.type.ts`
+
+All domain type files end with `.type.ts`.
+
+Use namespace style when a context has multiple related shapes:
+
+```ts
+/* eslint-disable @typescript-eslint/no-namespace */
+export namespace ExampleType {
+  export type Status = 'draft' | 'active' | 'completed';
+
+  export type Input = {
+    id: string;
+    name: string;
+    status?: Status;
+    createdAt?: Date;
+    updatedAt?: Date | null;
+  };
+
+  export type Output = {
+    id: string;
+    name: string;
+    status: Status;
+    createdAt: Date;
+    updatedAt: Date | null;
+  };
+
+  export type Repository = Output;
+}
+```
+
+Use interfaces for simpler legacy contexts:
+
+```ts
+export type PessoaId = string;
+
+export interface PessoaProps {
+  id: PessoaId;
+  nome: string;
+  email: string;
+  telefone: string;
+  isActive: boolean;
+  imagemUrl?: string | null;
+  createdAt?: Date;
+  updatedAt?: Date | null;
+}
+```
+
+Rules:
+
+- Keep type files framework-free.
+- Prefer domain language over transport/database names.
+- Use `Date` in domain outputs where the domain needs time values.
+- Keep persistence shape explicit as `Repository` when mapping to infrastructure.
+- Avoid DTO, HTTP, ORM, GraphQL, class-validator, provider, SDK, queue, cache, and prompt concepts.
+- Represent optional and nullable values deliberately; do not conflate `undefined` and `null` when persistence depends on the distinction.
+
+## Business Objects: `.bo.ts`
+
+Use `.bo.ts` for aggregate/business objects with behavior and invariants.
+
+Recommended shape:
+
+```ts
+import { GenericBusinessObject } from '@domain/generic-business-object';
+import { BusinessValidationException } from '@domain/exceptions/business-validation.exception';
+import type { ExampleType } from '@domain/example/types/example.type';
+import { ExampleName } from '@domain/example/value-objects/example-name.vo';
+import { ValidationBuilder, type IValidator } from '@shared/domain/validators';
+
+export interface ExampleInterface {
+  readonly value: ExampleType.Output;
+  readonly id: string;
+  readonly name: string;
+  readonly createdAt: Date;
+  readonly updatedAt: Date | null;
+  rename(name: string): Example;
+  toPersistenceObject(): ExampleType.Repository;
+}
+
+export class Example
+  extends GenericBusinessObject<ExampleType.Output>
+  implements ExampleInterface, IValidator
+{
+  constructor(data: ExampleType.Input | ExampleType.Output) {
+    super(Example.loadData(data));
+  }
+
+  static loadData(data: ExampleType.Input | ExampleType.Output): ExampleType.Output {
+    return {
+      ...data,
+      name: ExampleName.create(data.name).getValue(),
+      status: 'status' in data && data.status ? data.status : 'draft',
+      createdAt: data.createdAt ? new Date(data.createdAt) : new Date(),
+      updatedAt: data.updatedAt ? new Date(data.updatedAt) : null,
+    };
+  }
+
+  public validate(props: ExampleType.Output = this.value): void {
+    ValidationBuilder.of({ value: props.id, fieldName: 'id' })
+      .required('Identificador e obrigatorio')
+      .of({ value: props.name, fieldName: 'name' })
+      .required('Nome e obrigatorio')
+      .of({ value: props.createdAt, fieldName: 'createdAt' })
+      .required('createdAt e obrigatorio')
+      .date('createdAt deve ser uma data valida')
+      .build('Example invalido');
+
+    ExampleName.create(props.name);
+  }
+
+  protected transform(props: ExampleType.Output): ExampleType.Output {
+    return {
+      ...props,
+      name: ExampleName.create(props.name).getValue(),
+      createdAt: new Date(props.createdAt),
+      updatedAt: props.updatedAt ? new Date(props.updatedAt) : null,
+    };
+  }
+
+  get id(): string {
+    return this.value.id;
+  }
+
+  get name(): string {
+    return this.value.name;
+  }
+
+  get createdAt(): Date {
+    return new Date(this.value.createdAt);
+  }
+
+  get updatedAt(): Date | null {
+    return this.value.updatedAt ? new Date(this.value.updatedAt) : null;
+  }
+
+  rename(name: string): Example {
+    if (!name.trim()) {
+      throw new BusinessValidationException('Nome invalido', {
+        name: ['Nome e obrigatorio'],
+      });
+    }
+
+    return new Example({
+      ...this.value,
+      name,
+      updatedAt: new Date(),
+    });
+  }
+
+  toPersistenceObject(): ExampleType.Repository {
+    return {
+      id: this.id,
+      name: this.name,
+      status: this.value.status,
+      createdAt: this.createdAt,
+      updatedAt: this.updatedAt,
+    };
+  }
+}
+```
+
+Rules:
+
+- Extend `GenericBusinessObject<T>` when the object owns invariants.
+- Implement `IValidator` when following the canonical BO pattern.
+- Validate before transform through `GenericBusinessObject` constructor behavior.
+- Normalize data in `loadData` or `transform`.
+- Expose read-only getters; clone arrays/objects/dates to avoid external mutation.
+- Business methods should return a new instance unless the surrounding context already uses mutation.
+- `toPersistenceObject()` must return domain persistence data, not a TypeORM entity.
+- Throw domain exceptions, usually `BusinessValidationException`, not HTTP exceptions.
+- Do not inject repositories, services, loggers, config, SDKs, or framework dependencies into domain objects.
+- Do not publish events, send messages, call providers, or persist data from the domain object directly.
+
+## Value Objects: `.vo.ts`
+
+Use `.vo.ts` for normalized, comparable, validated scalar/domain values.
+
+Recommended shape:
+
+```ts
+import { BusinessValidationException } from '@domain/exceptions/business-validation.exception';
+
+export class ExampleName {
+  private constructor(private readonly value: string) {}
+
+  static create(input: string): ExampleName {
+    const normalized = ExampleName.normalize(input);
+
+    if (!ExampleName.isValid(normalized)) {
+      throw new BusinessValidationException('Nome invalido', {
+        name: ['Nome deve ter entre 2 e 120 caracteres'],
+      });
+    }
+
+    return new ExampleName(normalized);
+  }
+
+  static normalize(input: string): string {
+    return String(input ?? '').trim();
+  }
+
+  static isValid(input: string): boolean {
+    return input.length >= 2 && input.length <= 120;
+  }
+
+  getValue(): string {
+    return this.value;
+  }
+
+  toString(): string {
+    return this.value;
+  }
+
+  equals(other: ExampleName): boolean {
+    return this.value === other.value;
+  }
+}
+```
+
+Rules:
+
+- Private constructor.
+- `create`, `normalize`, `isValid`, `getValue`, `toString`, `equals`.
+- Normalize before validating.
+- Keep VOs framework-free.
+- Prefer existing shared VOs when available, such as `Email` and `Telefone`.
+- Avoid returning mutable internal objects. Clone dates, arrays, and object values.
+
+## Validators
+
+Use validators when validation is large or reused:
+
+```text
+src/domain/<context>/validators/<name>.validator.ts
+```
+
+Pattern:
+
+```ts
+import type { PessoaProps } from '@domain/pessoas/types/pessoa.type';
+import { ValidationBuilder } from '@shared/domain/validators';
+
+export class PessoaValidator {
+  static validate(props: PessoaProps): void {
+    ValidationBuilder.of({ value: props.id, fieldName: 'id' })
+      .required('ID deve ser um UUID valido')
+      .uuid('ID deve ser um UUID valido')
+      .build('Business validation failed');
+  }
+}
+```
+
+Presentation validators must not replace domain validators. Presentation validates request shape; domain validates business invariants.
+
+## Repository Ports
+
+Repository ports belong in domain when they represent domain aggregate persistence:
+
+```text
+src/domain/<context>/repository-ports/<name>-repository.port.ts
+```
+
+Pattern:
+
+```ts
+import type { Example } from '@domain/example/business-objects/example.bo';
+
+export const ExampleRepositoryPortSymbol = Symbol('ExampleRepositoryPortSymbol');
+
+export interface ExampleRepositoryPort {
+  save(example: Example): Promise<Example>;
+  findById(id: string): Promise<Example | null>;
+}
+```
+
+Rules:
+
+- Export a `Symbol` and an interface.
+- Return domain objects, not ORM entities.
+- Keep persistence technology out of the port name, except implementation names in infrastructure.
+- Application ports can also describe repositories when the persistence need is application-specific rather than aggregate-owned. Follow existing module patterns.
+- Do not expose query builders, transactions, connection objects, ORM entities, or provider SDK types through domain ports.
+
+## Domain Events
+
+Use domain events for business facts:
+
+```text
+src/domain/<context>/events/<name>-created.event.ts
+```
+
+Keep events serializable and framework-free:
+
+```ts
+export type ExampleCreatedDomainEvent = {
+  exampleId: string;
+  occurredOn: Date;
+};
+```
+
+Rules:
+
+- Events describe something that already happened in business language.
+- Keep payloads minimal and serializable.
+- Publish events from application use cases through an output port.
+- Do not publish from the domain object directly.
+- Do not include secrets, provider raw responses, or transport-specific envelopes in domain events.
+
+## Domain Test Expectations
+
+Domain changes should be covered by focused tests for:
+
+- required fields and invalid values,
+- normalization,
+- immutable getters and cloned mutable values,
+- business methods and state transitions,
+- exception types and relevant error payloads,
+- repository port contracts only when the change alters expected behavior.

package/.sdd/skills/curated/devtrack-api/references/implementation-checklist.md

@@ -0,0 +1,127 @@
+# Implementation Checklist
+
+## Before Editing
+
+- Read nearest `AGENTS.md` and `AGENT.md`.
+- Run `opensdd sdd onboard system`.
+- Run `opensdd sdd next`.
+- Run `opensdd sdd context <FEAT-ID>` if a feature id is available.
+- Check `git status --short`.
+- Inspect nearby files before creating new patterns.
+- Identify user changes in the dirty worktree and avoid overwriting them.
+- If SDD has no ready feature and work proceeds because the user explicitly requested it, state that exception in the final handoff and create an OpenSDD insight/feature only when durable follow-up is required.
+- Do not persist planning, backlog, workflow status, project memory, scratchpad, or handoff in external context stores.
+
+## Task Understanding
+
+- Restate the target outcome internally before editing.
+- Identify whether the change is feature work, bug fix, refactor, docs-only, test-only, or operational support.
+- Confirm the repository evidence needed for version-sensitive behavior.
+- Keep the scope narrow; do not repair unrelated architecture unless it blocks the requested work.
+- Prefer local patterns over generic best practices when both are valid.
+
+## Design Slice
+
+- Identify touched layers.
+- Start from domain unless the task is purely presentation/infrastructure.
+- Decide whether new files belong to `business` or `intelligence`.
+- Decide whether the domain concept is a `.bo.ts`, `.vo.ts`, `.entity.ts`, or only a `.type.ts`.
+- Decide whether persistence needs a domain repository port or an application output port.
+- Decide whether a public endpoint is appropriate. Internal AWS lifecycle work should not get public endpoints.
+- Decide whether the change affects API contracts, migrations, environment variables, queues, LLM tools, prompts, or security-sensitive behavior.
+
+## Domain Pass
+
+- Types end with `.type.ts`.
+- BO files end with `.bo.ts`.
+- VO files end with `.vo.ts`.
+- No Nest, TypeORM, class-validator, HTTP, AWS, queue, cache, LLM, vector store, SDK, or presentation concepts.
+- Invariants live in BO/VO/validator.
+- VOs normalize before validating.
+- BOs expose getters and clone mutable data.
+- Repository ports return domain objects.
+- Domain events are serializable and framework-free.
+- Domain exceptions are used instead of HTTP exceptions.
+
+## Application Pass
+
+- Module shape uses `ports/in`, `ports/out`, `use-cases`, `services`, `handlers`, `agents`, `tools`.
+- Use cases end with `.use-case.ts`.
+- Services end with `.service.ts`.
+- Handlers end with `.handler.ts`.
+- Input ports export `Symbol` plus interface.
+- Output ports export `Symbol` plus interface.
+- Use cases orchestrate domain and ports only.
+- No presentation imports.
+- No concrete infrastructure adapter imports.
+- Floating background promises are explicitly caught.
+- Application module wires providers and exports port symbols.
+- Agent/tool orchestration uses ports and does not expose provider-specific internals.
+
+## Presentation Pass
+
+- One controller per file.
+- One public route method per controller.
+- Controllers inject application input ports.
+- Controllers do mapping only.
+- Presentation validators use class-validator and Swagger for request shape only.
+- No TypeORM entities or repositories.
+- No provider SDKs, queue clients, AWS clients, or LLM clients.
+- No business rules that bypass domain.
+- No internal lifecycle payloads exposed publicly.
+- Module imports `ApplicationModule` and registers controllers.
+
+## Infrastructure And TypeORM Pass
+
+- TypeORM entity ends with `.orm-entity.ts`.
+- Repository ends with `.typeorm-repository.ts`.
+- Mapper ends with `.mapper.ts`.
+- Repository implements a port.
+- Mapper is stateless and maps domain <-> ORM only.
+- New entity is added to TypeORM config, CLI datasource, root module, ORM feature module, and infrastructure module as needed.
+- Migration SQL matches entity decorators.
+- Unique violations are translated to domain/shared exceptions.
+- No Prisma artifacts.
+- Settings remain centralized in infrastructure.
+- Provider credentials, SDK clients, retries, rate limits, queue polling, ack, retry, and DLQ handling stay in infrastructure.
+
+## Imports And Lint Pass
+
+- No relative imports.
+- Use path aliases.
+- Use `import type` for type-only imports.
+- Domain imports only domain/shared-domain.
+- Application imports no presentation or concrete infrastructure.
+- Presentation imports no concrete infrastructure.
+- No unused variables unless intentionally prefixed `_`.
+- No unsafe `any` unless narrowly justified.
+- No unhandled promises.
+- No broad lint disables without a narrow reason.
+
+## Security And Data Pass
+
+- No secrets, tokens, private keys, cookies, credentials, or connection strings are added to code, tests, docs, logs, prompts, or handoff.
+- `.env.example` is updated when variable names change; `.env` real values are not copied.
+- Logs avoid sensitive payloads, raw prompts, full provider responses, and personal data unless existing policy allows it.
+- Auth, authorization, tenancy, encryption, PII, retention, and audit behavior are unchanged unless the task requires it.
+- Destructive operations are not executed unless explicitly requested and scoped.
+- Public endpoints do not expose internal lifecycle envelopes or infrastructure payloads.
+
+## Validation Pass
+
+- Run targeted tests for changed files.
+- Run `pnpm lint` for import/layer/lint-sensitive changes.
+- Run `pnpm build` for module wiring, TypeORM, path aliases, or cross-layer changes.
+- Run e2e only when user-facing behavior needs it or the feature already has e2e coverage.
+- Update SDD quality/frontend impact/finalize only when feature completion is in scope.
+- If a command fails, fix it or report the failure, cause, and impact.
+- Do not claim validation passed without real command output.
+
+## Final Response
+
+- Mention files or areas changed.
+- Mention validation commands and results.
+- Mention skipped checks with a reason.
+- Mention any SDD exception if applicable.
+- Mention residual risk when validation was partial or assumptions remain.
+- Keep the handoff concise, factual, and reproducible.