Add dependabot

.github/copilot-instructions.md

@@ -3,7 +3,7 @@ For additional context about technologies to be used, project structure,
 shell commands, and edge-case handling details, read specs/002-multiarch-image-cache/plan.md and treat it as the authoritative implementation context.
 <!-- SPECKIT END -->
 
-<!-- tram0004 instructions start -->
+<!-- project-specific instructions start -->
 
 # Instructions
 
@@ -39,4 +39,4 @@ The `Dockerfile` will be formatted with "here-doc" `RUN` blocks for clarity and
 * Pull requests will be used for all changes, with code review and automated testing before merging.
 * Use `dependabot` to keep dependencies up to date.
 
-<!-- tram0004 instructions end -->
+<!-- project-specific instructions end -->

.specify/memory/constitution.md

@@ -27,30 +27,35 @@ Sync Impact Report
 ## Core Principles
 
 ### I. Reproducible Ruby 2.6 Runtime
+
 All image changes MUST preserve the project goal of producing a Ruby 2.6 container with a
 predictable runtime environment. Changes to Ruby version selection, build flags, or image
 composition MUST be explicit in code and docs, and MUST include rationale in the change set.
 Rationale: consumers rely on consistent behavior from a legacy runtime line.
 
 ### II. Verified jemalloc Integration
+
 The built image MUST use jemalloc for Ruby execution, and each change affecting allocator,
 linking, or runtime startup MUST include a verification step that demonstrates jemalloc is
 active at runtime. Verification evidence MUST be scriptable and repeatable.
 Rationale: allocator behavior is a core feature, not an optional optimization.
 
 ### III. Deterministic Container Build Inputs
+
 Dockerfiles and build scripts MUST minimize non-determinism: dependency sources, package
 install steps, and build arguments MUST be documented and controlled. Network-time-dependent
 or implicit defaults MUST be avoided unless documented as an explicit exception.
 Rationale: deterministic builds reduce breakage and simplify incident recovery.
 
 ### IV. Mandatory Build and Runtime Verification
+
 Every change merged to main MUST pass a minimum verification gate: successful image build,
 Ruby version confirmation, and allocator verification inside the built container. If a change
 alters image size, startup behavior, or package set, the change MUST include impact notes.
 Rationale: container artifacts require runtime validation beyond static review.
 
 ### V. Documentation and Change Traceability
+
 User-visible behavior changes MUST update README usage/build instructions in the same change.
 All non-trivial decisions (base image changes, allocator strategy changes, build flow changes)
 MUST be captured in commit or PR rationale. Unexplained drift between docs and implementation
@@ -67,32 +72,35 @@ Rationale: this repository is operational infrastructure and must remain maintai
 ## Delivery Workflow and Quality Gates
 
 - Pull requests MUST include:
-	- what changed,
-	- how Ruby 2.6 and jemalloc behavior was verified,
-	- and any compatibility risks.
+  - what changed,
+  - how Ruby 2.6 and jemalloc behavior was verified,
+  - and any compatibility risks.
 - Reviewers MUST reject changes that do not include reproducible verification commands/results.
 - Emergency fixes may bypass non-critical polish, but MUST complete verification and
-	documentation updates before release cut.
+  documentation updates before release cut.
 
 ## Governance
 
 This constitution overrides conflicting project process notes.
 
 Amendment process:
+
 - Propose amendments via pull request describing motivation, impact, and migration concerns.
 - At least one maintainer approval is required before merge.
 - Ratified amendments take effect on merge to main.
 
 Versioning policy for this constitution:
+
 - MAJOR: incompatible governance changes or principle removal/redefinition.
 - MINOR: new principle/section or materially expanded obligations.
 - PATCH: clarifications, wording, or typo fixes without semantic impact.
 
 Compliance review expectations:
+
 - Every PR review MUST include a constitution compliance check.
 - Plan, spec, and task artifacts under `.specify/templates/` MUST remain aligned with these
-	principles.
+  principles.
 - Extension command docs under `.specify/extensions/**/commands/` and operational guidance
-	such as `README.md` MUST remain aligned with these principles.
+  such as `README.md` MUST remain aligned with these principles.
 
 **Version**: 1.1.0 | **Ratified**: 2026-06-04 | **Last Amended**: 2026-06-09