dev/ACTIVE_TASK.json

@@ -1,5 +1,5 @@
 {
-  "task_file": "dev/tasks/DEV-000045-production-artifact-provenance.json",
-  "task_id": "DEV-000045",
+  "task_file": "dev/tasks/ARCH-000007-cognitive-provider-proposal.json",
+  "task_id": "ARCH-000007",
   "task_revision": 1
 }

dev/tasks/ARCH-000007-cognitive-provider-proposal.json

@@ -0,0 +1,23 @@
+{
+  "task_id": "ARCH-000007",
+  "task_revision": 1,
+  "architecture_revision": "generation-1",
+  "base_repo_revision": "43d1ef58213938c7ad8761375705849eec8fd901",
+  "risk_tier": "E",
+  "intent": "Produce a proposal-only decision for Domovoy's first real cognitive provider slice: authenticated Creator advisory responses with explicit data boundaries, replaceable provider binding, evaluation/promotion rules, and mechanically absent canonical or external mutation authority.",
+  "requirement_ids": ["FD-001", "FD-009", "FD-023", "FD-025", "INV-EPI-001", "USER-CONTINUE-PROJECT"],
+  "allowed_change_scope": {"modules": [], "paths": ["docs/COGNITIVE_PROVIDER_PROPOSAL.md", "dev/ACTIVE_TASK.json", "dev/tasks/ARCH-000007-cognitive-provider-proposal.json"]},
+  "forbidden_change_scope": {"paths": ["architecture/**", "ci/**", ".gitea/**", "contracts/**", "modules/**", "adapters/**", "cmd/**", "database/**", "deploy/**", "security/**", "tests/**"]},
+  "allowed_architecture_delta": {"new_cross_module_dependencies": 0, "new_canonical_owners": 0, "new_privileges": 0, "new_third_party_dependencies": 0},
+  "contracts": {"consume": ["FD-001", "FD-009", "FD-023", "FD-025", "existing authenticated Creator session"], "may_change": []},
+  "semantic_owner": "proposal-only; no architecture decision is accepted by this task",
+  "canonical_state": [],
+  "state_transitions": [],
+  "side_effects_and_privileges": ["select this proposal in the active task pointer", "no provider call, credential creation, deployment, canonical mutation or external action"],
+  "persistence_and_migrations": [],
+  "failure_retry_restart": ["proposal defines timeout and provider-unavailable as explicit advisory failures", "advisory requests are not silently retried", "loss of cognition does not affect continuity or integrity"],
+  "assumptions": ["the first cognitive slice is advisory text, not autonomous action", "the user has not yet accepted a provider, data policy or retention policy", "docker-test remains prohibited"],
+  "acceptance_scenarios": ["proposal defines a provider-neutral typed advisory contract", "proposal defines allowed and forbidden context data", "model output has no canonical write or Executor path", "proposal defines secret isolation and log redaction", "proposal defines deterministic validation, timeout, rate and size limits", "proposal defines fake/eval/shadow/canary/promotion and rollback", "proposal identifies the minimum decisions requiring explicit user acceptance", "no runtime, protected architecture, credential or deployment state changes"],
+  "required_tests": ["task schema", "architecture preflight", "exact diff scope", "documentation review", "CI"],
+  "terminal_gap_states": ["BLOCKED_BY_ARCHITECTURE_GAP", "BLOCKED_BY_SPEC_GAP", "BLOCKED_BY_CONFLICT"]
+}

docs/COGNITIVE_PROVIDER_PROPOSAL.md

