@geraldmaron/construct 1.0.0

package/skills/devops/cost-optimization.md

@@ -0,0 +1,105 @@
+<!--
+skills/devops/cost-optimization.md — Cloud Cost Optimization — Use this skill when reducing cloud spend, right-sizing resources, or implementin
+
+Use this skill when reducing cloud spend, right-sizing resources, or implementing FinOps practices. ## Cost Visibility
+-->
+# Cloud Cost Optimization
+
+Use this skill when reducing cloud spend, right-sizing resources, or implementing FinOps practices.
+
+## Cost Visibility
+
+### Tagging Strategy
+- Mandatory tags: team, service, environment, cost-center
+- Enforce tagging via policy-as-code; block untagged resource creation
+- Use consistent naming across providers
+- Tag ephemeral resources (CI runners, dev environments) for cleanup automation
+
+### Cost Allocation
+- Map spend to teams, services, and features
+- Separate shared infrastructure costs (networking, logging, security) and distribute fairly
+- Track unit economics: cost per request, cost per user, cost per transaction
+- Report weekly to team leads; monthly to leadership
+
+### Tooling
+- Cloud provider native: AWS Cost Explorer, GCP Billing, Azure Cost Management
+- Third-party: Infracost, Kubecost, CloudHealth, Spot.io
+- FinOps dashboards visible to engineering teams, not just finance
+
+## Right-Sizing
+
+### Compute
+- Analyze CPU and memory utilization over 2+ weeks
+- Target 60-70% average utilization for steady-state
+- Downsize instances with <30% average utilization
+- Use burstable instances (T-series, e2-micro) for variable workloads
+- Auto-scale based on demand; avoid over-provisioning for peaks
+
+### Database
+- Match instance class to actual query load
+- Use read replicas only when read traffic justifies the cost
+- Consider serverless options (Aurora Serverless, DynamoDB on-demand) for variable loads
+- Archive cold data to cheaper storage tiers
+- Right-size connection pools to reduce idle connections
+
+### Storage
+- Lifecycle policies: move to infrequent access after 30 days, archive after 90, delete after retention
+- Compress data before storage
+- Deduplicate where applicable
+- Delete orphaned volumes, snapshots, and unused images
+- Monitor storage growth; alert on unexpected spikes
+
+## Commitment Strategies
+
+### Reserved Instances / Savings Plans
+- Commit to 1-year for stable baseline workloads
+- Cover 60-70% of steady-state with commitments
+- Leave headroom for growth and experimentation
+- Review utilization monthly; exchange underused reservations
+- Use convertible reservations when instance types may change
+
+### Spot/Preemptible Instances
+- Use for fault-tolerant, stateless workloads: CI/CD, batch processing, dev environments
+- Implement graceful handling of interruptions
+- Diversify across instance types and availability zones
+- Savings: 60-90% compared to on-demand
+
+## Architecture Cost Patterns
+
+### Scale to Zero
+- Serverless functions for infrequent or variable workloads
+- Scale Kubernetes deployments to zero during off-hours
+- Shut down development environments outside business hours
+- Use spot instances for non-production environments
+
+### Efficient Data Transfer
+- Minimize cross-region and cross-AZ traffic
+- Use VPC endpoints for AWS service communication
+- Compress payloads between services
+- Cache at the edge to reduce origin traffic
+- Consolidate API calls; avoid chatty microservice communication
+
+### Storage Tiering
+- Hot: SSD, high IOPS for active data
+- Warm: standard storage for recent data
+- Cold: infrequent access for archived data
+- Glacier/Archive: long-term compliance retention
+- Automate transitions with lifecycle policies
+
+## Waste Elimination
+
+- Idle resources: instances running with no traffic
+- Orphaned resources: unattached volumes, unused elastic IPs, stale snapshots
+- Over-provisioned resources: 4 CPUs allocated, 0.5 used
+- Redundant data: multiple copies without retention policy
+- Unused features: load balancers, NAT gateways, reserved capacity not utilized
+
+## FinOps Process
+
+1. **Inform**: visibility into who spends what
+2. **Optimize**: right-size, commit, eliminate waste
+3. **Operate**: continuous monitoring, budget alerts, anomaly detection
+- Set budget alerts at 80% and 100% of monthly target
+- Anomaly detection for unexpected spend spikes
+- Review optimization recommendations weekly
+- Track cost efficiency trends month-over-month

