44 lines
3.1 KiB
Markdown
44 lines
3.1 KiB
Markdown
## Context
|
|
|
|
The SCUM plugin already declares runtime config mappings and log sources, while Platform exposes safe configuration read/diff/approval APIs and a scoped file-operation dispatcher. Its current plugin page is an operations overview with semantic logs; this does not match the operator's configuration-first workflow.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
|
|
- Make plugin-owned logical file declarations the single catalog for SCUM configuration and log file scopes.
|
|
- Model safe configuration fields separately from the raw INI content, then compose changes into the existing Platform diff-preview and approval flow.
|
|
- Present declared log files and their Platform log-stream contents in the same workbench.
|
|
- Redirect historical SCUM page keys to the default `files-config` page without breaking shared plugin routing.
|
|
|
|
**Non-Goals:**
|
|
|
|
- Arbitrary filesystem browsing, path entry, terminals, FTP/rsync controls, raw secrets, or host/socket exposure.
|
|
- Raw text as the default configuration editor, write access for unknown fields, or a new run-side protocol.
|
|
- Changing global server-list behavior or non-SCUM plugin pages.
|
|
|
|
## Decisions
|
|
|
|
1. Add `fileWorkspace` to the plugin manifest/runtime projection. It contains safe logical directories/files and modeled fields, rather than host paths or unbounded schemas. This makes a page contract auditable and keeps ownership with the plugin.
|
|
2. Give every modeled field an owning logical file key, Chinese operational metadata, and constrained control details. The frontend uses only these fields to compose proposed INI content; unmapped lines remain visible as read-only field records.
|
|
3. Reuse `GET /config`, config diff preview, and config approval for the declared primary config file. Log-file selection maps declared logical files to existing Platform log streams; no new direct file-read API is introduced.
|
|
4. Move SCUM from `operations` to `files-config`; the route resolver redirects old `overview`, `config`, `logs`, and `operations` keys only for `game.scum`. Other plugins keep their declared page keys unchanged.
|
|
5. Build page content from existing shared console form/list/diff classes. No page-owned surface system or global decoration is added.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- [A config document may contain extra keys] → preserve them in the proposed content and show them as read-only, unmodeled rows.
|
|
- [Existing installations still link old route keys] → normalize those keys in the common resolver before page lookup.
|
|
- [A declared log stream is absent] → show an explicit unavailable state and never fall back to a filesystem path.
|
|
- [INI parsing has formatting limits] → patch only declared simple key/value fields and rely on Platform preview before approval.
|
|
|
|
## Migration Plan
|
|
|
|
1. Ship manifest and Platform declaration validation/projection with the SCUM `files-config` page.
|
|
2. Deploy the frontend route normalization and workbench; old SCUM links resolve to `files-config`.
|
|
3. Rollback by restoring the previous manifest page declaration; no persisted migration or write protocol needs reversal.
|
|
|
|
## Open Questions
|
|
|
|
None. The first field catalog uses existing SCUM deployment mappings and can be expanded through manifest declarations later.
|