This commit is contained in:
@@ -0,0 +1,100 @@
|
||||
# 23 — Future expansion and extension points
|
||||
|
||||
## Forge adapters
|
||||
|
||||
The normalized forge port supports Gitea first. Future adapters:
|
||||
|
||||
- Forgejo;
|
||||
- GitHub;
|
||||
- GitLab;
|
||||
- Azure DevOps.
|
||||
|
||||
Each adapter declares capabilities rather than pretending feature parity.
|
||||
|
||||
## Agent adapters
|
||||
|
||||
Potential output/execution adapters:
|
||||
|
||||
- OpenAI Codex prompt/Run Pack;
|
||||
- Codex Skill;
|
||||
- DevRunbook MCP server;
|
||||
- Codex SDK/CLI bridge;
|
||||
- other coding agents through model-specific render profiles.
|
||||
|
||||
The internal playbook remains model-neutral enough to preserve task semantics, while render adapters can apply platform-specific conventions.
|
||||
|
||||
## Policy packs
|
||||
|
||||
Teams may install policy packs that add non-overridable controls:
|
||||
|
||||
- no production dependency without approval;
|
||||
- migrations require backup and rollback;
|
||||
- security-sensitive paths require review;
|
||||
- release playbooks require SBOM and scan evidence;
|
||||
- public API changes require compatibility report.
|
||||
|
||||
Policy packs need signed source and explicit precedence.
|
||||
|
||||
## Playbook collections
|
||||
|
||||
Curated bundles:
|
||||
|
||||
- Repository Foundations
|
||||
- Bugfix Discipline
|
||||
- Frontend Quality
|
||||
- Docker and Self-hosting
|
||||
- Gitea Governance
|
||||
- Release Readiness
|
||||
- Security Hygiene
|
||||
- .NET Engineering
|
||||
- TypeScript Monorepos
|
||||
- Python Services
|
||||
|
||||
## Scheduled intelligence
|
||||
|
||||
Future condition-based checks can refresh repository evidence and notify users of meaningful changes:
|
||||
|
||||
- test command disappeared;
|
||||
- default branch protection weakened;
|
||||
- new package manager introduced;
|
||||
- release overdue;
|
||||
- workflow failing;
|
||||
- AGENTS.md changed;
|
||||
- dependency policy drift.
|
||||
|
||||
Notifications should report evidence and recommend a playbook, not automatically change repositories.
|
||||
|
||||
## Collaborative review
|
||||
|
||||
- comments on playbook blocks;
|
||||
- requested changes;
|
||||
- approval requirements;
|
||||
- branch-like draft revisions;
|
||||
- signed releases;
|
||||
- team collections;
|
||||
- usage analytics without exposing prompt content unnecessarily.
|
||||
|
||||
## Evaluation marketplace
|
||||
|
||||
A future registry can publish not only packages but evaluation evidence. Trust should include:
|
||||
|
||||
- publisher identity;
|
||||
- package signature;
|
||||
- fixture provenance;
|
||||
- execution environment;
|
||||
- result artifacts;
|
||||
- reviewer identity;
|
||||
- recency;
|
||||
- revoked versions.
|
||||
|
||||
## Local desktop companion
|
||||
|
||||
A companion app can securely access local repositories and Codex CLI while the web platform remains isolated. It can provide:
|
||||
|
||||
- repository profile generation;
|
||||
- worktree creation;
|
||||
- exact Run Pack handoff;
|
||||
- execution evidence capture;
|
||||
- file-diff and validation result import.
|
||||
|
||||
The companion requires explicit pairing, least privilege and a separate security review.
|
||||
Reference in New Issue
Block a user