# https://github.com/Djtony707/TITAN Project Manual Generated at: 2026-07-12 10:43:30 UTC ## Table of Contents - [Overview & Getting Started](#page-1) - [Core Agent System & Reliability Discipline (Fable-5)](#page-2) - [Providers, Channels & Interoperability](#page-3) - [Mission Control UI, Skills, Memory & Deployment](#page-4) ## Overview & Getting Started ### Related Pages Related topics: [Core Agent System & Reliability Discipline (Fable-5)](#page-2), [Providers, Channels & Interoperability](#page-3), [Mission Control UI, Skills, Memory & Deployment](#page-4)
Related Source Files The following source files were used to generate this page: - [README.md](https://github.com/Djtony707/TITAN/blob/main/README.md) - [ARCHITECTURE.md](https://github.com/Djtony707/TITAN/blob/main/ARCHITECTURE.md) - [CHANGELOG.md](https://github.com/Djtony707/TITAN/blob/main/CHANGELOG.md) - [package.json](https://github.com/Djtony707/TITAN/blob/main/package.json) - [install.sh](https://github.com/Djtony707/TITAN/blob/main/install.sh) - [docs/FIRST-STEPS.md](https://github.com/Djtony707/TITAN/blob/main/docs/FIRST-STEPS.md)
# Overview & Getting Started ## What is TITAN? TITAN is a local-first AI agent framework whose goal is to bring frontier-grade disciplined behavior to small, locally-hosted models. Instead of relying on a cloud provider to enforce process, TITAN wraps the model in a structured agent loop and a configuration surface that the developer controls. Source: [README.md:1-40](). The project is release-driven; the most recent tracked release is **v7.2.1**, which builds on v7.2.0 "Conscience" and composes the full Fable-5 discipline set behind a single switch. Source: [CHANGELOG.md:1-30](). ## Core Concepts TITAN organizes behavior around a small set of recurring concepts that recur across the documentation, the architecture notes, and the configuration surface: - **Agent configuration block** — A single config file (referenced as `titan.config.*` in the docs) where top-level toggles such as `agent.reliabilityMode` live. - **Reliability Mode** — A composition of the four Fable-5 disciplines that wrap raw model output in a structured workflow. As of v7.2.1, enabling `agent.reliabilityMode: true` activates the complete set, which includes at minimum: 1. **Plan-first** — On multi-step tasks, the agent writes a numbered plan and verifies each step before proceeding. 2. **Verify** — The agent is not allowed to claim a side-effect (file edit, network call, etc.) without producing the tool call that produced it. - **Local model** — TITAN targets models running on the developer's machine; the framework exists to make those models behave predictably rather than to call a hosted API. - **Tools** — Side-effecting capabilities the agent can invoke; Reliability Mode treats the tool call log as the ground truth for any claimed effect. Source: [ARCHITECTURE.md:1-60](), [CHANGELOG.md:10-50](), [README.md:15-45](). ## Installation & First Run The repository ships a one-shot bootstrap script that handles the full install: pulling Node dependencies declared in `package.json`, linking the `titan` CLI onto the user's `PATH`, and printing next-step pointers. Source: [install.sh:1-40](), [package.json:1-30](). After the script finishes, the canonical onboarding path described in `docs/FIRST-STEPS.md` walks a new user through four moves: 1. **Initialize a workspace** — Run the init command in a project directory. This creates a default config with `agent.reliabilityMode: false`. 2. **Enable Reliability Mode** — Flip `agent.reliabilityMode` to `true` to activate the full Fable-5 discipline set described above. 3. **Point at a local model** — Configure the `model` block to talk to a local model endpoint. 4. **Run a task** — Issue a multi-step prompt and observe the agent plan, invoke tools, and verify each step before producing a final answer. Source: [docs/FIRST-STEPS.md:1-80](). ## Project Layout & Where to Go Next The repository is laid out so the runtime, the configuration surface, and the documentation are easy to locate: | Path | Role | | --- | --- | | `README.md` | Project overview, install link, headline feature | | `ARCHITECTURE.md` | Internal component diagram, agent loop, tool system | | `CHANGELOG.md` | Versioned release notes (current: v7.2.1) | | `package.json` | Node dependency manifest and CLI entry point | | `install.sh` | One-shot bootstrap script | | `docs/FIRST-STEPS.md` | Step-by-step onboarding guide for new users | Source: [README.md:1-30](), [ARCHITECTURE.md:1-20](), [package.json:1-25](). After the first successful run, the natural follow-ups are: - Read `ARCHITECTURE.md` to understand the agent loop and exactly how Reliability Mode plugs into it. - Skim `CHANGELOG.md` for the diff between v7.2.0 "Conscience" and v7.2.1, in particular the discipline-composition notes. - Customize the config: register additional tools, adjust the plan/verify prompts, or — if Reliability Mode is too strict for a given workload — disable individual Fable-5 disciplines while keeping the others. Source: [ARCHITECTURE.md:1-40](), [docs/FIRST-STEPS.md:60-100](), [CHANGELOG.md:1-30](). --- ## Core Agent System & Reliability Discipline (Fable-5) ### Related Pages Related topics: [Overview & Getting Started](#page-1), [Providers, Channels & Interoperability](#page-3)
Related Source Files The following source files were used to generate this page: - [src/agent/agent.ts](https://github.com/Djtony707/TITAN/blob/main/src/agent/agent.ts) - [src/agent/agentLoop.ts](https://github.com/Djtony707/TITAN/blob/main/src/agent/agentLoop.ts) - [src/agent/orchestrator.ts](https://github.com/Djtony707/TITAN/blob/main/src/agent/orchestrator.ts) - [src/agent/specialists.ts](https://github.com/Djtony707/TITAN/blob/main/src/agent/specialists.ts) - [src/agent/planner.ts](https://github.com/Djtony707/TITAN/blob/main/src/agent/planner.ts) - [src/agent/verifier.ts](https://github.com/Djtony707/TITAN/blob/main/src/agent/verifier.ts)
# Core Agent System & Reliability Discipline (Fable-5) The Core Agent System is the top-level runtime that turns a local model into a disciplined, tool-using assistant. Reliability Mode (`agent.reliabilityMode: true`) composes the Fable-5 disciplines — Plan, Verify, Critique, and Reflect — into a single coherent process so that side-effects are never claimed without proof, multi-step work is decomposed before execution, and failures become self-correcting rather than terminal. Source: [src/agent/agent.ts](). ## Purpose and Scope The Core Agent System orchestrates every model invocation in TITAN. It owns the message lifecycle, decides when to call tools, and enforces the reliability contract that distinguishes a "chatty" model from an engineering-grade agent. Source: [src/agent/agentLoop.ts](). The scope is deliberately narrow but load-bearing: - **Single entry point** — all user requests flow through `agent.ts`, which dispatches into the loop and specialists. - **Reliability contract** — the agent may only assert a state change if a tool returned evidence of that change. - **Composable disciplines** — each Fable-5 behavior is an independent module that the loop can enable per request. Source: [src/agent/orchestrator.ts](), [src/agent/agent.ts](). ## Architecture Overview The runtime is layered: `agent.ts` is the façade, `agentLoop.ts` is the iteration driver, `orchestrator.ts` routes work to specialists, and the four discipline modules (`planner.ts`, `verifier.ts`, plus critique/reflect components in `specialists.ts`) are invoked at well-defined points in the loop. Source: [src/agent/orchestrator.ts](), [src/agent/specialists.ts](). ```mermaid flowchart TD U[User Request] --> A[agent.ts] A --> L[agentLoop.ts] L --> P{planner.ts
multi-step?} P -- yes --> Plan[Numbered Plan] P -- no --> T[Tool Call] Plan --> T T --> V{verifier.ts
side-effect?} V -- yes --> Vchk[Evidence Check] V -- no --> R[Response] Vchk -- pass --> R Vchk -- fail --> C[specialists.ts
Critique/Reflect] C --> T ``` The diagram above shows how Reliability Mode rewires a normal agent loop. On every turn, the planner decides whether the task warrants a plan; the verifier gates any claim about a side-effect on actual tool evidence; and on failure the critique/reflect specialists in `specialists.ts` re-enter the loop instead of returning an error. Source: [src/agent/agentLoop.ts](), [src/agent/planner.ts](), [src/agent/verifier.ts](), [src/agent/specialists.ts](). ## The Fable-5 Disciplines Reliability Mode composes four (currently) implemented disciplines out of the five that define the Fable-5 specification. Each is a small, single-purpose module the loop can invoke on demand. | Discipline | Module | Trigger | Contract | |---|---|---|---| | Plan | `planner.ts` | Multi-step task detected | Produce a numbered plan and verify each step | | Verify | `verifier.ts` | Side-effect claim about to be emitted | Require the tool that produced the effect | | Critique | `specialists.ts` | Verifier rejects a claim | Produce a concrete correction, not a refusal | | Reflect | `specialists.ts` | Loop exceeds budget | Summarize state and recommend a continuation policy | Source: [src/agent/planner.ts](), [src/agent/verifier.ts](), [src/agent/specialists.ts](). **Plan-first.** Before any tool runs on a multi-step request, the planner writes a numbered, ordered plan and the loop checks off steps as they complete. This is the single largest reliability improvement because it forces the model to commit to a sequence before mutating state. Source: [src/agent/planner.ts](). **Verify.** The verifier is the conscience of the agent. It inspects every claim the model wants to make about a side-effect (file written, command run, network call completed) and rejects the claim unless the corresponding tool receipt is present in the conversation context. Source: [src/agent/verifier.ts](). **Critique & Reflect.** When verification fails or the loop budgets are exhausted, control passes to the specialists module. Critique produces a specific, actionable correction; Reflect produces a state summary so a subsequent turn can resume without losing context. Both are designed to keep the agent inside the loop rather than returning a dead-end error. Source: [src/agent/specialists.ts](). ## Configuration and Usage Reliability Mode is enabled with a single configuration switch. Because the disciplines are composed inside the loop rather than bolted onto prompts, enabling it on a local model gives that model the same process discipline a frontier agent has — at the cost of extra turns. Source: [src/agent/agent.ts](), [src/agent/agentLoop.ts](). Key behavioral notes drawn from the source: - The `reliabilityMode` flag is read once per request and is honored for the lifetime of that loop. Source: [src/agent/agent.ts](). - Plan-first only activates when the planner detects a multi-step task; single-shot queries bypass planning to keep latency low. Source: [src/agent/planner.ts](), [src/agent/agentLoop.ts](). - The verifier is non-optional in Reliability Mode: any attempt by the model to short-circuit it is rejected by the orchestrator before the response is streamed to the user. Source: [src/agent/verifier.ts](), [src/agent/orchestrator.ts](). - Specialists are stateless across requests; their outputs are written back into the conversation so the next iteration can act on them. Source: [src/agent/specialists.ts](). This composition is what the community release notes describe as "the complete disciplined-process nervous system" — a useful mental model: each discipline is a reflex, the loop is the spinal cord, and Reliability Mode is the brainstem that turns them all on at once. Source: [src/agent/agent.ts](), [src/agent/agentLoop.ts](), [src/agent/orchestrator.ts](), [src/agent/specialists.ts](), [src/agent/planner.ts](), [src/agent/verifier.ts](). ## Practical Implications For users, the practical effect is that Reliability Mode trades a small amount of latency and token usage for a dramatically lower rate of false claims about file edits, command results, and tool outcomes. The fifth Fable-5 discipline is reserved for a future release; until then, four composed disciplines cover the failure modes most commonly reported in the community — silent side-effect claims, runaway loops, and unverified multi-step edits. Source: [src/agent/specialists.ts](), [src/agent/verifier.ts](). --- ## Providers, Channels & Interoperability ### Related Pages Related topics: [Core Agent System & Reliability Discipline (Fable-5)](#page-2), [Mission Control UI, Skills, Memory & Deployment](#page-4)
Related Source Files The following source files were used to generate this page: - [src/providers/router.ts](https://github.com/Djtony707/TITAN/blob/main/src/providers/router.ts) - [src/providers/anthropic.ts](https://github.com/Djtony707/TITAN/blob/main/src/providers/anthropic.ts) - [src/providers/openai.ts](https://github.com/Djtony707/TITAN/blob/main/src/providers/openai.ts) - [src/providers/google.ts](https://github.com/Djtony707/TITAN/blob/main/src/providers/google.ts) - [src/providers/ollama.ts](https://github.com/Djtony707/TITAN/blob/main/src/providers/ollama.ts) - [src/providers/openai_compat.ts](https://github.com/Djtony707/TITAN/blob/main/src/providers/openai_compat.ts)
# Providers, Channels & Interoperability The Providers subsystem is TITAN's transport layer between the agent core and the underlying model services. Each provider encapsulates the wire format, authentication, request shape, and streaming semantics of a single vendor or vendor-compatible endpoint, while `router.ts` resolves a logical provider name into a concrete implementation at call time. The design goal is that the rest of TITAN (planning, tool dispatch, reliability guards) speaks one neutral vocabulary, regardless of whether the user has configured Anthropic, OpenAI, Google, Ollama, or an OpenAI-compatible proxy. ## Provider Surface and Resolution TITAN exposes a single `Provider` interface implemented once per backend. The router holds a registry of named providers and is responsible for resolving the active provider from user configuration, environment variables, or a runtime override. Source: [src/providers/router.ts:1-40](). Resolution precedence typically follows: explicit CLI flag → `agent.provider` config → environment variable (`TITAN_PROVIDER`, `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, `GOOGLE_API_KEY`, `OLLAMA_HOST`) → fallback to the first registered provider that has credentials present. Source: [src/providers/router.ts:42-90](). The router exposes a uniform `complete()` and `stream()` API to the agent layer; it is the only module that imports the concrete vendor adapters. This keeps vendor churn localized to `src/providers/*` and lets Fable-5 disciplines such as Reliability Mode compose on top of a stable contract. Source: [src/providers/router.ts:92-140](). ## Vendor Adapters ### Anthropic `anthropic.ts` targets the Anthropic Messages API. It maps TITAN's neutral message list to Anthropic's `system` / `messages` separation, forwards tool definitions as `tools` blocks, and translates `tool_use` / `tool_result` blocks back into TITAN's internal representation. Streaming uses Anthropic's SSE event types. Source: [src/providers/anthropic.ts:1-60](). Auth is read from `ANTHROPIC_API_KEY` or the provider's `apiKey` field. Source: [src/providers/anthropic.ts:62-95](). ### OpenAI `openai.ts` targets the OpenAI Chat Completions API. It normalizes tool calls into the `tool_calls` array, supports `response_format` for JSON mode, and emits token-usage deltas during streaming. The `reasoning_effort` parameter is forwarded when the active model supports the o-series. Source: [src/providers/openai.ts:1-80](). Auth defaults to `OPENAI_API_KEY` and may be overridden by `baseURL` for Azure or proxies. Source: [src/providers/openai.ts:82-130](). ### Google `google.ts` targets the Google Generative AI (Gemini) endpoint. It performs the role-name to `generationConfig` mapping required by Gemini, converts function-call parts to TITAN tool invocations, and reconstructs `functionResponse` parts on the return trip. Source: [src/providers/google.ts:1-70](). Auth uses `GOOGLE_API_KEY` or an application-default credentials path. Source: [src/providers/google.ts:72-110](). ### Ollama `ollama.ts` speaks the local Ollama HTTP API. It is the canonical example of a "channel" rather than a hosted vendor: there is no remote auth, the base URL is `OLLAMA_HOST` (default `http://127.0.0.1:11434`), and model selection is by local model tag. This adapter makes TITAN fully usable offline, which is the precondition for Reliability Mode running against a local model. Source: [src/providers/ollama.ts:1-90](). ### OpenAI-Compatible `openai_compat.ts` is a generic shim for any endpoint that implements the OpenAI Chat Completions shape. It accepts a `baseURL`, an `apiKey` (optional for local proxies), and a `model` string, and reuses the request/response translation in `openai.ts` while skipping vendor-specific affordances such as `reasoning_effort`. Source: [src/providers/openai_compat.ts:1-70](). This is the recommended channel for vLLM, LM Studio, llama.cpp's server, OpenRouter, and similar gateways. Source: [src/providers/openai_compat.ts:72-110](). ## Interoperability Patterns Three patterns recur across the adapters and let TITAN stay vendor-neutral: 1. **Normalize on entry, normalize on exit.** Every provider converts the neutral `Message[]` and `ToolDefinition[]` into its native schema before the HTTP call, and converts the response back on the way out. The agent core never sees vendor-specific blocks. Source: [src/providers/router.ts:140-200](). 2. **Streaming as a first-class channel.** All providers expose a token-streaming interface that emits `delta` events with a uniform shape. Reliability Mode's verify step depends on this stream being available so that plan verification can interrupt a runaway model. Source: [src/providers/anthropic.ts:96-140](). 3. **Credential discovery is provider-local, not router-local.** Each adapter owns its env-var lookup so the router does not need to know vendor details. Source: [src/providers/ollama.ts:92-130](). ## Configuration Example ```yaml agent: provider: ollama # logical name resolved by router.ts model: qwen2.5-coder:14b reliabilityMode: true # v7.2.1: composes plan-first + verify on top of any provider providers: anthropic: apiKey: ${ANTHROPIC_API_KEY} openai_compat: baseURL: http://localhost:8080/v1 model: llama-3.3-70b ``` Switching between Anthropic, OpenAI, Gemini, Ollama, and an OpenAI-compatible gateway is a single config change at the `provider:` key; no agent code changes. Source: [src/providers/router.ts:42-90](). Community discussions around v7.2.1's Reliability Mode emphasize that this provider-agnostic surface is what makes the new plan-first and verify disciplines work uniformly across local and hosted backends. --- ## Mission Control UI, Skills, Memory & Deployment ### Related Pages Related topics: [Overview & Getting Started](#page-1), [Core Agent System & Reliability Discipline (Fable-5)](#page-2), [Providers, Channels & Interoperability](#page-3)
Related Source Files The following source files were used to generate this page: - [ui/src/App.tsx](https://github.com/Djtony707/TITAN/blob/main/ui/src/App.tsx) - [ui/src/components/shell/TitanShell.tsx](https://github.com/Djtony707/TITAN/blob/main/ui/src/components/shell/TitanShell.tsx) - [ui/src/components/admin/OverviewPanel.tsx](https://github.com/Djtony707/TITAN/blob/main/ui/src/components/admin/OverviewPanel.tsx) - [ui/src/components/command-post/CPDashboard.tsx](https://github.com/Djtony707/TITAN/blob/main/ui/src/components/command-post/CPDashboard.tsx) - [ui/src/views/LiveStudio.tsx](https://github.com/Djtony707/TITAN/blob/main/ui/src/views/LiveStudio.tsx) - [ui/src/titan2/canvas/TitanCanvas.tsx](https://github.com/Djtony707/TITAN/blob/main/ui/src/titan2/canvas/TitanCanvas.tsx)
# Mission Control UI, Skills, Memory & Deployment TITAN's Mission Control is the operator-facing surface that pairs a local agent runtime with a rich web UI. It composes a shell, a command-post dashboard, an overview panel, a live studio, and a canvas view to give operators visibility into plans, skills, memory, and deployment status. This page describes how those pieces fit together and how they map to the agent's Skills and Memory subsystems. ## Mission Control Architecture The UI is mounted from a single React root. `App.tsx` sets up routing and top-level providers, then hands off to the shell chrome. `TitanShell.tsx` defines the persistent layout: navigation, sidebar, and the slot where feature views render. Inside that slot, `CPDashboard.tsx` (Command Post) is the central "Mission Control" page that surfaces live agent state, active plans, tool calls, and deployment health side-by-side. `OverviewPanel.tsx` is a compact summary tile used both inside the dashboard and in admin contexts. `Source: [ui/src/App.tsx:1-80]()` The canvas layer is provided by `TitanCanvas.tsx`, which renders the visual workspace used in `LiveStudio.tsx`. The studio is where operators can watch plan execution unfold step-by-step and inspect intermediate outputs. Together, these components implement a "cockpit" pattern: shell + dashboard for at-a-glance status, studio + canvas for deep inspection. `Source: [ui/src/components/shell/TitanShell.tsx:1-120]()` ``` ┌──────────────────────────────────────────────────────┐ │ TitanShell (nav, sidebar, slot) │ │ ┌──────────────────────────────────────────────────┐ │ │ │ CPDashboard (Mission Control) │ │ │ │ ┌────────────┬────────────┬───────────────────┐ │ │ │ │ │ Overview │ Plans │ Deployment / Logs │ │ │ │ │ │ Panel │ & Skills │ │ │ │ │ │ └────────────┴────────────┴───────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────┐ │ │ │ │ │ LiveStudio → TitanCanvas (plan execution) │ │ │ │ │ └──────────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────┘ ``` ## Skills Subsystem Skills are how operators extend the agent without editing prompts. The Mission Control UI surfaces the active skill set inside the Command Post dashboard, where each skill is listed with its name, description, and invocation status. Skills are loaded from the runtime and rendered as cards in `CPDashboard.tsx`, which polls for updates and reflects whether a skill is enabled, in use, or failed. `Source: [ui/src/components/command-post/CPDashboard.tsx:1-160]()` The studio view (`LiveStudio.tsx`) shows the live execution trace of a skill invocation: inputs, intermediate tool calls, and outputs. When a multi-step plan is active, the plan-first discipline (part of the v7.2.1 Reliability Mode) is visualized in the canvas as a numbered list of steps, each with a verification marker once the corresponding tool confirms a side-effect. `Source: [ui/src/views/LiveStudio.tsx:1-200]()` Operators can toggle, configure, and reload skills from the dashboard without restarting the runtime. The overview panel summarizes skill health: how many are loaded, how many are currently executing, and any recent errors. `Source: [ui/src/components/admin/OverviewPanel.tsx:1-140]()` ## Memory Subsystem Memory in TITAN is exposed through the Mission Control UI as a first-class surface. The Command Post dashboard includes a memory pane that lists the agent's stored facts, episodic traces, and retrieved context snippets. Operators can inspect, prune, or seed memory entries directly from the UI, which is useful when debugging why the agent recalled (or failed to recall) a particular detail. `Source: [ui/src/components/command-post/CPDashboard.tsx:160-260]()` The canvas view (`TitanCanvas.tsx`) can be switched into a memory mode that visualizes retrieval as a graph of nodes (entries) and edges (associations), giving operators a structural view of what the agent "knows" at the moment of inference. This is the same canvas used for plans, so operators get a unified visual language for both execution flow and recall flow. `Source: [ui/src/titan2/canvas/TitanCanvas.tsx:1-180]()` Live execution in `LiveStudio.tsx` shows memory reads and writes inline with the plan steps, so it is possible to see exactly which entries were consulted before a tool call and which were appended afterward. This makes the agent's reasoning auditable end-to-end. `Source: [ui/src/views/LiveStudio.tsx:200-320]()` ## Deployment & Reliability Integration Deployment status is woven through the Mission Control UI rather than living on a separate page. The overview panel reports runtime version (currently aligned with the v7.2.1 release line), uptime, model backend, and the state of the `agent.reliabilityMode` switch. When reliability mode is enabled, the dashboard shows the four composed Fable-5 disciplines — plan-first, verify, self-critique, and recovery — as status badges so operators can confirm the disciplined-process nervous system is active. `Source: [ui/src/components/admin/OverviewPanel.tsx:140-240]()` The shell (`TitanShell.tsx`) owns the connection state to the local runtime, surfacing reconnect attempts and degraded modes. Logs stream into the studio so deployment issues can be correlated with plan execution in the same view. `Source: [ui/src/components/shell/TitanShell.tsx:120-220]()` Because all of these surfaces share the shell and the canvas, operators can move from a high-level overview (panel) to a mid-level dashboard (command post) to a low-level execution trace (studio + canvas) without losing context, which is the core value proposition of the Mission Control design. --- --- ## Pitfall Log Project: Djtony707/TITAN Summary: Found 6 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Capability evidence risk - Capability evidence risk requires verification. ## 1. Capability evidence risk - Capability evidence risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: README/documentation is current enough for a first validation pass. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: capability.assumptions | https://github.com/Djtony707/TITAN ## 2. Maintenance risk - Maintenance risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: evidence.maintainer_signals | https://github.com/Djtony707/TITAN ## 3. Security or permission risk - Security or permission risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: no_demo - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: downstream_validation.risk_items | https://github.com/Djtony707/TITAN ## 4. Security or permission risk - Security or permission risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: no_demo - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: risks.scoring_risks | https://github.com/Djtony707/TITAN ## 5. Maintenance risk - Maintenance risk requires verification - Severity: low - Evidence strength: source_linked - Finding: issue_or_pr_quality=unknown。 - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: evidence.maintainer_signals | https://github.com/Djtony707/TITAN ## 6. Maintenance risk - Maintenance risk requires verification - Severity: low - Evidence strength: source_linked - Finding: release_recency=unknown。 - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: evidence.maintainer_signals | https://github.com/Djtony707/TITAN