[FEATURE] Project type system in config.yaml — adapts agents, workflows, security, and knowledge per type

[JoshLuedeman]

Problem It Solves

Closes gap: #178

The framework has no declared project type, so it cannot adapt behavior for non-software projects. All installation, agent configuration, and workflow steps assume a standard software project with CI, tests, and a web API. This is the root cause addressed by all v1.6.0 issues (#126, #127, #132, #134, #135, #137).

Proposed Behavior

Project type field in config.yaml

project:
  name: "my-project"
  repo: "owner/repo"
  type: software    # software | api | database | infrastructure | documentation | ml

What project type controls

Config Dimension	Example: software	Example: database	Example: infrastructure
Default agents	All core + api-agent	dba-agent, security-auditor, reviewer	devops, security-auditor, architect
Opt-in agents	devops, perf-agent	api-agent, tester	tester, coder
Security checks	Web, OWASP Top 10	SQL injection, RBAC, encryption at rest	IAM, firewall rules, secrets management
Mandatory workflow steps	CI pass, tests pass	Schema diff review, migration dry-run	Plan output review, cost estimate
Knowledge schemas	languages, build, test, lint	DB engine, ORM, migration tool	IaC tool, cloud provider, state backend

teamwork init --type flag

teamwork init --type database

Sets project.type in config.yaml, installs the type-appropriate agent roster, and populates agent knowledge schemas with type-relevant facts.

When --type is omitted, teamwork init detects project type from file signatures (go.mod → software/api, terraform files → infrastructure, SQL migrations without app code → database, only markdown/rst → documentation) and prompts the user to confirm.

Runtime enforcement

The workflow engine reads project.type at startup and applies type-specific behavior:

• Skips CI/test quality gates for documentation and database types (unless DetectTestFramework() returns true)
• Routes security checks to the type-appropriate vulnerability categories
• Filters teamwork doctor prerequisite checks to type-relevant tools

Integration with preset system (v1.5.0 NF-8)

Project type is one dimension of the preset system. teamwork init --preset go-api implies --type api. Presets set type + tech stack together.

Dependencies

• Resolves: setup-teamwork skill should detect non-software projects #126, Agent project knowledge sections are identical across all roles #132, Security Auditor agent is web-app focused — lacks database and infrastructure security #134, Workflow skills assume CI/CD, test suites, and build systems universally #135, api-agent installed unconditionally — even for projects with no API #137 (all v1.6.0 issues are partial implementations of this)
• Requires: internal/config/detect.go extended with project type detection
• Requires: agent template system that reads type to select knowledge schema (see [FEATURE] Role-specific project knowledge schemas in agent templates and setup-teamwork #185)
• Requires: workflow engine type-aware gate evaluation (see [FEATURE] Branching and conditional step definitions in workflow engine #179 conditional steps)
• Builds on: teamwork init interactive wizard (v1.2.0)

Complexity Estimate

Large — 8+ files: config schema type field, detect.go type detection, init command type prompt, agent roster per type, workflow engine type-aware gates, security auditor type-aware checklist, knowledge schema registry per type, tests