Update deploy flow and asset UI

bible-local/architecture/runtime-flows.md

@@ -209,6 +209,9 @@ Mutating history operations are asynchronous and DB-backed (`history_recompute_j
   - may enqueue recompute jobs for affected entities
   - retries transient DB connection errors and continues on per-entity failures (best effort)
 - `Cleanup Orphaned Projections` removes registry/projection/raw rows for entities that have no active history left after cancellations.
+- Orphan cleanup candidate detection is not limited to `parts` / `machines` rows:
+  - dangling component/asset `timeline_events` without parent registry rows must also be removed
+  - asset orphan detection is evaluated after orphan component cleanup in the same run so installations deleted in step 1 can expose new orphan assets in step 2
 - `observations` usage in repair flows is allowed only as one-time recovery input; runtime state must still come from history + projections.
 
 ## Recompute Scope And Propagation

bible-local/architecture/ui-information-architecture.md

@@ -4,17 +4,22 @@
 
 Required section order:
 
-1. `Current Components`
-2. `Previous Components` (directly below Current Components)
-3. `Host Logs`
-4. `Movement & Events` (timeline cards)
+1. `Current Components / Host Logs`
+2. `Previous Components` (directly below Current Components / Host Logs)
+3. `Movement & Events` (timeline cards)
 
 `Previous Components` lists components that were previously installed on the asset and are currently removed.
 
-`Host Logs` is a dedicated asset log section for operational logs ingested from `host`, `bmc`, and `redfish`.
+`Current Components / Host Logs` is a single asset-page switcher section with two modes:
+- `Current Components`
+- `Host Logs`
+
+`Host Logs` mode is dedicated to operational logs ingested from `host`, `bmc`, and `redfish`.
 
 - It is separate from timeline/history cards.
+- Host logs mode uses full section width.
 - Default presentation is a filterable table/list ordered by newest `event_time` first.
+- Pagination is required in host logs mode.
 - Filters:
   - source (`host`, `bmc`, `redfish`)
   - severity
@@ -35,10 +40,16 @@ Required section order:
 `Current Components` interaction contract:
 
 - Section header uses the same right-aligned button row pattern as `Server Card`.
-- Buttons in header:
-  - `Add`
-  - `Edit`
-  - `Remove`
+- The left side of the header is a view switcher:
+  - `Current Components`
+  - `Host Logs`
+- Buttons in header depend on active mode:
+  - `Current Components` mode:
+    - `Add`
+    - `Edit`
+    - `Remove`
+  - `Host Logs` mode:
+    - `Refresh`
 - `Current Components` is a single filterable/selectable table (not grouped by type tables) to support bulk actions.
 - Table includes:
   - header `Select` checkbox (select all visible rows)

bible-local/decisions/2026-03-16-asset-page-components-hostlogs-switcher.md

@@ -0,0 +1,11 @@
+- Date: 2026-03-16
+- Decision: Asset page combines `Current Components` and `Host Logs` into one switcher section instead of rendering host logs as a separate card below components.
+- Context: Operators switch frequently between installed hardware view and operational logs for the same server. A separate host logs card pushes the log table too far down the page and wastes horizontal space.
+- Consequences:
+  - Asset page top data section exposes two view buttons: `Current Components` and `Host Logs`.
+  - `Host Logs` mode uses the full section width.
+  - Host logs pagination is explicit in the switcher view and does not reuse timeline cards.
+  - Component bulk action buttons are hidden in host logs mode and replaced with log-specific controls.
+- Affected:
+  - `bible-local/architecture/ui-information-architecture.md`
+  - `internal/api/ui_assets.tmpl`

bible-local/decisions/2026-03-16-local-deploy-platform-amd64.md

@@ -0,0 +1,12 @@
+- Date: 2026-03-16
+- Decision: `deploy.sh` local mode always builds, pulls, and runs `git.mchus.pro/reanimator/core` as `linux/amd64`, regardless of the operator host architecture.
+- Context: Developers run local deploy from Apple Silicon / ARM hosts, but the deployed container target is x86-compatible. Without an explicit runtime platform, Docker local pull/compose flow may select host architecture semantics and break the deploy.
+- Consequences:
+  - Local deploy uses `DOCKER_DEFAULT_PLATFORM=linux/amd64`.
+  - Local image pull is explicit: `docker pull --platform linux/amd64`.
+  - `deploy.sh` provides a dedicated `push only` mode that builds `linux/amd64` and publishes to Gitea Registry without any local or remote deploy step.
+  - The project deployment contract is now "local mode emulates x86 deploy target", not "local mode follows host CPU architecture".
+  - Local deploy resolves compose directory from `DEPLOY_DIR`, then falls back to repository-local `infra/reanimator/` when `/appdata/reanimator` is absent on the operator workstation.
+  - Reanimator compose configuration uses directory-local `./reanimator.env` so the same compose file works both in `/appdata/reanimator` and in repository-local deploy fallback.
+  - Deploy tag selection is explicit: compose image reference is parameterized by `REANIMATOR_IMAGE` and `REANIMATOR_TAG`, and `deploy.sh` exports them before `docker compose pull/up`.
+- Affected: `deploy.sh`

bible-local/decisions/2026-03-16-orphan-cleanup-secondary-assets-and-dangling-timeline.md

@@ -0,0 +1,10 @@
+- Date: 2026-03-16
+- Decision: `Cleanup Orphaned Projections` must remove dangling component/asset timeline residues even when the parent `parts`/`machines` row is already absent, and must detect orphan assets after orphan component cleanup in the same run.
+- Context: The previous cleanup implementation derived candidates only from `parts` / `machines` and computed orphan assets before deleting orphan component installations. This left behind dangling component timeline rows and assets that became orphan only after step 1.
+- Consequences:
+  - Orphan candidate collection now includes timeline-only component/asset ids with missing parent registry rows.
+  - Cleanup runs asset orphan detection after component cleanup side effects.
+  - A single cleanup execution is expected to converge without requiring a second manual run for these cases.
+- Affected:
+  - `internal/history/admin_cleanup_orphans.go`
+  - `bible-local/architecture/runtime-flows.md`