101 lines
2.5 KiB
Markdown
101 lines
2.5 KiB
Markdown
# 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.
|