59 lines
3.6 KiB
Markdown
59 lines
3.6 KiB
Markdown
---
|
|
title: 'Remove feature-layer HostAuthority model'
|
|
state: 'closed'
|
|
created_at: '2026-06-13T15:30:22Z'
|
|
updated_at: '2026-06-14T14:00:13Z'
|
|
assignee: null
|
|
readiness: 'implementation_ready'
|
|
risk_flags: ['feature-api', 'tool-registry', 'ticket-tools']
|
|
queued_by: 'workspace-panel'
|
|
queued_at: '2026-06-13T16:33:15Z'
|
|
---
|
|
|
|
## Background
|
|
|
|
Current `pod::feature` contains `HostAuthority`, `HostAuthorityRequest`, and `HostAuthorityGrantSet`. In practice this layer does not enforce OS-level or Plugin/MCP permissions: current install code grants requested authorities and uses them mostly as declaration/reporting and contribution registration checks.
|
|
|
|
The project decision is to keep `pod::feature` as an API/contribution substrate and move real permission/trust decisions to the owning layers:
|
|
|
|
- Plugin package/runtime permission policy belongs to the Plugin layer.
|
|
- MCP local stdio enablement, command/env/secret policy, and server trust belong to the MCP layer.
|
|
- filesystem/tool/pod permissions remain in existing manifest/profile/tool permission paths.
|
|
- Ticket feature access remains explicit Ticket feature configuration and backend validation, not feature-layer authority grants.
|
|
|
|
Therefore the feature-layer authority model should be removed, not renamed or preserved as diagnostics. Any remaining report data should use ordinary contribution/installation diagnostic terminology without `Authority`, `Grant`, or permission semantics.
|
|
|
|
## Requirements
|
|
|
|
- Remove `HostAuthority`, `HostAuthorityRequest`, `HostAuthorityGrantSet`, and related feature install report fields from `pod::feature`.
|
|
- Do not introduce renamed feature-layer authority/grant types as a replacement; use ordinary diagnostics for non-permission install information.
|
|
- Remove contribution registration checks that depend on feature-layer authority grants.
|
|
- Keep contribution declaration/registration checks that are still useful without authority terminology.
|
|
- duplicate contribution names
|
|
- undeclared contribution categories, if currently checked
|
|
- feature install diagnostics
|
|
- Update built-in features that currently request host authorities.
|
|
- Ticket feature should rely on validated `TicketFeatureConfig`, backend root validation, and access-level configuration.
|
|
- Task feature should not mention host authority.
|
|
- Ensure no Plugin or MCP Ticket depends on feature-layer authority grants after the cleanup.
|
|
- Update comments/docs/tests that describe feature-layer authority as future Plugin/MCP permission infrastructure.
|
|
- Do not use this cleanup to introduce Plugin permission policy or MCP server trust policy; those remain separate layers.
|
|
|
|
## Acceptance criteria
|
|
|
|
- The codebase no longer exposes `HostAuthority*` or equivalent feature-layer authority/grant types as part of the `pod::feature` public API.
|
|
- Built-in task and ticket feature tests pass without authority grants.
|
|
- Ticket tools still require explicit Ticket feature config/access and validated backend root.
|
|
- Feature install reports still provide useful diagnostics for skipped/failed contributions without implying security grants.
|
|
- Grep/review confirms Plugin and MCP planning Tickets do not rely on feature authority for permission/trust control.
|
|
- Validation: focused feature/ticket/task tests, `cargo fmt --check`, affected crate tests, `cargo check --workspace --all-targets`, and `nix build .#yoi`.
|
|
|
|
## Related work
|
|
|
|
- Feature API dynamic provider work: `00001KTR81P9X`
|
|
- MCP local stdio integration: `00001KTR82RB7`
|
|
- Plugin extension surface: `00001KSXRQ4G8`
|
|
- Plugin package/discovery: `00001KT0Z4BK8`
|
|
- Earlier feature registry scaffold: `00001KT6Q08R9`
|
|
- Earlier authority naming split: `00001KTAGM2V0`
|