Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[devcontainers]: Define devcontainer spec extension for hawkeye policy injection

Open
#5 0 comments 0 reactions 0 assignees View on GitHub

@jpoley is already working on this.

Since Apr 18, 2026.

  • #10 by @jpoley — open

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
docker, typescript
Domain
devops, tooling

Research direction

Start by locating the devcontainer.json handling and the devcontainer startup sequence, then trace the daax dev validate entry point. Define the schema and policy registration behavior against the listed Definition of Done, and add the requested container validation test plus an annotated devcontainer.json example.

Written by the indexing model from the issue text.

Description

devcontainers hawkeye high-priority

Issue: [devcontainers]: Define devcontainer spec extension for hawkeye policy injection

Feature: devcontainers
Priority: high
Labels: devcontainers, hawkeye, high-priority

Description

Currently hawkeye policy and devcontainer definitions are separate. When a devcontainer is launched for agent work, hawkeye has no structured way to know which policies apply to that container context. We need a standard extension to the devcontainer spec that declares hawkeye policy bindings — so the container itself encodes what rules govern the agent running inside it.

Intel driver: Martin Fowler's harness engineering article (2026-04-02, martinfowler.com) — "outer harness serves two goals: increases the probability the agent gets it right AND provides a feedback loop that self-corrects." The harness starts at the container definition level.

What

Define a devcontainer.json extension schema:

{
  "hawkeye": {
    "policySet": "daax/standard-v1",
    "qualityGates": ["test-coverage-80", "no-secrets", "lint-pass"],
    "feedbackMode": "adaptive",
    "maxAutoCorrections": 3
  }
}

Why

Container-declared policy means: (1) policy travels with the code, not just the repo config; (2) any agent spawned in that container automatically inherits the right hawkeye ruleset; (3) policy can be version-controlled alongside the container definition.

Definition of Done

  • Schema defined and documented in daax devcontainers spec
  • devcontainer startup sequence reads hawkeye block and registers policy with hawkeye before first agent command
  • If hawkeye block is absent, container starts with default policy (not no policy)
  • Validation: daax dev validate catches invalid hawkeye policy refs at startup, not at runtime
  • Test: container with "qualityGates": ["test-coverage-80"] causes hawkeye to reject code submissions below 80% coverage
  • Documentation: annotated devcontainer.json example with hawkeye block
Dominant language
TypeScript
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from daax-dev/daax-devtools

All issues in daax-dev/daax-devtools

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.