@@ -0,0 +1,121 @@
+# Cognitive provider proposal — Creator advisory V1
+
+Status: proposal only. It does not authorize implementation, provider traffic, credentials, deployment or architecture changes.
+
+## 1. Product slice
+
+The first real cognitive feature should be `creator-advisory-v1`: an authenticated Creator asks a question and receives an advisory text response. The response is explicitly non-canonical and cannot itself create or change a Goal, Task, Commitment, Prospective item, Authority grant, Capability binding, ActionProposal or external effect.
+
+This slice is useful before autonomous behavior: Domovoy can explain current information and help formulate a possible next step while every durable or external change remains an explicit existing Creator command through its semantic owner and, where required, Commit/Executor.
+
+## 2. Typed boundary
+
+The provider-neutral Cognitive Gateway request should contain only:
+
+- contract version `creator-advisory-v1`;
+- request ID generated by the gateway;
+- authenticated Actor ID, Principal ID and Scope ID supplied by the trusted server, never chosen by the browser;
+- user message as bounded UTF-8 text;
+- a bounded list of typed context excerpts with source kind, source ID, revision, sensitivity class and exact text;
+- locale and response-size limit;
+- provider binding ID and revision resolved by Capability, not supplied by the browser.
+
+The response should contain:
+
+- request ID and binding revision;
+- advisory text;
+- references only to supplied context excerpt IDs;
+- finish reason from a closed enum: `COMPLETED | LENGTH_LIMIT | CONTENT_REJECTED | PROVIDER_UNAVAILABLE | TIMEOUT | INVALID_PROVIDER_RESPONSE`;
+- provider usage counters when available, treated as operational metadata;
+- no tool call, executable command, authority claim or canonical object mutation.
+
+Free-form provider JSON must not cross into Core contracts. A provider adapter translates its wire response into this closed gateway response and rejects unknown executable/tool fields.
+
+## 3. Data policy
+
+V1 should be data-minimal:
+
+- allowed by default: the current user message plus context the authenticated Creator explicitly selected for this request;
+- denied by default: passwords, tokens, secret files, credential paths, environment variables, private keys, database connection strings, raw logs, browser storage, notification credentials and backup recovery material;
+- no automatic repository, filesystem, email, calendar, network or database crawling;
+- no implicit conversation history or provider-side memory;
+- no full canonical table dump; each context excerpt is bounded, typed and scope-checked by its owner-facing query before gateway assembly;
+- request and response bodies are not written to ordinary application logs;
+- persistence is absent in the first slice. If conversation history is later requested, it requires an Artifact/Epistemics ownership and retention decision rather than provider memory.
+
+Provider retention/training behavior is a deployment acceptance condition. A binding may become active only when its configured data-handling mode matches the accepted deployment policy.
+
+## 4. Authority and isolation
+
+The cognitive worker remains outside canonical ownership and receives no database role, Commit Executor credential, notification writer token, Creator password/session signing key or filesystem secret beyond its single provider credential.
+
+Creator Web calls a server-side gateway endpoint after session validation. The browser never receives the provider key, provider base URL, model identifier override, system instruction or binding secret reference. The cognitive worker may call only the fixed origin in the active Capability binding; redirects, browser-supplied URLs and ambient proxy credentials are denied.
+
+The advisory response is displayed as untrusted assistance. It is never automatically converted to an ActionProposal. A later “use this suggestion” flow must parse into a typed owner command and obtain explicit Creator confirmation under a separate task.
+
+## 5. Deterministic controls
+
+Before a provider call:
+
+- require a valid Creator session and exact Scope binding;
+- enforce request and per-excerpt byte limits, excerpt count, total context limit and UTF-8 validity;
+- reject secret-classified or unknown-classified context;
+- resolve an active Capability binding and exact revision;
+- apply a fixed timeout, concurrency ceiling and per-Principal rate budget;
+- build fixed system instructions in server code, not from browser fields.
+
+After a provider call:
+
+- cap response bytes and validate UTF-8;
+- reject tool calls, executable fields and unknown response shapes;
+- allow citations only to supplied excerpt IDs;
+- report timeout/provider failure distinctly; do not fabricate an answer;
+- do not silently retry, because a second paid request is a distinct attempt even though no external world mutation occurs.
+
+## 6. Provider binding and secrets
+
+Capability owns the binding lifecycle and health, including provider adapter kind, fixed HTTPS origin, model identifier, data-handling mode, limits and secret reference. Provider-specific wire types stay under `adapters/models`; domain packages do not import a provider SDK.
+
+The provider credential is generated or supplied outside Git and PostgreSQL, mounted read-only only into the cognitive worker, and referenced by an opaque secret reference. It is absent from Creator responses, logs, task packets, image layers, health payloads, browser storage and cognitive context.
+
+V1 should use the standard library HTTP client unless an accepted provider requires functionality that cannot be implemented safely without a dependency. TLS verification is mandatory; redirects are disabled; the origin is fixed by the binding.
+
+## 7. Evaluation and promotion
+
+Promotion follows `fake → offline evaluation → shadow (optional) → explicit canary → active`:
+
+1. Keep the deterministic fake as the contract test oracle and degraded fallback indicator, not as a fabricated real answer.
+2. Run a versioned, secret-free evaluation corpus covering scope leakage, prompt injection, secret requests, unsupported citations, oversized input, timeout and malformed responses.
+3. A shadow provider result is never shown or committed and must use only data approved for shadow processing.
+4. Canary is explicit for the Creator Principal, with a fixed binding revision and immediate disable switch.
+5. Promotion records the evaluated adapter/model/binding revisions and thresholds. A stronger/newer model never inherits promotion automatically.
+6. Rollback retires the binding and returns explicit `PROVIDER_UNAVAILABLE`; continuity, Commit and existing deterministic product commands remain operational.
+
+## 8. Failure and observability
+
+Operational telemetry may record request ID, binding ID/revision, timings, byte counts, finish reason, HTTP status class and usage totals. It must not record prompt, context, response or credentials. Provider 429/5xx, timeout, invalid TLS, redirect and invalid response are separate health evidence.
+
+There is no durable semantic obligation to finish an advisory request after process loss. The caller may explicitly submit a new request. Background retry queues and unmanaged goroutines are not introduced.
+
+## 9. Implementation slices after acceptance
+
+1. Accept a decision record specifying the contract, deployment data policy and initial provider binding class.
+2. Add provider-neutral gateway types and fake contract tests without changing canonical modules.
+3. Add one provider adapter using fixed-origin HTTPS and an external secret file; add adversarial fake-server tests.
+4. Add authenticated Creator advisory endpoint and UI with no persistence or action conversion.
+5. Add Capability health/binding deployment, evaluation evidence and canary controls.
+6. Deploy on `docker.cin.su`, mount the provider secret only into cognitive worker, then verify no-LLM degraded operation and rollback.
+
+## 10. Decisions requiring explicit acceptance
+
+Implementation remains blocked until the Creator explicitly accepts:
+
+1. advisory-only first slice, with no tools and no automatic actions;
+2. initial provider/API and model family;
+3. whether any user/context content may leave the private infrastructure;
+4. provider retention/training policy required for the binding;
+5. initial hard limits for message/context/output and request rate;
+6. no server-side conversation persistence in V1;
+7. evaluation/canary thresholds and acceptable operating cost.
+
+No choice above is inferred from possession of credentials or broad machine access.