package/skills/devops/data-engineering.md

@@ -0,0 +1,181 @@
+<!--
+skills/devops/data-engineering.md — Data Engineering — 1. **Idempotency**: pipelines can run multiple times without duplicating data
+
+## Core Principles 1. **Idempotency**: pipelines can run multiple times without duplicating data
+-->
+# Data Engineering
+
+## Core Principles
+
+1. **Idempotency**: pipelines can run multiple times without duplicating data
+2. **Observability**: every pipeline run logs row counts, latency, and anomalies
+3. **Data contracts**: producers and consumers agree on schema and SLAs
+4. **Lineage**: know where every column came from and what it feeds
+
+## Pipeline Patterns
+
+### ELT over ETL
+
+Modern data platforms (BigQuery, Snowflake, Redshift) are powerful enough to transform inside the warehouse. Prefer **ELT** (Extract → Load raw → Transform in warehouse):
+
+```
+Source → Airbyte/Fivetran → Raw tables → dbt models → Mart/API
+```
+
+**ETL** (transform before loading) is still appropriate for:
+- PII masking before data leaves the source system
+- Extremely large aggregations that reduce volume significantly
+- Real-time streaming with latency constraints
+
+### Batch pipelines
+
+Use **Apache Airflow** or **Prefect** for orchestration:
+
+```python
+@dag(schedule="@daily", start_date=pendulum.datetime(2024, 1, 1), catchup=False)
+def orders_pipeline():
+  raw = extract_orders()
+  validated = validate_orders(raw)
+  loaded = load_to_warehouse(validated)
+  transform_dbt_models(loaded)
+```
+
+- `catchup=False` prevents backfilling missed runs on deploy
+- Idempotent tasks: use `INSERT OVERWRITE` / `MERGE` instead of `INSERT`
+- Partition by date and process one partition at a time
+
+### Streaming pipelines
+
+Use **Apache Kafka** + **Flink** or **Spark Structured Streaming** for sub-minute latency:
+
+```python
+# Flink example (PyFlink)
+env = StreamExecutionEnvironment.get_execution_environment()
+stream = env \
+  .from_source(kafka_source, WatermarkStrategy.no_watermarks(), "Kafka") \
+  .map(parse_event) \
+  .filter(lambda e: e.type == "order_placed") \
+  .sink_to(warehouse_sink)
+env.execute("Orders Streaming Pipeline")
+```
+
+Watermarks define event-time handling for late-arriving events — configure based on source latency SLA.
+
+## Data Modeling
+
+### Kimball dimensional model (warehouses)
+
+```sql
+-- Fact table: measurements/events at grain
+CREATE TABLE fct_orders (
+  order_id        BIGINT PRIMARY KEY,
+  customer_sk     BIGINT REFERENCES dim_customer(sk),
+  product_sk      BIGINT REFERENCES dim_product(sk),
+  ordered_at      TIMESTAMP,
+  amount_usd      NUMERIC(12,2)
+);
+
+-- Dimension: slowly changing attribute context
+CREATE TABLE dim_customer (
+  sk              BIGINT PRIMARY KEY,    -- surrogate key
+  customer_id     VARCHAR NOT NULL,      -- natural key
+  name            VARCHAR NOT NULL,
+  tier            VARCHAR,
+  valid_from      TIMESTAMP NOT NULL,
+  valid_to        TIMESTAMP,             -- NULL = current
+  is_current      BOOLEAN DEFAULT TRUE
+);
+```
+
+- Facts are narrow (IDs + measures)
+- Dimensions are wide (all attributes about an entity)
+- Slowly Changing Dimension Type 2 (SCD2) tracks historical state via `valid_from`/`valid_to`
+
+### dbt for transformations
+
+```sql
+-- models/marts/fct_orders.sql
+WITH source AS (
+  SELECT * FROM {{ ref('stg_orders') }}
+),
+validated AS (
+  SELECT * FROM source WHERE amount_usd > 0
+)
+SELECT
+  order_id,
+  customer_id,
+  {{ dbt_utils.generate_surrogate_key(['customer_id']) }} AS customer_sk,
+  ordered_at,
+  amount_usd
+FROM validated
+```
+
+- `ref()` builds the DAG automatically
+- `source()` for raw tables with freshness assertions
+- Add `dbt test` assertions: `not_null`, `unique`, `accepted_values`, `relationships`
+- `dbt docs generate && dbt docs serve` for lineage UI
+
+## Data Quality
+
+### At ingestion
+
+- Schema validation: reject records that don't match expected types/nullability
+- Volume checks: alert if row count deviates > 20% from trailing 7-day average
+- Freshness: alert if source hasn't updated within its SLA window
+
+### At transformation
+
+```yaml
+# dbt tests in schema.yml
+models:
+  - name: fct_orders
+    columns:
+      - name: order_id
+        tests: [unique, not_null]
+      - name: amount_usd
+        tests:
+          - not_null
+          - dbt_utils.accepted_range:
+              min_value: 0
+```
+
+### Great Expectations (standalone)
+
+```python
+context.sources.add_pandas_filesystem(name="orders", base_directory="data/")
+validator = context.get_validator(batch_request=..., expectation_suite_name="orders")
+validator.expect_column_values_to_not_be_null("order_id")
+validator.expect_column_values_to_be_between("amount_usd", min_value=0)
+validator.save_expectation_suite()
+```
+
+## Data Contracts
+
+Define and enforce schema agreements between producers and consumers:
+
+```yaml
+# contract: orders-v1.yaml
+name: orders
+version: 1
+schema:
+  - name: order_id
+    type: string
+    nullable: false
+  - name: amount_usd
+    type: number
+    nullable: false
+sla:
+  freshness: 1h
+  availability: 99.5%
+```
+
+Tools: **Soda Core**, **DataHub**, **OpenLineage** for lineage tracking.
+
+## Common Pitfalls
+
+- **No idempotency**: `INSERT` without `ON CONFLICT` or partition-replace duplicates rows on reruns
+- **Wide tables**: adding columns to fact tables without versioning breaks downstream models
+- **Missing backfill strategy**: pipelines without `catchup` support can't recover historical data gaps
+- **Unmonitored late data**: streaming jobs without watermarks silently drop late events
+- **Schema evolution without contracts**: upstream changes break downstream models silently
+- **Full table scans**: no partition pruning on fact tables causes escalating costs

