spike(framework): validate a portable project-policy boundary

Open
#585 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Domain
cli, tooling

Research direction

Start by mapping the existing .aidd/ state and the aidd clean --force entry point, including auth, manifests, caches, ignore rules, secrets, and generated files. Review the stale .aidd/config.yml documentation, then compare at least two live policy consumers and candidate boundaries. Done means a written decision, cleanup and credential-safety evidence, an owner for documentation correction, and justified follow-up work.

Written by the indexing model from the issue text.

Description

Question

What portable project-policy boundary, if any, lets a team version genuinely shared AI-development policy without colliding with CLI-managed state or a specific host?

Why this must be investigated first

.aidd/ already contains CLI-managed auth, manifests, and caches. aidd clean --force currently removes the whole directory. The previous proposal assumed .aidd/config.yml, YAML, precedence, and a broad schema before proving the consumers or a safe ownership boundary.

Scope

  • Map the lifecycle and ownership of existing project state, including clean, ignore, secrets, and generated files.
  • Establish at least two independent, live policy consumers that cannot be served by existing project documentation, rules, or host configuration.
  • Compare candidate locations and formats against portability, team review, lifecycle safety, and host neutrality.
  • Decide whether a shared policy artifact is warranted; if so, recommend its narrowest first contract and migration safeguards.

Evidence of completion

  • A written decision records the candidate consumers, alternatives considered, and rejected options.
  • The chosen boundary is not deleted by normal CLI cleanup and cannot expose credentials through normal version control.
  • Any required correction to the stale config.yml documentation is identified with an owner.
  • The result names follow-up delivery work only when the evidence justifies it.

Out of scope

  • Implementing a parser, schema, generator, precedence cascade, or consumers.
  • Choosing YAML in advance.
  • Migrating existing runtime configuration or secrets.
Dominant language
TypeScript
Stars
481
Forks
45
Avg merge
17h 40m
Merged PRs (30d)
106

Contributor guide

Open the contributing guide

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 ai-driven-dev/framework

All issues in ai-driven-dev/framework

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.