From 92f9f60a6c915dcd873415352ae3abf178342baa Mon Sep 17 00:00:00 2001 From: Dmitry Smirnov Date: Fri, 17 Apr 2026 19:42:58 +0300 Subject: [PATCH 1/4] Worker Upgrade --- .rabbit/context.yaml | 106 +++++++++++++++++++++++++++++++++++++++++++ AGENTS.md | 95 ++++++++++++++++++++++++++++++++++++++ Dockerfile | 6 +-- 3 files changed, 204 insertions(+), 3 deletions(-) create mode 100644 .rabbit/context.yaml create mode 100644 AGENTS.md diff --git a/.rabbit/context.yaml b/.rabbit/context.yaml new file mode 100644 index 0000000..9623322 --- /dev/null +++ b/.rabbit/context.yaml @@ -0,0 +1,106 @@ +# Generated by dev.kit repo — do not edit manually. +# Run `dev.kit repo` to refresh. +kind: repoContext +version: udx.io/dev.kit/v1 +generated: 2026-04-17 + +repo: + name: worker-nodejs + archetype: runtime-image + profile: container + +refs: + - ./README.md + - ./.rabbit + - ./.github/workflows + - ./Makefile + - ./Dockerfile + - ./deploy.yml + - ./src + +commands: + verify: make test + build: make build + run: make run + +# Gaps — factors that are missing or partial +gaps: + - dependencies (partial) + +# Engineering practices +practices: + - "Keep the repository as the primary source of truth so context-driven engineering comes from repo contracts, docs, tests, config, and repo-native notes instead of agent memory." + - "Prefer repo-centric mechanisms that discover workflows, tools, formats, and refs dynamically instead of hardcoding per-agent assumptions." + - "Keep markdown, yaml, diagrams, tests, and command contracts self-contained in the repo so local and remote UDX workflows stay aligned." + - "Keep deterministic workflow logic in repo config and scripts, and reserve AI agents for reading that contract, generating grounded summaries, and handling non-deterministic judgment without inventing hidden rules." + - "Operate from repo-declared context at all times. Do not carry assumptions across sessions or rely on prompt history when the repo contract is available on disk." + - "After loading the repo contract, prefer current GitHub issues, pull requests, review state, and commit history as the primary dynamic source for agent decisions. Use repo workflow and practice catalogs as fallback defaults when live GitHub signal is missing or thin." + - "When understanding behavior, read the YAML manifest that defines it before reading the code that implements it. Manifests are the interface — code is the mechanism." + - "Check existing org patterns, configs, workflows, and templates before creating new ones. Reuse declared patterns instead of inventing alternatives." + - "Detect the repo's canonical verification surface from context, but prefer GitHub workflow executions and monitor their outcomes when the repo already has CI coverage. Use local verification for quick scoped debugging, missing CI coverage, or reproducing workflow failures." + - "Keep the delivery chain explicit — branch, PR, and issue must be connected before close-out. Do not treat any step as done until the link to the next step is visible." + - "Report outcomes with exact URLs, versions, findings deltas, and next steps so follow-up can be reused by humans and agents without drift." + - "Use README, docs, and tests as the first alignment surface before broad refactors. Read the declared workflow before changing the implementation." + - "Do not require custom repo files for dev.kit to work. Prefer standard engineering signals such as README, docs, tests, manifests, workflows, and deployment config, with dev.kit-owned continuity treated as optional acceleration only." + - "Express repo rules in YAML manifests first, then keep shell glue thin and composable. Policy belongs in config, not buried in imperative scripts." + - "When a new direction is accepted, archive or delete conflicting old modules and configs instead of carrying both models forward." + - "If local verification is needed, run the smallest local check that proves the current change. Prefer broader or slower coverage in GitHub workflows, monitor the workflow run, and call the tradeoff out explicitly." + - "Make sure to develop and test incrementally, so it is easier to detect problems early and build on verified behavior." + - "Make sure to protect development executions with scoped and limited tasks, so failures are easier to isolate and blast radius stays low." + - "Use the linked GitHub issue as the cross-repo context root. When work spans multiple repos, the issue URL anchors scope, acceptance criteria, and follow-up across all of them." + +# Canonical agent workflow +workflow: + - "Refresh repo context: Run `dev.kit` → `dev.kit repo` → `dev.kit agent` before starting work. Each command guides to the next required step. This resyncs repo context, environment state, and the AGENTS.md execution contract. A current context.yaml is the source of truth for refs, commands, gaps, and lessons. Do not rely on ad hoc prompt memory when the repo contract can be read from disk. When GitHub context is available, prefer current issues, pull requests, review state, and commit history over stale memory or generic workflow defaults." + - "Read linked GitHub issue and confirm scope: If a GitHub issue URL is available, read the full body and comments, confirm the repo matches the issue scope, and map acceptance criteria before writing any code. Use the issue URL as the cross-repo context root." + - "Inspect git status" + - "Analyze local changes" + - "Analyze branch state" + - "Group logical commits" + - "Bump version and changelog if supported" + - "Create or validate feature branch" + - "Push branch to remote" + - "Generate pull request description: Pick the PR template type from src/configs/github-prs.yaml (feature, deployment, ops, hotfix). Fill every required section. Include \"Closes #N\" for linked issues. Add a \"Backlog from this investigation\" section for any new gaps found. Use .github/PULL_REQUEST_TEMPLATE.md as the base form." + - "Create pull request" + - "Monitor related workflow executions: After PR creation, monitor the related GitHub workflow runs and status checks. Open the run details when needed, watch for failed or stuck jobs, and treat GitHub workflow execution as the primary verification path when the repo already has CI coverage." + - "Loop automated review feedback: After PR creation, wait for Copilot, Devin, and CodeQL reviews. Read each review from github-prs.yaml bot guidance. Address actionable findings with code changes, reply to each bot comment, and resolve the thread when handled. Repeat this loop after each push until bot feedback is clean. Do not request human review while bot findings are unaddressed." + - "Verify required status checks: All required checks must pass before requesting human review. For infra PRs, open check details and review the Terraform plan output. For CodeQL, review findings in the Security tab. When the repo already has GitHub workflow coverage, prefer those executions as the primary verification path and monitor them closely. Use local verification to reproduce failures or cover gaps, not as a universal gate." + - "Post close-out comment on linked issue: After PR is created, post a brief comment on the linked issue with the PR URL, what changed, and any follow-up items. GitHub auto-closes the issue on merge when \"Closes #N\" is in the PR body — do not close manually." + - "Post-merge close-out and backlog: After merge: verify issue auto-closed, post close-out comment, open issues for any backlog items from the PR, verify monitoring changes are live. See post_merge steps in github-prs.yaml." + +# External dependencies — cross-repo and upstream references +# Trace these to find infrastructure, deployment, and build logic outside this repo. +# Same-org deps are resolved with metadata. External deps listed for agent reference. +dependencies: + - repo: actions/checkout + type: github action + resolved: false + used_by: + - .github/workflows/codeql.yml + - .github/workflows/tests.yml + - repo: udx/reusable-workflows + type: reusable workflow + resolved: true + archetype: workflow-repo + profile: unknown + used_by: + - .github/workflows/context7_sync.yml + - .github/workflows/docker-ops.yml + - repo: usabilitydynamics/udx-worker:0.41.0 + type: base image + resolved: true + source_repo: udx/worker + archetype: runtime-image + profile: container + used_by: + - Dockerfile + +# Config manifests — traceable workflow and tooling dependencies +# Read these to understand what controls repo behavior before reading shell code. +manifests: + - .github/workflows/codeql.yml + - .github/workflows/context7_sync.yml + - .github/workflows/docker-ops.yml + - .github/workflows/tests.yml + - deploy.yml + diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..8ccaf79 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,95 @@ +# AGENTS.md + +_Auto-generated by `dev.kit agent`. Sources: `.rabbit/context.yaml`, GitHub history, lesson artifacts._ + +## Contract + +This repository is a deterministic execution contract. Agents MUST interpret declared context — no scanning, no guesswork, no invention. + +### Rules + +1. **Do NOT scan the filesystem.** No `find`, `ls -R`, `glob`, or recursive directory walks. All paths you need are listed below. +2. **Context boundaries are strict.** Read only files in Priority refs and Config manifests. If a file is not listed, do not read it unless a listed file explicitly references it. +3. **Manifests before code.** When you need to understand behavior, read the YAML manifest that defines it — not the code that implements it. Manifests are the interface. +4. **Context over memory.** Operate from repo-declared context. Do not carry assumptions from prior sessions or rely on prompt history when the contract is on disk. +5. **Prefer workflow verification, not automatic local enforcement.** Detect the repo verify command from `context.yaml`, prefer GitHub workflow executions when the repo already has CI coverage, and use local verification to reproduce failures, debug quickly, or cover workflow gaps. +6. **Follow the Workflow below.** Do not invent ad hoc steps or skip phases. The workflow is the execution sequence. +7. **Reuse over invention.** Check existing org patterns, configs, and workflows before creating new ones. +8. **Prefer live GitHub experience over generic defaults.** After loading the repo contract, use current issues, pull requests, review state, and commit history as the primary dynamic source. Fall back to workflow and practice catalogs when GitHub signal is missing, thin, or irrelevant. +9. **Remember this context.** If your agent supports persistent memory, save that this repo uses `dev.kit` for context management. Start every session — or after merges, config changes, or workflow updates — by running: `dev.kit` → `dev.kit repo` → `dev.kit agent`. Each command guides to the next required step. This resyncs repo context, environment state, and the execution contract before any work begins. + +## Repo: worker-nodejs + +- archetype: runtime-image +- profile: container +- context: ./.rabbit/context.yaml + +### Commands + +``` + verify: make test + build: make build + run: make run +``` + +## Use context.yaml + +All refs, config manifests, command surfaces, dependencies, and gaps live in `.rabbit/context.yaml`. + +Do not duplicate that inventory here. Read `context.yaml` first, then use this file for operating rules, workflow, and dynamic guidance. + +### Gaps + +Incomplete factors. Address within the workflow, not as separate tasks. + + - dependencies (partial) + +## Versioned workflow artifacts + +`.rabbit/` contains generated context downstream of repo signals. These are versioned artifacts, not primary sources. + + - `.rabbit/context.yaml` — generated execution contract (source of truth for this file) + +## Workflow + +The dev.kit lifecycle: **repo → agent → work → PR → merge**. Follow these steps in order. Use them as repo-declared defaults when live GitHub context does not provide a more specific current signal. Steps with notes contain operational guidance. + + - Refresh repo context: Run `dev.kit` → `dev.kit repo` → `dev.kit agent` before starting work. Each command guides to the next required step. This resyncs repo context, environment state, and the AGENTS.md execution contract. A current context.yaml is the source of truth for refs, commands, gaps, and lessons. Do not rely on ad hoc prompt memory when the repo contract can be read from disk. When GitHub context is available, prefer current issues, pull requests, review state, and commit history over stale memory or generic workflow defaults. + - Read linked GitHub issue and confirm scope: If a GitHub issue URL is available, read the full body and comments, confirm the repo matches the issue scope, and map acceptance criteria before writing any code. Use the issue URL as the cross-repo context root. + - Inspect git status + - Analyze local changes + - Analyze branch state + - Group logical commits + - Bump version and changelog if supported + - Create or validate feature branch + - Push branch to remote + - Generate pull request description: Pick the PR template type from src/configs/github-prs.yaml (feature, deployment, ops, hotfix). Fill every required section. Include "Closes #N" for linked issues. Add a "Backlog from this investigation" section for any new gaps found. Use .github/PULL_REQUEST_TEMPLATE.md as the base form. + - Create pull request + - Monitor related workflow executions: After PR creation, monitor the related GitHub workflow runs and status checks. Open the run details when needed, watch for failed or stuck jobs, and treat GitHub workflow execution as the primary verification path when the repo already has CI coverage. + - Loop automated review feedback: After PR creation, wait for Copilot, Devin, and CodeQL reviews. Read each review from github-prs.yaml bot guidance. Address actionable findings with code changes, reply to each bot comment, and resolve the thread when handled. Repeat this loop after each push until bot feedback is clean. Do not request human review while bot findings are unaddressed. + - Verify required status checks: All required checks must pass before requesting human review. For infra PRs, open check details and review the Terraform plan output. For CodeQL, review findings in the Security tab. When the repo already has GitHub workflow coverage, prefer those executions as the primary verification path and monitor them closely. Use local verification to reproduce failures or cover gaps, not as a universal gate. + - Post close-out comment on linked issue: After PR is created, post a brief comment on the linked issue with the PR URL, what changed, and any follow-up items. GitHub auto-closes the issue on merge when "Closes #N" is in the PR body — do not close manually. + - Post-merge close-out and backlog: After merge: verify issue auto-closed, post close-out comment, open issues for any backlog items from the PR, verify monitoring changes are live. See post_merge steps in github-prs.yaml. + +## Engineering practices + + - Keep the repository as the primary source of truth so context-driven engineering comes from repo contracts, docs, tests, config, and repo-native notes instead of agent memory. + - Prefer repo-centric mechanisms that discover workflows, tools, formats, and refs dynamically instead of hardcoding per-agent assumptions. + - Keep markdown, yaml, diagrams, tests, and command contracts self-contained in the repo so local and remote UDX workflows stay aligned. + - Keep deterministic workflow logic in repo config and scripts, and reserve AI agents for reading that contract, generating grounded summaries, and handling non-deterministic judgment without inventing hidden rules. + - Operate from repo-declared context at all times. Do not carry assumptions across sessions or rely on prompt history when the repo contract is available on disk. + - After loading the repo contract, prefer current GitHub issues, pull requests, review state, and commit history as the primary dynamic source for agent decisions. Use repo workflow and practice catalogs as fallback defaults when live GitHub signal is missing or thin. + - When understanding behavior, read the YAML manifest that defines it before reading the code that implements it. Manifests are the interface — code is the mechanism. + - Check existing org patterns, configs, workflows, and templates before creating new ones. Reuse declared patterns instead of inventing alternatives. + - Detect the repo's canonical verification surface from context, but prefer GitHub workflow executions and monitor their outcomes when the repo already has CI coverage. Use local verification for quick scoped debugging, missing CI coverage, or reproducing workflow failures. + - Keep the delivery chain explicit — branch, PR, and issue must be connected before close-out. Do not treat any step as done until the link to the next step is visible. + - Report outcomes with exact URLs, versions, findings deltas, and next steps so follow-up can be reused by humans and agents without drift. + - Use README, docs, and tests as the first alignment surface before broad refactors. Read the declared workflow before changing the implementation. + - Do not require custom repo files for dev.kit to work. Prefer standard engineering signals such as README, docs, tests, manifests, workflows, and deployment config, with dev.kit-owned continuity treated as optional acceleration only. + - Express repo rules in YAML manifests first, then keep shell glue thin and composable. Policy belongs in config, not buried in imperative scripts. + - When a new direction is accepted, archive or delete conflicting old modules and configs instead of carrying both models forward. + - If local verification is needed, run the smallest local check that proves the current change. Prefer broader or slower coverage in GitHub workflows, monitor the workflow run, and call the tradeoff out explicitly. + - Make sure to develop and test incrementally, so it is easier to detect problems early and build on verified behavior. + - Make sure to protect development executions with scoped and limited tasks, so failures are easier to isolate and blast radius stays low. + - Use the linked GitHub issue as the cross-repo context root. When work spans multiple repos, the issue URL anchors scope, acceptance criteria, and follow-up across all of them. + diff --git a/Dockerfile b/Dockerfile index 40c896c..012de1f 100644 --- a/Dockerfile +++ b/Dockerfile @@ -1,8 +1,8 @@ -# Use the latest udx-worker as the base image -FROM usabilitydynamics/udx-worker:0.40.0 +# Use a pinned udx-worker release +FROM usabilitydynamics/udx-worker:0.41.0 # Add metadata labels -LABEL version="0.31.0" +LABEL version="0.41.0" # Set build arguments for Node.js version and application port ARG NODE_VERSION=24.13.1 From 955be766743f10fb2a3b6b240b5bc6907b49a40e Mon Sep 17 00:00:00 2001 From: Dmitry Smirnov Date: Fri, 17 Apr 2026 19:47:47 +0300 Subject: [PATCH 2/4] Remove generated context artifacts --- .rabbit/context.yaml | 106 ------------------------------------------- AGENTS.md | 95 -------------------------------------- 2 files changed, 201 deletions(-) delete mode 100644 .rabbit/context.yaml delete mode 100644 AGENTS.md diff --git a/.rabbit/context.yaml b/.rabbit/context.yaml deleted file mode 100644 index 9623322..0000000 --- a/.rabbit/context.yaml +++ /dev/null @@ -1,106 +0,0 @@ -# Generated by dev.kit repo — do not edit manually. -# Run `dev.kit repo` to refresh. -kind: repoContext -version: udx.io/dev.kit/v1 -generated: 2026-04-17 - -repo: - name: worker-nodejs - archetype: runtime-image - profile: container - -refs: - - ./README.md - - ./.rabbit - - ./.github/workflows - - ./Makefile - - ./Dockerfile - - ./deploy.yml - - ./src - -commands: - verify: make test - build: make build - run: make run - -# Gaps — factors that are missing or partial -gaps: - - dependencies (partial) - -# Engineering practices -practices: - - "Keep the repository as the primary source of truth so context-driven engineering comes from repo contracts, docs, tests, config, and repo-native notes instead of agent memory." - - "Prefer repo-centric mechanisms that discover workflows, tools, formats, and refs dynamically instead of hardcoding per-agent assumptions." - - "Keep markdown, yaml, diagrams, tests, and command contracts self-contained in the repo so local and remote UDX workflows stay aligned." - - "Keep deterministic workflow logic in repo config and scripts, and reserve AI agents for reading that contract, generating grounded summaries, and handling non-deterministic judgment without inventing hidden rules." - - "Operate from repo-declared context at all times. Do not carry assumptions across sessions or rely on prompt history when the repo contract is available on disk." - - "After loading the repo contract, prefer current GitHub issues, pull requests, review state, and commit history as the primary dynamic source for agent decisions. Use repo workflow and practice catalogs as fallback defaults when live GitHub signal is missing or thin." - - "When understanding behavior, read the YAML manifest that defines it before reading the code that implements it. Manifests are the interface — code is the mechanism." - - "Check existing org patterns, configs, workflows, and templates before creating new ones. Reuse declared patterns instead of inventing alternatives." - - "Detect the repo's canonical verification surface from context, but prefer GitHub workflow executions and monitor their outcomes when the repo already has CI coverage. Use local verification for quick scoped debugging, missing CI coverage, or reproducing workflow failures." - - "Keep the delivery chain explicit — branch, PR, and issue must be connected before close-out. Do not treat any step as done until the link to the next step is visible." - - "Report outcomes with exact URLs, versions, findings deltas, and next steps so follow-up can be reused by humans and agents without drift." - - "Use README, docs, and tests as the first alignment surface before broad refactors. Read the declared workflow before changing the implementation." - - "Do not require custom repo files for dev.kit to work. Prefer standard engineering signals such as README, docs, tests, manifests, workflows, and deployment config, with dev.kit-owned continuity treated as optional acceleration only." - - "Express repo rules in YAML manifests first, then keep shell glue thin and composable. Policy belongs in config, not buried in imperative scripts." - - "When a new direction is accepted, archive or delete conflicting old modules and configs instead of carrying both models forward." - - "If local verification is needed, run the smallest local check that proves the current change. Prefer broader or slower coverage in GitHub workflows, monitor the workflow run, and call the tradeoff out explicitly." - - "Make sure to develop and test incrementally, so it is easier to detect problems early and build on verified behavior." - - "Make sure to protect development executions with scoped and limited tasks, so failures are easier to isolate and blast radius stays low." - - "Use the linked GitHub issue as the cross-repo context root. When work spans multiple repos, the issue URL anchors scope, acceptance criteria, and follow-up across all of them." - -# Canonical agent workflow -workflow: - - "Refresh repo context: Run `dev.kit` → `dev.kit repo` → `dev.kit agent` before starting work. Each command guides to the next required step. This resyncs repo context, environment state, and the AGENTS.md execution contract. A current context.yaml is the source of truth for refs, commands, gaps, and lessons. Do not rely on ad hoc prompt memory when the repo contract can be read from disk. When GitHub context is available, prefer current issues, pull requests, review state, and commit history over stale memory or generic workflow defaults." - - "Read linked GitHub issue and confirm scope: If a GitHub issue URL is available, read the full body and comments, confirm the repo matches the issue scope, and map acceptance criteria before writing any code. Use the issue URL as the cross-repo context root." - - "Inspect git status" - - "Analyze local changes" - - "Analyze branch state" - - "Group logical commits" - - "Bump version and changelog if supported" - - "Create or validate feature branch" - - "Push branch to remote" - - "Generate pull request description: Pick the PR template type from src/configs/github-prs.yaml (feature, deployment, ops, hotfix). Fill every required section. Include \"Closes #N\" for linked issues. Add a \"Backlog from this investigation\" section for any new gaps found. Use .github/PULL_REQUEST_TEMPLATE.md as the base form." - - "Create pull request" - - "Monitor related workflow executions: After PR creation, monitor the related GitHub workflow runs and status checks. Open the run details when needed, watch for failed or stuck jobs, and treat GitHub workflow execution as the primary verification path when the repo already has CI coverage." - - "Loop automated review feedback: After PR creation, wait for Copilot, Devin, and CodeQL reviews. Read each review from github-prs.yaml bot guidance. Address actionable findings with code changes, reply to each bot comment, and resolve the thread when handled. Repeat this loop after each push until bot feedback is clean. Do not request human review while bot findings are unaddressed." - - "Verify required status checks: All required checks must pass before requesting human review. For infra PRs, open check details and review the Terraform plan output. For CodeQL, review findings in the Security tab. When the repo already has GitHub workflow coverage, prefer those executions as the primary verification path and monitor them closely. Use local verification to reproduce failures or cover gaps, not as a universal gate." - - "Post close-out comment on linked issue: After PR is created, post a brief comment on the linked issue with the PR URL, what changed, and any follow-up items. GitHub auto-closes the issue on merge when \"Closes #N\" is in the PR body — do not close manually." - - "Post-merge close-out and backlog: After merge: verify issue auto-closed, post close-out comment, open issues for any backlog items from the PR, verify monitoring changes are live. See post_merge steps in github-prs.yaml." - -# External dependencies — cross-repo and upstream references -# Trace these to find infrastructure, deployment, and build logic outside this repo. -# Same-org deps are resolved with metadata. External deps listed for agent reference. -dependencies: - - repo: actions/checkout - type: github action - resolved: false - used_by: - - .github/workflows/codeql.yml - - .github/workflows/tests.yml - - repo: udx/reusable-workflows - type: reusable workflow - resolved: true - archetype: workflow-repo - profile: unknown - used_by: - - .github/workflows/context7_sync.yml - - .github/workflows/docker-ops.yml - - repo: usabilitydynamics/udx-worker:0.41.0 - type: base image - resolved: true - source_repo: udx/worker - archetype: runtime-image - profile: container - used_by: - - Dockerfile - -# Config manifests — traceable workflow and tooling dependencies -# Read these to understand what controls repo behavior before reading shell code. -manifests: - - .github/workflows/codeql.yml - - .github/workflows/context7_sync.yml - - .github/workflows/docker-ops.yml - - .github/workflows/tests.yml - - deploy.yml - diff --git a/AGENTS.md b/AGENTS.md deleted file mode 100644 index 8ccaf79..0000000 --- a/AGENTS.md +++ /dev/null @@ -1,95 +0,0 @@ -# AGENTS.md - -_Auto-generated by `dev.kit agent`. Sources: `.rabbit/context.yaml`, GitHub history, lesson artifacts._ - -## Contract - -This repository is a deterministic execution contract. Agents MUST interpret declared context — no scanning, no guesswork, no invention. - -### Rules - -1. **Do NOT scan the filesystem.** No `find`, `ls -R`, `glob`, or recursive directory walks. All paths you need are listed below. -2. **Context boundaries are strict.** Read only files in Priority refs and Config manifests. If a file is not listed, do not read it unless a listed file explicitly references it. -3. **Manifests before code.** When you need to understand behavior, read the YAML manifest that defines it — not the code that implements it. Manifests are the interface. -4. **Context over memory.** Operate from repo-declared context. Do not carry assumptions from prior sessions or rely on prompt history when the contract is on disk. -5. **Prefer workflow verification, not automatic local enforcement.** Detect the repo verify command from `context.yaml`, prefer GitHub workflow executions when the repo already has CI coverage, and use local verification to reproduce failures, debug quickly, or cover workflow gaps. -6. **Follow the Workflow below.** Do not invent ad hoc steps or skip phases. The workflow is the execution sequence. -7. **Reuse over invention.** Check existing org patterns, configs, and workflows before creating new ones. -8. **Prefer live GitHub experience over generic defaults.** After loading the repo contract, use current issues, pull requests, review state, and commit history as the primary dynamic source. Fall back to workflow and practice catalogs when GitHub signal is missing, thin, or irrelevant. -9. **Remember this context.** If your agent supports persistent memory, save that this repo uses `dev.kit` for context management. Start every session — or after merges, config changes, or workflow updates — by running: `dev.kit` → `dev.kit repo` → `dev.kit agent`. Each command guides to the next required step. This resyncs repo context, environment state, and the execution contract before any work begins. - -## Repo: worker-nodejs - -- archetype: runtime-image -- profile: container -- context: ./.rabbit/context.yaml - -### Commands - -``` - verify: make test - build: make build - run: make run -``` - -## Use context.yaml - -All refs, config manifests, command surfaces, dependencies, and gaps live in `.rabbit/context.yaml`. - -Do not duplicate that inventory here. Read `context.yaml` first, then use this file for operating rules, workflow, and dynamic guidance. - -### Gaps - -Incomplete factors. Address within the workflow, not as separate tasks. - - - dependencies (partial) - -## Versioned workflow artifacts - -`.rabbit/` contains generated context downstream of repo signals. These are versioned artifacts, not primary sources. - - - `.rabbit/context.yaml` — generated execution contract (source of truth for this file) - -## Workflow - -The dev.kit lifecycle: **repo → agent → work → PR → merge**. Follow these steps in order. Use them as repo-declared defaults when live GitHub context does not provide a more specific current signal. Steps with notes contain operational guidance. - - - Refresh repo context: Run `dev.kit` → `dev.kit repo` → `dev.kit agent` before starting work. Each command guides to the next required step. This resyncs repo context, environment state, and the AGENTS.md execution contract. A current context.yaml is the source of truth for refs, commands, gaps, and lessons. Do not rely on ad hoc prompt memory when the repo contract can be read from disk. When GitHub context is available, prefer current issues, pull requests, review state, and commit history over stale memory or generic workflow defaults. - - Read linked GitHub issue and confirm scope: If a GitHub issue URL is available, read the full body and comments, confirm the repo matches the issue scope, and map acceptance criteria before writing any code. Use the issue URL as the cross-repo context root. - - Inspect git status - - Analyze local changes - - Analyze branch state - - Group logical commits - - Bump version and changelog if supported - - Create or validate feature branch - - Push branch to remote - - Generate pull request description: Pick the PR template type from src/configs/github-prs.yaml (feature, deployment, ops, hotfix). Fill every required section. Include "Closes #N" for linked issues. Add a "Backlog from this investigation" section for any new gaps found. Use .github/PULL_REQUEST_TEMPLATE.md as the base form. - - Create pull request - - Monitor related workflow executions: After PR creation, monitor the related GitHub workflow runs and status checks. Open the run details when needed, watch for failed or stuck jobs, and treat GitHub workflow execution as the primary verification path when the repo already has CI coverage. - - Loop automated review feedback: After PR creation, wait for Copilot, Devin, and CodeQL reviews. Read each review from github-prs.yaml bot guidance. Address actionable findings with code changes, reply to each bot comment, and resolve the thread when handled. Repeat this loop after each push until bot feedback is clean. Do not request human review while bot findings are unaddressed. - - Verify required status checks: All required checks must pass before requesting human review. For infra PRs, open check details and review the Terraform plan output. For CodeQL, review findings in the Security tab. When the repo already has GitHub workflow coverage, prefer those executions as the primary verification path and monitor them closely. Use local verification to reproduce failures or cover gaps, not as a universal gate. - - Post close-out comment on linked issue: After PR is created, post a brief comment on the linked issue with the PR URL, what changed, and any follow-up items. GitHub auto-closes the issue on merge when "Closes #N" is in the PR body — do not close manually. - - Post-merge close-out and backlog: After merge: verify issue auto-closed, post close-out comment, open issues for any backlog items from the PR, verify monitoring changes are live. See post_merge steps in github-prs.yaml. - -## Engineering practices - - - Keep the repository as the primary source of truth so context-driven engineering comes from repo contracts, docs, tests, config, and repo-native notes instead of agent memory. - - Prefer repo-centric mechanisms that discover workflows, tools, formats, and refs dynamically instead of hardcoding per-agent assumptions. - - Keep markdown, yaml, diagrams, tests, and command contracts self-contained in the repo so local and remote UDX workflows stay aligned. - - Keep deterministic workflow logic in repo config and scripts, and reserve AI agents for reading that contract, generating grounded summaries, and handling non-deterministic judgment without inventing hidden rules. - - Operate from repo-declared context at all times. Do not carry assumptions across sessions or rely on prompt history when the repo contract is available on disk. - - After loading the repo contract, prefer current GitHub issues, pull requests, review state, and commit history as the primary dynamic source for agent decisions. Use repo workflow and practice catalogs as fallback defaults when live GitHub signal is missing or thin. - - When understanding behavior, read the YAML manifest that defines it before reading the code that implements it. Manifests are the interface — code is the mechanism. - - Check existing org patterns, configs, workflows, and templates before creating new ones. Reuse declared patterns instead of inventing alternatives. - - Detect the repo's canonical verification surface from context, but prefer GitHub workflow executions and monitor their outcomes when the repo already has CI coverage. Use local verification for quick scoped debugging, missing CI coverage, or reproducing workflow failures. - - Keep the delivery chain explicit — branch, PR, and issue must be connected before close-out. Do not treat any step as done until the link to the next step is visible. - - Report outcomes with exact URLs, versions, findings deltas, and next steps so follow-up can be reused by humans and agents without drift. - - Use README, docs, and tests as the first alignment surface before broad refactors. Read the declared workflow before changing the implementation. - - Do not require custom repo files for dev.kit to work. Prefer standard engineering signals such as README, docs, tests, manifests, workflows, and deployment config, with dev.kit-owned continuity treated as optional acceleration only. - - Express repo rules in YAML manifests first, then keep shell glue thin and composable. Policy belongs in config, not buried in imperative scripts. - - When a new direction is accepted, archive or delete conflicting old modules and configs instead of carrying both models forward. - - If local verification is needed, run the smallest local check that proves the current change. Prefer broader or slower coverage in GitHub workflows, monitor the workflow run, and call the tradeoff out explicitly. - - Make sure to develop and test incrementally, so it is easier to detect problems early and build on verified behavior. - - Make sure to protect development executions with scoped and limited tasks, so failures are easier to isolate and blast radius stays low. - - Use the linked GitHub issue as the cross-repo context root. When work spans multiple repos, the issue URL anchors scope, acceptance criteria, and follow-up across all of them. - From cda562915c16e4e83bb17a56c0da918b0fa98dde Mon Sep 17 00:00:00 2001 From: Dmitry Smirnov Date: Fri, 17 Apr 2026 20:04:21 +0300 Subject: [PATCH 3/4] Fix image version label --- Dockerfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Dockerfile b/Dockerfile index 012de1f..6929118 100644 --- a/Dockerfile +++ b/Dockerfile @@ -2,7 +2,7 @@ FROM usabilitydynamics/udx-worker:0.41.0 # Add metadata labels -LABEL version="0.41.0" +LABEL version="0.31.0" # Set build arguments for Node.js version and application port ARG NODE_VERSION=24.13.1 From 589adc9963ca1189b0fbbeebf5636a83f07d43d0 Mon Sep 17 00:00:00 2001 From: Dmitry Smirnov Date: Fri, 17 Apr 2026 20:04:54 +0300 Subject: [PATCH 4/4] Bump image version to 0.32.0 --- Dockerfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Dockerfile b/Dockerfile index 6929118..680ce0e 100644 --- a/Dockerfile +++ b/Dockerfile @@ -2,7 +2,7 @@ FROM usabilitydynamics/udx-worker:0.41.0 # Add metadata labels -LABEL version="0.31.0" +LABEL version="0.32.0" # Set build arguments for Node.js version and application port ARG NODE_VERSION=24.13.1