package/skills/devops/database.md

@@ -0,0 +1,95 @@
+<!--
+skills/devops/database.md — Database Patterns — Use this skill when designing schemas, writing migrations, optimizing queries, o
+
+Use this skill when designing schemas, writing migrations, optimizing queries, or selecting databases. ## Schema Design
+-->
+# Database Patterns
+
+Use this skill when designing schemas, writing migrations, optimizing queries, or selecting databases.
+
+## Schema Design
+
+### Relational
+- Normalize to 3NF by default; denormalize deliberately for read performance
+- Every table has a primary key; prefer UUID or ULID for distributed systems
+- Foreign keys enforced at the database level
+- Use appropriate column types; avoid stringly-typed data
+- Add `created_at` and `updated_at` timestamps to all entities
+- Soft delete (`deleted_at`) when audit trail matters
+
+### Document (NoSQL)
+- Model for access patterns, not entity relationships
+- Embed data that is read together
+- Reference data that changes independently or is shared
+- Avoid deeply nested documents (>3 levels)
+- Define a schema even when the database does not enforce one
+
+## Indexing
+
+### When to Index
+- Columns in WHERE, JOIN, ORDER BY, and GROUP BY clauses
+- Foreign key columns (often missed)
+- Columns used in unique constraints
+
+### Index Types
+- B-tree: default, good for equality and range queries
+- Hash: equality only, faster for point lookups
+- GIN/GiST: full-text search, JSONB, arrays, geometric data
+- Partial index: index only rows matching a condition
+- Composite index: column order matters; most selective first
+
+### Anti-Patterns
+- Indexing every column (write overhead, storage waste)
+- Unused indexes (monitor with `pg_stat_user_indexes` or equivalent)
+- Missing index on foreign keys (causes slow joins and cascading deletes)
+
+## Query Optimization
+
+- Always EXPLAIN queries before and after optimization
+- Avoid `SELECT *`; specify only needed columns
+- Use pagination: LIMIT + OFFSET for small datasets, cursor-based for large
+- Avoid N+1 queries: use JOINs, batch fetches, or DataLoader pattern
+- Use CTEs for readability; materialize only when the planner needs help
+- Parameterize queries; never interpolate user input
+
+## Migrations
+
+### Principles
+- Every schema change is a versioned migration
+- Migrations are forward-only in production; rollback via new forward migration
+- Test migrations against a copy of production data
+- Separate schema changes from data migrations
+- Deploy additive schema changes before code changes
+
+### Safe Practices
+- Add columns as nullable or with defaults; never add NOT NULL without a default
+- Add indexes concurrently (`CREATE INDEX CONCURRENTLY` in PostgreSQL)
+- Rename via add-new, migrate-data, remove-old (three deployments)
+- Drop columns only after all code references are removed
+- Lock-free migrations for high-traffic tables
+
+## Connection Management
+
+- Use connection pooling (PgBouncer, HikariCP, or ORM-level)
+- Set pool size based on: CPU cores x 2 + disk spindles (for PostgreSQL)
+- Set connection timeout and idle timeout
+- Monitor active, idle, and waiting connections
+- Close connections cleanly; handle connection loss gracefully
+
+## Backup and Recovery
+
+- Automated daily backups with point-in-time recovery
+- Test restore procedure quarterly
+- Backup retention: minimum 30 days
+- Encrypt backups at rest and in transit
+- Store backups in a different region or provider
+
+## Monitoring
+
+- Slow query log with threshold (100ms typical)
+- Connection pool utilization
+- Replication lag (for read replicas)
+- Table and index bloat
+- Disk usage growth rate
+- Lock contention and deadlock frequency
+- Alert on: replication lag >10s, connection pool >80%, slow query spike

package/skills/devops/dependency-management.md

@@ -0,0 +1,91 @@
+<!--
+skills/devops/dependency-management.md — Dependency Management — Use this skill when managing package upgrades, resolving CVEs, or establishing l
+
+Use this skill when managing package upgrades, resolving CVEs, or establishing lock file and versioning policy. ## Lock File Hygiene
+-->
+# Dependency Management
+
+Use this skill when managing package upgrades, resolving CVEs, or establishing lock file and versioning policy.
+
+## Lock File Hygiene
+
+- Always commit lock files: `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `go.sum`, `Cargo.lock`.
+- Never delete and regenerate a lock file without reviewing the full diff; regeneration silently upgrades all transitive dependencies.
+- Review lock file diffs in PRs for unexpected transitive version changes — these are where supply chain attacks hide.
+- Do not add lock files to `.gitignore`; they are the reproducibility contract for the build.
+- A PR that changes only the lock file (no `package.json` change) warrants careful scrutiny.
+
+## Safe Upgrade Strategies
+
+| Tool | Trigger | Grouping | Auto-merge Policy |
+|---|---|---|---|
+| Dependabot | Daily/weekly schedule | One PR per package by default; group with `groups:` config | Patch: auto-merge if CI passes. Minor: batch weekly, manual review. Major: manual always. |
+| Renovate | Configurable schedule | Group by ecosystem, semver range, or custom regex via `packageRules` | Auto-merge patch and minor with passing CI; use `stabilityDays: 3` to avoid merging on day of release |
+
+Prefer Renovate for complex repos — its `rangeStrategy`, `grouping`, `stabilityDays`, and `automerge` controls are more expressive than Dependabot's.
+
+Always require CI to pass before any auto-merge. Never auto-merge major version bumps.
+
+## Transitive CVE Resolution
+
+Run `npm audit --json` and parse the output. Each finding includes `severity`, `via` (the dependency chain), and `fixAvailable`.
+
+Force a transitive version without upgrading the direct dependency:
+
+In `package.json` (npm/pnpm):
+```json
+"overrides": {
+  "vulnerable-transitive-dep": ">=2.3.1"
+}
+```
+
+In `package.json` (yarn):
+```json
+"resolutions": {
+  "vulnerable-transitive-dep": "2.3.1"
+}
+```
+
+Risks of `npm audit fix --force`: it may install a semver-incompatible version and break the direct dependency. Always run your test suite after applying forced fixes. Prefer manual overrides over `--force` for production packages.
+
+Verify the fix took effect: run `npm ls vulnerable-transitive-dep` and confirm the version in the tree.
+
+## Version Pinning Policy
+
+| Context | Policy | Reason |
+|---|---|---|
+| Production app | Pin exact versions (`"react": "18.2.0"`) | Reproducible builds; no surprise upgrades in prod |
+| Library / published package | `^` for minor, `~` for patch | Consumers need flexibility; too-tight pins create version conflicts |
+| Dev dependencies | `^` acceptable | Test/build tools rarely cause production regressions |
+| Security-critical deps (auth, crypto, TLS) | Pin exact regardless of context | Breaking changes in security libs have outsize impact |
+| CI tool versions (actions, runners) | Pin to SHA or exact tag | Unpinned actions are a supply chain attack surface |
+
+## Vendoring Decisions
+
+Vendor when:
+- Builds must work offline or in air-gapped environments.
+- Supply chain risk is critical and you need full control of the source.
+- You have a stability SLA that cannot tolerate upstream changes.
+
+Go: `go mod vendor` copies all dependencies into `vendor/`; pass `-mod=vendor` to enforce it.
+
+pnpm strict mode: avoid `--shamefully-hoist`; it recreates the flat `node_modules` structure that allows phantom dependency bugs. Use strict mode by default and resolve missing hoisted deps explicitly.
+
+Trade-offs: vendoring increases repo size and creates a maintenance burden to keep vendored copies patched. Weigh against the reproducibility and supply chain benefits for your threat model.
+
+## Audit Workflows
+
+| Ecosystem | Command | CI Integration |
+|---|---|---|
+| Node.js | `npm audit --audit-level=high` | Run on every PR; fail on HIGH+ |
+| Python | `pip-audit` | Run after `pip install`; fail on CRITICAL |
+| Rust | `cargo audit` | Run in CI; fail on CRITICAL |
+| Go | `govulncheck ./...` | Run in CI; fail on CRITICAL |
+
+Severity thresholds:
+- CRITICAL: block CI, block merge, fix immediately.
+- HIGH: block merge; fix before shipping.
+- MEDIUM: open a tracked issue; fix within the current sprint.
+- LOW: log; fix in a batch dependency upgrade PR.
+
+Automate audit on every PR, not just on a schedule. A scheduled audit catches vulnerabilities too late relative to when the dependency was introduced.

package/skills/devops/devsecops.md

@@ -0,0 +1,96 @@
+<!--
+skills/devops/devsecops.md — DevSecOps — Use this skill when integrating security into CI/CD pipelines, managing supply c
+
+Use this skill when integrating security into CI/CD pipelines, managing supply chain risk, or automating security scanning. ## Pipeline Security Stages
+-->
+# DevSecOps
+
+Use this skill when integrating security into CI/CD pipelines, managing supply chain risk, or automating security scanning.
+
+## Pipeline Security Stages
+
+### Pre-Commit
+- Secret scanning: detect credentials before they reach the repo
+- Tools: gitleaks, truffleHog, git-secrets
+- Pre-commit hooks for fast local feedback
+- Block commits containing patterns matching API keys, tokens, certificates
+
+### Build
+- SAST: static application security testing on source code
+- Dependency scanning: check for known CVEs in direct and transitive dependencies
+- License scanning: flag incompatible or unapproved licenses
+- Container image scanning: vulnerabilities in base images and installed packages
+- Fail the build on Critical findings; warn on High
+
+### Test
+- DAST: dynamic scanning against a running instance in CI
+- API security testing: fuzz endpoints, test auth bypass
+- Infrastructure-as-code scanning: misconfigurations in Terraform, CloudFormation, Helm
+- Compliance-as-code: CIS benchmarks, custom policies
+
+### Deploy
+- Image signing and verification (cosign, Notary)
+- Admission controllers enforce signed images only
+- Runtime security policies (Falco, AppArmor, seccomp)
+- Secrets injected from vault at deploy time, not baked into images
+
+### Runtime
+- Runtime application self-protection (RASP) where applicable
+- Container runtime monitoring
+- Network policy enforcement
+- Continuous compliance scanning
+
+## Supply Chain Security
+
+### Dependency Management
+- Pin exact versions in lock files
+- Verify checksums of downloaded packages
+- Use private registries or mirrors for critical dependencies
+- Audit new dependencies before adding: maintainer reputation, download count, known issues
+- Automate dependency updates with PR-based tools (Dependabot, Renovate)
+
+### SBOM (Software Bill of Materials)
+- Generate SBOM in CycloneDX or SPDX format
+- Include in build artifacts
+- Track components across all deployed services
+- Automate SBOM comparison against vulnerability databases
+
+### Container Security
+- Use minimal base images (distroless, Alpine, scratch)
+- Pin base image by digest, not tag
+- Scan images at build and before deployment
+- No secrets in image layers; use runtime injection
+- Run containers as non-root with read-only filesystem where possible
+
+## Secret Management in CI/CD
+
+- Store secrets in the CI/CD platform's secret store or external vault
+- Never print secrets in build logs
+- Mask secret values in CI output
+- Rotate CI/CD secrets on a schedule
+- Audit secret access: who used which secret, when
+
+## Policy as Code
+
+- Define security policies in a machine-enforceable format
+- OPA/Rego for Kubernetes admission control
+- Sentinel or OPA for Terraform plan validation
+- Custom policies for organization-specific requirements
+- Version policies alongside code; review changes via PR
+
+## Metrics
+
+- Mean time to remediate (MTTR) by severity
+- Percentage of builds with zero Critical/High findings
+- Dependency freshness: age of oldest dependency
+- SBOM coverage: percentage of services with current SBOM
+- Secret rotation compliance rate
+- Policy violation trend over time
+
+## Incident Response Integration
+
+- Security findings automatically create tickets in the issue tracker
+- Critical findings trigger immediate notification
+- Runbook for each finding category
+- Post-incident review includes pipeline gap analysis
+- Update pipeline rules based on incident learnings

package/skills/devops/git-workflow.md

@@ -0,0 +1,100 @@
+<!--
+skills/devops/git-workflow.md — Git Workflow — Use this skill when establishing branching strategies, commit conventions, or co
+
+Use this skill when establishing branching strategies, commit conventions, or code integration practices. ## Branching Strategies
+-->
+# Git Workflow
+
+Use this skill when establishing branching strategies, commit conventions, or code integration practices.
+
+## Branching Strategies
+
+### Trunk-Based Development
+- Main branch is always deployable
+- Short-lived feature branches (1-2 days max)
+- Feature flags for incomplete work
+- Best for: teams with strong CI/CD and automated testing
+- Requires: comprehensive test suites, fast builds
+
+### GitHub Flow
+- `main` is always deployable
+- Feature branches created from `main`
+- Pull request for review; merge to `main` after approval
+- Deploy from `main` after merge
+- Best for: most teams, SaaS products
+
+### GitFlow
+- `main` for production, `develop` for integration
+- Feature branches from `develop`, release branches for stabilization
+- Hotfix branches from `main` for urgent fixes
+- Best for: projects with scheduled releases
+- Overhead is high; avoid unless release cadence demands it
+
+## Commit Conventions
+
+### Format
+```
+<type>(<scope>): <description>
+
+<optional body>
+
+<optional footer>
+```
+
+### Types
+- `feat`: new feature
+- `fix`: bug fix
+- `refactor`: code change that neither fixes nor adds
+- `docs`: documentation only
+- `test`: adding or updating tests
+- `chore`: build, CI, dependency updates
+- `perf`: performance improvement
+- `ci`: CI/CD configuration changes
+
+### Rules
+- Subject line: imperative mood, <72 characters
+- Body: explain what and why, not how
+- Footer: reference issues (`Closes #123`) or note breaking changes
+- One logical change per commit
+- Atomic commits: each commit should build and pass tests
+
+## Pull Request Process
+
+1. Branch from the latest base branch
+2. Keep PRs small: <400 lines changed when possible
+3. Self-review before requesting others
+4. Write a description: what changed, why, how to test
+5. Link related issues
+6. All CI checks must pass before merge
+7. At least one approval required
+8. Squash merge for clean history; merge commit when individual commits matter
+
+## Code Review Guidelines
+
+- Review within 24 hours of request
+- Focus on: correctness, security, maintainability, test coverage
+- Use severity labels: Critical, High, Medium, Low
+- Approve with minor comments; block only for Critical/High
+- Praise good patterns; review is not only for finding problems
+
+## Merge Conflict Resolution
+
+- Rebase feature branch on latest base branch frequently
+- Resolve conflicts locally, not in the merge UI
+- Re-run tests after conflict resolution
+- When in doubt, ask the original author
+
+## Release Tagging
+
+- Semantic versioning: MAJOR.MINOR.PATCH
+- Tag releases on `main` after deployment verification
+- Generate changelog from conventional commits
+- Sign tags for authenticity when required
+
+## Repository Hygiene
+
+- Delete merged branches automatically
+- Protect `main`: require PR, require CI, no force push
+- `.gitignore` covers build artifacts, dependencies, environment files
+- No large binaries in the repo; use Git LFS or external storage
+- Commit messages reference issue trackers for traceability