Skip to content
LEF LEF Docs
GitHubLinkedIn

TODO inventory

This page is generated from {/* TODO: ... */} blocks across the docs.

Do not edit by hand.

Generated by: npm run generate:todos

  • TODO blocks: 237
  • TODO items: 311

By section

Section titled “By section”
  • architecture: 12 blocks, 14 items
  • help-and-support: 4 blocks, 1 items
  • how-we-work: 75 blocks, 0 items
  • platforms-and-services: 21 blocks, 48 items
  • reference: 57 blocks, 107 items
  • run-and-maintenance: 68 blocks, 141 items

Details

Section titled “Details”

/architecture/archetypes/containers/connector/

Section titled “/architecture/archetypes/containers/connector/”
  • File: src/content/docs/architecture/archetypes/containers/connector.mdx
  • Section: architecture

Context: Canonical entry points

  • Add cross-links to any canonical “integration hub” service pages as they are created.
  • Capture security boundaries per pattern (public vs internal, auth context) without duplicating policy text.

/architecture/archetypes/infra/identity-authentication/

Section titled “/architecture/archetypes/infra/identity-authentication/”
  • File: src/content/docs/architecture/archetypes/infra/identity-authentication.mdx
  • Section: architecture

Context: Jump to facts / operate

  • Capture which authentication modes exist per archetype (SSO vs local users) and where exceptions are documented.

/architecture/archetypes/infra/

Section titled “/architecture/archetypes/infra/”
  • File: src/content/docs/architecture/archetypes/infra/index.mdx
  • Section: architecture

Context: Choose your path

  • Add a topology narrative that names the major hosting “regions” we use (public platforms vs EVEO private cloud) without duplicating server inventories.
  • Link out to the canonical server pages that define each runtime boundary.

/architecture/archetypes/infra/network-access/

Section titled “/architecture/archetypes/infra/network-access/”
  • File: src/content/docs/architecture/archetypes/infra/network-access.mdx
  • Section: architecture

Context: Jump to facts / operate

  • Document the canonical “public vs internal” boundary rules once agreed (Architecture-only, no step-by-step procedures here).

/architecture/archetypes/infra/storage-endpoints/

Section titled “/architecture/archetypes/infra/storage-endpoints/”
  • File: src/content/docs/architecture/archetypes/infra/storage-endpoints.mdx
  • Section: architecture

Context: Jump to facts / operate

  • Add an SFTP operational guide (where to request accounts/keys, and how file transfer is governed) if/when SFTP is used beyond ad-hoc transfers.

/architecture/archetypes/infra/tls-certificates/

Section titled “/architecture/archetypes/infra/tls-certificates/”
  • File: src/content/docs/architecture/archetypes/infra/tls-certificates.mdx
  • Section: architecture

Context: Jump to facts / operate

  • Capture the supported trust modes (public CA vs internal CA) and where each is expected to be used.
  • Add a canonical reference page for any internal CA(s) if/when it exists (facts only; no keys).

/architecture/archetypes/systems/report-app-environment/

Section titled “/architecture/archetypes/systems/report-app-environment/”
  • File: src/content/docs/architecture/archetypes/systems/report-app-environment.mdx
  • Section: architecture

Context: System context

  • Confirm canonical mobile app store listings and link them from Reference/Platform pages.

Context: Container model

Context: Where to go next

  • Confirm the canonical user entry points (mobile app names, web portal URL) and link them from the Reference service pages.
  • Confirm the runtime/container boundaries (what runs on np-ritmo vs shared services).

/architecture/archetypes/systems/sales-enablement/

Section titled “/architecture/archetypes/systems/sales-enablement/”
  • File: src/content/docs/architecture/archetypes/systems/sales-enablement.mdx
  • Section: architecture

Context: Where to go next

  • Confirm the canonical list of enablement domains (do not duplicate inventories here; link to Reference domain pages).

/architecture/archetypes/systems/thinkwise-environment/

Section titled “/architecture/archetypes/systems/thinkwise-environment/”
  • File: src/content/docs/architecture/archetypes/systems/thinkwise-environment.mdx
  • Section: architecture

Context: System context

Context: Where to go next

  • Capture “turn-key vs assisted vs support” responsibility boundaries once agreed (Architecture; no runbooks here).

/help-and-support/infra/troubleshooting/

Section titled “/help-and-support/infra/troubleshooting/”
  • File: src/content/docs/help-and-support/infra/troubleshooting/index.mdx
  • Section: help-and-support

Context: “Runtime / container issues”

  • Add a short “what to collect before asking for help” checklist (hostname, exact error, timestamp, where it happens, nginx/systemd logs).

/help-and-support/security/information-security-incident-response-procedure/

Section titled “/help-and-support/security/information-security-incident-response-procedure/”
  • File: src/content/docs/help-and-support/security/information-security-incident-response-procedure.mdx
  • Section: help-and-support

Context: Records / evidence

Context: Records / evidence

Context: Records / evidence

/how-we-work/engineering/guidelines/secure-development/

Section titled “/how-we-work/engineering/guidelines/secure-development/”
  • File: src/content/docs/how-we-work/engineering/guidelines/secure-development.mdx
  • Section: how-we-work

Context: 2) Secrets and credentials

Context: 4) Dependency and component hygiene

Context: 5) Logging and auditability

Context: Records / evidence

Context: Records / evidence

/how-we-work/engineering/reference/change-management/

Section titled “/how-we-work/engineering/reference/change-management/”
  • File: src/content/docs/how-we-work/engineering/reference/change-management.mdx
  • Section: how-we-work

Context: Change types (draft)

Context: Post-change review (draft)

/how-we-work/policies/access/access-control-policy/

Section titled “/how-we-work/policies/access/access-control-policy/”
  • File: src/content/docs/how-we-work/policies/access/access-control-policy.mdx
  • Section: how-we-work

Context: Records / evidence

Context: Records / evidence

Context: Records / evidence

Context: Exceptions and risk acceptance

/how-we-work/policies/continuity/backup-and-recovery-policy/

Section titled “/how-we-work/policies/continuity/backup-and-recovery-policy/”
  • File: src/content/docs/how-we-work/policies/continuity/backup-and-recovery-policy.mdx
  • Section: how-we-work

Context: Records / evidence

Context: Records / evidence

Context: Records / evidence

/how-we-work/policies/continuity/business-continuity-and-disaster-recovery-plan/

Section titled “/how-we-work/policies/continuity/business-continuity-and-disaster-recovery-plan/”
  • File: src/content/docs/how-we-work/policies/continuity/business-continuity-and-disaster-recovery-plan.mdx
  • Section: how-we-work

Context: Records / evidence

Context: Records / evidence

Context: Records / evidence

/how-we-work/policies/data/data-retention-and-deletion-policy/

Section titled “/how-we-work/policies/data/data-retention-and-deletion-policy/”
  • File: src/content/docs/how-we-work/policies/data/data-retention-and-deletion-policy.mdx
  • Section: how-we-work

Context: Records / evidence

Context: Records / evidence

Context: Records / evidence

/how-we-work/policies/data/information-classification-policy/

Section titled “/how-we-work/policies/data/information-classification-policy/”
  • File: src/content/docs/how-we-work/policies/data/information-classification-policy.mdx
  • Section: how-we-work

Context: Records / evidence

Context: Records / evidence

/how-we-work/policies/governance/document-control/

Section titled “/how-we-work/policies/governance/document-control/”
  • File: src/content/docs/how-we-work/policies/governance/document-control.mdx
  • Section: how-we-work

Context: 2. Roles (draft)

Context: 3.3 Publish and communicate

/how-we-work/policies/governance/

Section titled “/how-we-work/policies/governance/”
  • File: src/content/docs/how-we-work/policies/governance/index.mdx
  • Section: how-we-work

/how-we-work/policies/governance/information-security-policy/

Section titled “/how-we-work/policies/governance/information-security-policy/”
  • File: src/content/docs/how-we-work/policies/governance/information-security-policy.mdx
  • Section: how-we-work

Context: 2. Scope

Context: 4. Responsibilities (high level)

Context: 6. Exceptions and risk acceptance

/how-we-work/policies/governance/internal-audit/

Section titled “/how-we-work/policies/governance/internal-audit/”
  • File: src/content/docs/how-we-work/policies/governance/internal-audit.mdx
  • Section: how-we-work

Context: 2. Scope and criteria

Context: 3. Audit cadence (draft)

Context: 4. Independence (draft)

Context: 7. Records / evidence

/how-we-work/policies/governance/isms-scope/

Section titled “/how-we-work/policies/governance/isms-scope/”
  • File: src/content/docs/how-we-work/policies/governance/isms-scope.mdx
  • Section: how-we-work

Context: 1. Scope statement

Context: Included

Context: Excluded

Context: 3. Locations and interfaces

Context: 4. Interested parties & requirements

Context: 5. ISMS ownership and responsibilities

/how-we-work/policies/governance/management-review/

Section titled “/how-we-work/policies/governance/management-review/”
  • File: src/content/docs/how-we-work/policies/governance/management-review.mdx
  • Section: how-we-work

Context: 2. Attendees (draft)

Context: 5. Records / evidence

/how-we-work/policies/governance/nonconformity-and-corrective-action/

Section titled “/how-we-work/policies/governance/nonconformity-and-corrective-action/”
  • File: src/content/docs/how-we-work/policies/governance/nonconformity-and-corrective-action.mdx
  • Section: how-we-work

Context: 5. Records / evidence

/how-we-work/policies/iso-27001/

Section titled “/how-we-work/policies/iso-27001/”
  • File: src/content/docs/how-we-work/policies/iso-27001/index.mdx
  • Section: how-we-work

Context: What ISO 27001 typically expects (documentation artifacts)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Current coverage (high-level)

Context: Common gaps to plan for

/how-we-work/policies/people/

Section titled “/how-we-work/policies/people/”
  • File: src/content/docs/how-we-work/policies/people/index.mdx
  • Section: how-we-work

/how-we-work/policies/people/nda-checks-default/

Section titled “/how-we-work/policies/people/nda-checks-default/”
  • File: src/content/docs/how-we-work/policies/people/nda-checks-default.mdx
  • Section: how-we-work

Context: Records / evidence

/how-we-work/policies/risk/risk-management-methodology/

Section titled “/how-we-work/policies/risk/risk-management-methodology/”
  • File: src/content/docs/how-we-work/policies/risk/risk-management-methodology.mdx
  • Section: how-we-work

Context: 2. Inputs

Context: 3.2 Analyze and evaluate

Context: 4. Roles and responsibilities

Context: 5. Review cadence

/how-we-work/policies/risk/statement-of-applicability/

Section titled “/how-we-work/policies/risk/statement-of-applicability/”
  • File: src/content/docs/how-we-work/policies/risk/statement-of-applicability.mdx
  • Section: how-we-work

/how-we-work/policies/suppliers/supplier-security-policy/

Section titled “/how-we-work/policies/suppliers/supplier-security-policy/”
  • File: src/content/docs/how-we-work/policies/suppliers/supplier-security-policy.mdx
  • Section: how-we-work

Context: 2. Scope

Context: 3.1 Due diligence (before onboarding)

Context: Records / evidence

Context: Records / evidence

Context: Records / evidence

/how-we-work/todos/

Section titled “/how-we-work/todos/”
  • File: src/content/docs/how-we-work/todos.mdx
  • Section: how-we-work

/platforms-and-services/infra/proxy/api-hook/

Section titled “/platforms-and-services/infra/proxy/api-hook/”
  • File: src/content/docs/platforms-and-services/infra/proxy/api-hook.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who owns this endpoint and approves exposure changes)
  • Monitoring & alerting (where to check availability/errors)

/platforms-and-services/infra/proxy/cors-proxy/

Section titled “/platforms-and-services/infra/proxy/cors-proxy/”
  • File: src/content/docs/platforms-and-services/infra/proxy/cors-proxy.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who owns this proxy and approves changes)
  • Monitoring & alerting (where to check availability/errors)

/platforms-and-services/infra/proxy/tcp-proxy/

Section titled “/platforms-and-services/infra/proxy/tcp-proxy/”
  • File: src/content/docs/platforms-and-services/infra/proxy/tcp-proxy.mdx
  • Section: platforms-and-services

Context: Related

  • Add a short “security posture” note once the intended access model is confirmed (VPN-only, allowlists, auditing), without duplicating policy text.

/platforms-and-services/infra/services/certificate-authority/

Section titled “/platforms-and-services/infra/services/certificate-authority/”
  • File: src/content/docs/platforms-and-services/infra/services/certificate-authority.mdx
  • Section: platforms-and-services

Context: Where it runs

Context: Related

  • Ownership & support (who operates the Root CA / CA tooling)
  • Monitoring & alerting (where to check CA health)
  • Backup & recovery (how CA data/keys are backed up and recovered, if documented)

/platforms-and-services/infra/services/container-registry/

Section titled “/platforms-and-services/infra/services/container-registry/”
  • File: src/content/docs/platforms-and-services/infra/services/container-registry.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who operates the registry and approves deletions)
  • Monitoring & alerting (where to check registry health and storage use)

/platforms-and-services/infra/services/domain-controller/

Section titled “/platforms-and-services/infra/services/domain-controller/”
  • File: src/content/docs/platforms-and-services/infra/services/domain-controller.mdx
  • Section: platforms-and-services

Context: Related

  • Backup & recovery (how AD state is backed up and restored)
  • Monitoring & alerting (health checks and where they live)

/platforms-and-services/infra/services/entra-connect/

Section titled “/platforms-and-services/infra/services/entra-connect/”
  • File: src/content/docs/platforms-and-services/infra/services/entra-connect.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who maintains Entra Connect configuration)
  • Monitoring & alerting (where to check sync health and failures)

/platforms-and-services/infra/services/s3/

Section titled “/platforms-and-services/infra/services/s3/”
  • File: src/content/docs/platforms-and-services/infra/services/s3.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who operates MinIO and how to request changes)
  • Monitoring & alerting (where to check MinIO health)
  • Backup & recovery (how MinIO data is protected/recovered, if documented)

/platforms-and-services/infra/services/shared-assets/

Section titled “/platforms-and-services/infra/services/shared-assets/”
  • File: src/content/docs/platforms-and-services/infra/services/shared-assets.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who owns assets publishing and approves changes)
  • Monitoring & alerting (where to check availability and error rates)

/platforms-and-services/platforms/klippa/

Section titled “/platforms-and-services/platforms/klippa/”
  • File: src/content/docs/platforms-and-services/platforms/klippa/index.mdx
  • Section: platforms-and-services

Context: Overview

  • What we use Klippa for (use cases)
  • Entry points / URLs (admin + user)
  • Authentication model (SSO? local accounts?)
  • Ownership & support (who administers it)
  • Operational notes (backup, monitoring, incident handling)
  • Links to any internal integrations and runbooks

/platforms-and-services/platforms/report-app/

Section titled “/platforms-and-services/platforms/report-app/”
  • File: src/content/docs/platforms-and-services/platforms/report-app/index.mdx
  • Section: platforms-and-services

Context: Overview

  • What Report App is (product description) and what we resell
  • Entry points / URLs (admin + user)
  • Authentication model (SSO? local accounts?)
  • Ownership & support (who administers it)
  • Operational notes (backup, monitoring, incident handling)
  • Links to any internal integrations and runbooks

/platforms-and-services/services/engineering/github/

Section titled “/platforms-and-services/services/engineering/github/”
  • File: src/content/docs/platforms-and-services/services/engineering/github.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who administers the org and handles access requests)

/platforms-and-services/services/engineering/reporting/

Section titled “/platforms-and-services/services/engineering/reporting/”
  • File: src/content/docs/platforms-and-services/services/engineering/reporting.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who owns reporting endpoints and handles incidents)
  • Monitoring & alerting (where to check availability and error rates)

/platforms-and-services/services/engineering/uptime-monitoring/

Section titled “/platforms-and-services/services/engineering/uptime-monitoring/”
  • File: src/content/docs/platforms-and-services/services/engineering/uptime-monitoring.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who maintains checks/notifications)
  • Backup & recovery (how Uptime Kuma configuration/history is backed up, if documented)

/platforms-and-services/services/engineering/workflow-automation/

Section titled “/platforms-and-services/services/engineering/workflow-automation/”
  • File: src/content/docs/platforms-and-services/services/engineering/workflow-automation.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who owns workflows and approves new hooks)
  • Monitoring & alerting (where to check job/webhook failures)

/platforms-and-services/services/office/analytics/

Section titled “/platforms-and-services/services/office/analytics/”
  • File: src/content/docs/platforms-and-services/services/office/analytics.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who owns Analytics and handles requests/incidents)
  • Monitoring & alerting (where to check service health)

/platforms-and-services/services/office/kanban/

Section titled “/platforms-and-services/services/office/kanban/”
  • File: src/content/docs/platforms-and-services/services/office/kanban.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who owns Kanban and handles access requests/incidents)
  • Monitoring & alerting (where to check service health)

/platforms-and-services/services/office/microsoft-365/

Section titled “/platforms-and-services/services/office/microsoft-365/”
  • File: src/content/docs/platforms-and-services/services/office/microsoft-365.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who handles Microsoft 365 administration and incidents)

/platforms-and-services/services/office/vault/

Section titled “/platforms-and-services/services/office/vault/”
  • File: src/content/docs/platforms-and-services/services/office/vault.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who administers Vault and handles incidents)
  • Monitoring & alerting (where to check Vault health)
  • Backup & recovery (how Vault data is backed up and restored, if documented)

/platforms-and-services/services/office/wiki/

Section titled “/platforms-and-services/services/office/wiki/”
  • File: src/content/docs/platforms-and-services/services/office/wiki.mdx
  • Section: platforms-and-services

Context: Related

  • Ownership & support (who owns docs hosting and handles incidents)
  • Monitoring & alerting (where to check uptime/build failures)

/reference/domains/docs-lef/

Section titled “/reference/domains/docs-lef/”
  • File: src/content/docs/reference/domains/docs-lef.mdx
  • Section: reference

Context: Related

  • Confirm authoritative DNS provider, management UI, and DNS zone type.

/reference/domains/report-app-br/

Section titled “/reference/domains/report-app-br/”
  • File: src/content/docs/reference/domains/report-app-br.mdx
  • Section: reference

Context: Related

  • Confirm whether report.app.br is hosted in Hostinger (WordPress/static) or via EVEO + web.core.lef and document the authoritative DNS provider/nameservers.

/reference/environments/clients/sapore/

Section titled “/reference/environments/clients/sapore/”
  • File: src/content/docs/reference/environments/clients/sapore.mdx
  • Section: reference

Context: Related

  • Where it runs (backend host(s) and/or server pages)
  • Monitoring & alerting
  • Runbooks

/reference/environments/clients/solutions-dev/

Section titled “/reference/environments/clients/solutions-dev/”
  • File: src/content/docs/reference/environments/clients/solutions-dev.mdx
  • Section: reference

Context: Related

  • Where it runs (backend host(s) and/or server pages)
  • Monitoring & alerting
  • Runbooks

/reference/environments/clients/unimed/

Section titled “/reference/environments/clients/unimed/”
  • File: src/content/docs/reference/environments/clients/unimed.mdx
  • Section: reference

Context: Related

  • Where it runs (backend host(s) and/or server pages)
  • Monitoring & alerting
  • Runbooks

/reference/environments/internal/

Section titled “/reference/environments/internal/”
  • File: src/content/docs/reference/environments/internal/index.mdx
  • Section: reference

/reference/environments/internal/pivot/

Section titled “/reference/environments/internal/pivot/”
  • File: src/content/docs/reference/environments/internal/pivot.mdx
  • Section: reference

Context: Related

  • Where it runs (backend host(s) and/or server pages)
  • Monitoring & alerting
  • Runbooks

/reference/environments/internal/pivoted/

Section titled “/reference/environments/internal/pivoted/”
  • File: src/content/docs/reference/environments/internal/pivoted.mdx
  • Section: reference

Context: Related

  • Ownership & support (who owns My LEF and handles changes/incidents)
  • Monitoring & alerting (where to check availability and backend health)

/reference/environments/internal/trainee/

Section titled “/reference/environments/internal/trainee/”
  • File: src/content/docs/reference/environments/internal/trainee.mdx
  • Section: reference

Context: Related

  • Ownership & support (who owns the trainee platform and handles changes/incidents)
  • Monitoring & alerting (where to check availability and tier health)
  • Backup & recovery (database/app backup expectations and restore approach, if documented)

/reference/environments/pre-sales/concepts/

Section titled “/reference/environments/pre-sales/concepts/”
  • File: src/content/docs/reference/environments/pre-sales/concepts.mdx
  • Section: reference

Context: Related

  • Ownership & support (who owns this environment and handles changes/incidents)
  • Monitoring & alerting (where to check availability and tier health)
  • Backup & recovery (database/app backup expectations and restore approach, if documented)

/reference/environments/pre-sales/experience/

Section titled “/reference/environments/pre-sales/experience/”
  • File: src/content/docs/reference/environments/pre-sales/experience.mdx
  • Section: reference

Context: Related

  • Ownership & support (who owns this environment and handles changes/incidents)
  • Monitoring & alerting (where to check availability and backend health)
  • Backup & recovery (database/app backup expectations and restore approach, if documented)

/reference/environments/tokio-marine/credit-hub/

Section titled “/reference/environments/tokio-marine/credit-hub/”
  • File: src/content/docs/reference/environments/tokio-marine/credit-hub.mdx
  • Section: reference

Context: Related

  • Ownership & support (who owns this environment and handles changes/incidents)
  • Monitoring & alerting (where to check availability and backend health)
  • Backup & recovery (database/app backup expectations and restore approach, if documented)

/reference/environments/tokio-marine/tokio-dev/

Section titled “/reference/environments/tokio-marine/tokio-dev/”
  • File: src/content/docs/reference/environments/tokio-marine/tokio-dev.mdx
  • Section: reference

Context: Related

  • Where it runs (backend host(s) and/or server pages)
  • Monitoring & alerting
  • Runbooks

/reference/environments/tokio-marine/tokiocred/

Section titled “/reference/environments/tokio-marine/tokiocred/”
  • File: src/content/docs/reference/environments/tokio-marine/tokiocred.mdx
  • Section: reference

Context: Related

  • Where it runs (backend host(s) and/or server pages)
  • Dependencies (auth)
  • Monitoring & alerting
  • Runbooks

/reference/infra/access/firewall-reference/

Section titled “/reference/infra/access/firewall-reference/”
  • File: src/content/docs/reference/infra/access/firewall-reference.mdx
  • Section: reference

Context: Public IP block (EVEO-managed)

  • Reconcile the /28 block documented here with the /29 block referenced in the EVEO firewall bundle (confirm which block is used for public HTTP(S) ingress vs other purposes).

Context: Current allocations (HTTP/HTTPS)

  • If report.app.br is meant to be served from EVEO, document its public IP → internal VIP mapping (or remove this from the allocation list entirely).

Context: VPN-only web ingress (public DNS)

  • Confirm which hostnames are intended to resolve to 177.136.240.174 (and keep them in sync with the NGINX sites-enabled/vpn/ vhosts).
  • Reconcile the statement “SSL-VPN public IP is 177.136.240.162” with the current allocation table above (confirm whether 177.136.240.162 is used for VPN, HTTP(S), or both).

/reference/infra/databases/concepts-db-lef/

Section titled “/reference/infra/databases/concepts-db-lef/”
  • File: src/content/docs/reference/infra/databases/concepts-db-lef.mdx
  • Section: reference

Context: Related

  • Ownership & support (who maintains the concepts.db.lef routing)
  • Monitoring & alerting (where to check endpoint and backend health)

/reference/infra/databases/eveo-dbaas-sqlserver/

Section titled “/reference/infra/databases/eveo-dbaas-sqlserver/”
  • File: src/content/docs/reference/infra/databases/eveo-dbaas-sqlserver.mdx
  • Section: reference

Context: Related

  • Ownership & support (who owns the EVEO DBaaS relationship and incident escalation)
  • Monitoring & alerting (where to check service health and connectivity)

/reference/infra/databases/pivot-db-lef/

Section titled “/reference/infra/databases/pivot-db-lef/”
  • File: src/content/docs/reference/infra/databases/pivot-db-lef.mdx
  • Section: reference

Context: Related

  • Ownership & support (who maintains the pivot.db.lef routing)
  • Monitoring & alerting (where to check endpoint and backend health)

/reference/infra/databases/pivoted-db-lef/

Section titled “/reference/infra/databases/pivoted-db-lef/”
  • File: src/content/docs/reference/infra/databases/pivoted-db-lef.mdx
  • Section: reference

Context: Related

  • Ownership & support (who maintains the pivoted.db.lef routing)
  • Monitoring & alerting (where to check endpoint and backend health)

/reference/infra/databases/sapore-db-lef/

Section titled “/reference/infra/databases/sapore-db-lef/”
  • File: src/content/docs/reference/infra/databases/sapore-db-lef.mdx
  • Section: reference

Context: Related

  • Ownership & support (who maintains the sapore.db.lef routing)
  • Monitoring & alerting (where to check endpoint and backend health)

/reference/infra/databases/sicoob-db-lef/

Section titled “/reference/infra/databases/sicoob-db-lef/”
  • File: src/content/docs/reference/infra/databases/sicoob-db-lef.mdx
  • Section: reference

Context: Related

  • Ownership & support (who maintains the sicoob.db.lef routing)
  • Monitoring & alerting (where to check endpoint and backend health)

/reference/infra/databases/solutions-db-lef/

Section titled “/reference/infra/databases/solutions-db-lef/”
  • File: src/content/docs/reference/infra/databases/solutions-db-lef.mdx
  • Section: reference

Context: Related

  • Ownership & support (who maintains the solutions.db.lef routing)
  • Monitoring & alerting (where to check endpoint and backend health)

/reference/infra/databases/tokio-db-lef/

Section titled “/reference/infra/databases/tokio-db-lef/”
  • File: src/content/docs/reference/infra/databases/tokio-db-lef.mdx
  • Section: reference

Context: Related

  • Ownership & support (who maintains the tokio.db.lef routing)
  • Monitoring & alerting (where to check endpoint and backend health)

/reference/infra/databases/tokio-prod-db-lef/

Section titled “/reference/infra/databases/tokio-prod-db-lef/”
  • File: src/content/docs/reference/infra/databases/tokio-prod-db-lef.mdx
  • Section: reference

Context: Related

  • Ownership & support (who maintains the tokio-prod.db.lef routing and the EVEO DBaaS relationship)
  • Monitoring & alerting (where to check endpoint and backend health)

/reference/infra/databases/tools-db-lef/

Section titled “/reference/infra/databases/tools-db-lef/”
  • File: src/content/docs/reference/infra/databases/tools-db-lef.mdx
  • Section: reference

Context: Related

  • Ownership & support (who maintains the tools.db.lef routing)
  • Monitoring & alerting (where to check endpoint and backend health)

/reference/infra/databases/trainee-db-lef/

Section titled “/reference/infra/databases/trainee-db-lef/”
  • File: src/content/docs/reference/infra/databases/trainee-db-lef.mdx
  • Section: reference

Context: Related

  • Ownership & support (who maintains the trainee.db.lef routing)
  • Monitoring & alerting (where to check endpoint and backend health)

/reference/infra/databases/unimed-db-lef/

Section titled “/reference/infra/databases/unimed-db-lef/”
  • File: src/content/docs/reference/infra/databases/unimed-db-lef.mdx
  • Section: reference

Context: Related

  • Ownership & support (who maintains the unimed.db.lef routing)
  • Monitoring & alerting (where to check endpoint and backend health)

/reference/infra/networks/core-lan/

Section titled “/reference/infra/networks/core-lan/”
  • File: src/content/docs/reference/infra/networks/core-lan.mdx
  • Section: reference

Context: Related private addresses (not in this subnet)

  • VLAN ID / tagging details (if any).
  • Reserved ranges (DHCP, static reservations, VIP ranges beyond 112–120, etc).
  • Confirm whether any additional subnets exist behind VPN besides those referenced in docs.

/reference/infra/networks/vlan-2061/

Section titled “/reference/infra/networks/vlan-2061/”
  • File: src/content/docs/reference/infra/networks/vlan-2061.mdx
  • Section: reference

Context: What it’s for (current)

  • Default gateway / router IP for 192.168.50.0/24.
  • What else is routed on this subnet (other endpoints, services, or provider-managed devices).
  • Confirm the purpose/scope of VLAN 2061 (e.g., DBaaS-only vs broader private routing).

/reference/infra/networks/vpn-client-addressing/

Section titled “/reference/infra/networks/vpn-client-addressing/”
  • File: src/content/docs/reference/infra/networks/vpn-client-addressing.mdx
  • Section: reference

Context: Related

  • Confirm the VPN client address pool CIDR (not just an example IP).
  • Confirm whether different VPN groups receive different pools/routes.

/reference/infra/proxy/tcp-proxy/

Section titled “/reference/infra/proxy/tcp-proxy/”
  • File: src/content/docs/reference/infra/proxy/tcp-proxy.mdx
  • Section: reference

Context: VIP IPs (LAN)

  • Confirm whether these VIP IPs are stable allocations or an operational implementation detail that can change without notice.
  • Capture a “last verified” timestamp/source for the VIP allocation table (e.g., DNS export or firewall/proxy config), rather than ad-hoc scanning.

Context: Related

  • Ownership & support (who maintains HAProxy routes for *.db.lef)
  • Monitoring & alerting (where to check endpoint and HAProxy health)

/reference/infra/servers/bare-metal/lab-core-lef/

Section titled “/reference/infra/servers/bare-metal/lab-core-lef/”
  • File: src/content/docs/reference/infra/servers/bare-metal/lab-core-lef.mdx
  • Section: reference

Context: Related

  • Monitoring & alerting (what signals indicate host/resource health)

/reference/infra/servers/external/ext-sapore-lef/

Section titled “/reference/infra/servers/external/ext-sapore-lef/”
  • File: src/content/docs/reference/infra/servers/external/ext-sapore-lef.mdx
  • Section: reference

Context: Overview

  • Confirm where this host runs (provider/platform) and how it is managed.
  • Confirm OS (or document why OS is not applicable for this host).
  • Confirm entry points (hostname, ports, VPN/LAN requirement) and access workflow.
  • Confirm whether this host participates in internal DNS zones or is purely external.

/reference/infra/servers/external/hostinger/

Section titled “/reference/infra/servers/external/hostinger/”
  • File: src/content/docs/reference/infra/servers/external/hostinger.mdx
  • Section: reference

Context: Inventory

  • Confirm whether we have SSH/SFTP access for this hosting plan (and document the workflow if so).
  • Confirm whether OS is relevant for this provider surface (or document why it is not tracked here).

Context: Related

  • Provider dashboard entrypoint (URL) and access workflow

/reference/infra/servers/private-cloud/alma-core-lef/

Section titled “/reference/infra/servers/private-cloud/alma-core-lef/”
  • File: src/content/docs/reference/infra/servers/private-cloud/alma-core-lef.mdx
  • Section: reference

Context: Operational notes

  • If/when np-ritmo is provisioned, confirm whether 2 vCPU are reallocated from VM105 (np-alma) and update vCPU above.

Context: Related

  • Monitoring & alerting (how environment/host health is monitored)

/reference/infra/servers/private-cloud/coragem-core-lef/

Section titled “/reference/infra/servers/private-cloud/coragem-core-lef/”
  • File: src/content/docs/reference/infra/servers/private-cloud/coragem-core-lef.mdx
  • Section: reference

Context: Related

  • Monitoring & alerting (how environment/host health is monitored)

/reference/infra/servers/private-cloud/dc-core-lef/

Section titled “/reference/infra/servers/private-cloud/dc-core-lef/”
  • File: src/content/docs/reference/infra/servers/private-cloud/dc-core-lef.mdx
  • Section: reference

Context: Related

  • Monitoring & alerting (what signals indicate AD/DC health)
  • Backup & recovery (how this DC is backed up and how restore is performed)

/reference/infra/servers/private-cloud/dns-core-lef/

Section titled “/reference/infra/servers/private-cloud/dns-core-lef/”
  • File: src/content/docs/reference/infra/servers/private-cloud/dns-core-lef.mdx
  • Section: reference

Context: Related

  • Monitoring & alerting (how DNS health is monitored)

/reference/infra/servers/private-cloud/np-leftec-hipervisora-1/

Section titled “/reference/infra/servers/private-cloud/np-leftec-hipervisora-1/”
  • File: src/content/docs/reference/infra/servers/private-cloud/np-leftec-hipervisora-1.mdx
  • Section: reference

Context: Capacity add-ons (contract)

  • Confirm whether the pool totals above include the signed add-ons (+8 GB RAM / +100 GB SSD) and the scope of the existing “provisioned extras”.

Context: Related

  • Confirm whether operators have any direct hypervisor management access (URL/host, auth model), or whether EVEO-only.
  • Confirm the Proxmox UI URL/port and access model for 192.168.20.100 (and whether access is EVEO-only or shared).
  • Confirm PBS details for storage_backup (endpoint, ownership, storage sizing, restore procedure).
  • Confirm which /29 block is associated with this item and where it is used.

/reference/infra/servers/private-cloud/proxy-core-lef/

Section titled “/reference/infra/servers/private-cloud/proxy-core-lef/”
  • File: src/content/docs/reference/infra/servers/private-cloud/proxy-core-lef.mdx
  • Section: reference

Context: Related

  • Monitoring & alerting (how HAProxy and endpoint health are monitored)

/reference/infra/servers/private-cloud/rds-core-lef/

Section titled “/reference/infra/servers/private-cloud/rds-core-lef/”
  • File: src/content/docs/reference/infra/servers/private-cloud/rds-core-lef.mdx
  • Section: reference

Context: Related

  • Monitoring & alerting (how RDP host availability is monitored)

/reference/infra/servers/private-cloud/ritmo-core-lef/

Section titled “/reference/infra/servers/private-cloud/ritmo-core-lef/”
  • File: src/content/docs/reference/infra/servers/private-cloud/ritmo-core-lef.mdx
  • Section: reference

Context: Inventory

  • Add VMID (Proxmox) once the VM is provisioned.
  • Add LAN IP and the canonical hostname (if any) once confirmed.

Context: Entry points

  • Confirm how users reach this VM (hostname, ports, and whether there is a service URL).

/reference/infra/servers/private-cloud/storage-core-lef/

Section titled “/reference/infra/servers/private-cloud/storage-core-lef/”
  • File: src/content/docs/reference/infra/servers/private-cloud/storage-core-lef.mdx
  • Section: reference

Context: Known risks / failure modes

  • Monitoring & alerting (how storage/minio health is monitored)
  • Host-level VM backup is provided by EVEO (see np-leftec-hipervisorA-1).

/reference/infra/servers/private-cloud/tokio-core-lef/

Section titled “/reference/infra/servers/private-cloud/tokio-core-lef/”
  • File: src/content/docs/reference/infra/servers/private-cloud/tokio-core-lef.mdx
  • Section: reference

Context: Related

  • Monitoring & alerting (how environment/host health is monitored)

/reference/infra/servers/private-cloud/tools-core-lef/

Section titled “/reference/infra/servers/private-cloud/tools-core-lef/”
  • File: src/content/docs/reference/infra/servers/private-cloud/tools-core-lef.mdx
  • Section: reference

Context: Operational notes

  • Storage expansion: allocate +40 GB to this VM (VM104) to grow /dev/mapper/almalinux-root from 17 GB to 17 GB + 40 GB, and then update Disk above.

Context: Related

  • Monitoring & alerting (how host and key tool health is monitored)

/reference/infra/servers/private-cloud/web-core-lef/

Section titled “/reference/infra/servers/private-cloud/web-core-lef/”
  • File: src/content/docs/reference/infra/servers/private-cloud/web-core-lef.mdx
  • Section: reference

Context: VPN-only ingress VIP (required)

  • Confirm whether 192.168.20.111 is already configured on web.core.lef (and which ens18:<n> alias index is used).

Context: Related

  • Monitoring & alerting (where to check reverse proxy health)

/reference/technology/

Section titled “/reference/technology/”
  • File: src/content/docs/reference/technology/index.mdx
  • Section: reference

Context: SQL Server (TCP) (11)

  • Decide whether we want a canonical supplier/provider inventory page under /reference/ (and what fields it must contain).

/reference/technology/thinkwise-versions/

Section titled “/reference/technology/thinkwise-versions/”
  • File: src/content/docs/reference/technology/thinkwise-versions/index.mdx
  • Section: reference

Context: Runtimes

/run-and-maintenance/infra/access/vpn-access/

Section titled “/run-and-maintenance/infra/access/vpn-access/”
  • File: src/content/docs/run-and-maintenance/infra/access/vpn-access.mdx
  • Section: run-and-maintenance

Context: VPN authorization (groups)

  • Confirm the purpose and effective access scope of the VPN Entra group.

/run-and-maintenance/infra/app-tiers/platform/analytics/

Section titled “/run-and-maintenance/infra/app-tiers/platform/analytics/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/platform/analytics.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

/run-and-maintenance/infra/app-tiers/platform/certificate-authority/

Section titled “/run-and-maintenance/infra/app-tiers/platform/certificate-authority/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/platform/certificate-authority.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • Document the decommission date and removal steps for this legacy service.
  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

/run-and-maintenance/infra/app-tiers/platform/container-registry/

Section titled “/run-and-maintenance/infra/app-tiers/platform/container-registry/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/platform/container-registry.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health
  • Storage path and cleanup (GC) procedures

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

/run-and-maintenance/infra/app-tiers/platform/cors-proxy/

Section titled “/run-and-maintenance/infra/app-tiers/platform/cors-proxy/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/platform/cors-proxy.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

/run-and-maintenance/infra/app-tiers/platform/kanban/

Section titled “/run-and-maintenance/infra/app-tiers/platform/kanban/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/platform/kanban.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

/run-and-maintenance/infra/app-tiers/platform/reporting/

Section titled “/run-and-maintenance/infra/app-tiers/platform/reporting/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/platform/reporting.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name(s) or compose project(s))
  • Logs location and where to check health

Context: Runtime version

  • Image (include all runtimes if multiple)
  • Version (tag or digest)
  • How to check running version

/run-and-maintenance/infra/app-tiers/platform/s3/

Section titled “/run-and-maintenance/infra/app-tiers/platform/s3/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/platform/s3.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name(s) or compose project(s))
  • Logs location and where to check health

Context: Runtime version

  • Image (include all runtimes if multiple)
  • Version (tag or digest)
  • How to check running version

/run-and-maintenance/infra/app-tiers/platform/uptime-kuma/

Section titled “/run-and-maintenance/infra/app-tiers/platform/uptime-kuma/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/platform/uptime-kuma.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

/run-and-maintenance/infra/app-tiers/platform/vault/

Section titled “/run-and-maintenance/infra/app-tiers/platform/vault/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/platform/vault.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

/run-and-maintenance/infra/app-tiers/platform/wiki/

Section titled “/run-and-maintenance/infra/app-tiers/platform/wiki/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/platform/wiki.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

/run-and-maintenance/infra/app-tiers/platform/workflow-automation/

Section titled “/run-and-maintenance/infra/app-tiers/platform/workflow-automation/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/platform/workflow-automation.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check job/webhook health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

/run-and-maintenance/infra/app-tiers/thinkwise/concepts/

Section titled “/run-and-maintenance/infra/app-tiers/thinkwise/concepts/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/thinkwise/concepts.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

Context: Thinkwise versions

  • Thinkwise platform version
  • Universal GUI version

/run-and-maintenance/infra/app-tiers/thinkwise/credit-hub/

Section titled “/run-and-maintenance/infra/app-tiers/thinkwise/credit-hub/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/thinkwise/credit-hub.mdx
  • Section: run-and-maintenance

Context: Dependencies

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

Context: Thinkwise versions

  • Thinkwise platform version
  • Universal GUI version

/run-and-maintenance/infra/app-tiers/thinkwise/pivot/

Section titled “/run-and-maintenance/infra/app-tiers/thinkwise/pivot/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/thinkwise/pivot.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • How to check running version

Context: Thinkwise versions

Context: Thinkwise versions

  • How to check

/run-and-maintenance/infra/app-tiers/thinkwise/pivoted/

Section titled “/run-and-maintenance/infra/app-tiers/thinkwise/pivoted/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/thinkwise/pivoted.mdx
  • Section: run-and-maintenance

Context: Dependencies

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

Context: Thinkwise versions

  • Thinkwise platform version
  • Universal GUI version

/run-and-maintenance/infra/app-tiers/thinkwise/sapore/

Section titled “/run-and-maintenance/infra/app-tiers/thinkwise/sapore/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/thinkwise/sapore.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

Context: Thinkwise versions

  • Thinkwise platform version
  • Universal GUI version

/run-and-maintenance/infra/app-tiers/thinkwise/solutions-dev/

Section titled “/run-and-maintenance/infra/app-tiers/thinkwise/solutions-dev/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/thinkwise/solutions-dev.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

Context: Thinkwise versions

  • Thinkwise platform version
  • Universal GUI version

/run-and-maintenance/infra/app-tiers/thinkwise/tokio-dev/

Section titled “/run-and-maintenance/infra/app-tiers/thinkwise/tokio-dev/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/thinkwise/tokio-dev.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

Context: Thinkwise versions

  • Thinkwise platform version
  • Universal GUI version

/run-and-maintenance/infra/app-tiers/thinkwise/tokiocred/

Section titled “/run-and-maintenance/infra/app-tiers/thinkwise/tokiocred/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/thinkwise/tokiocred.mdx
  • Section: run-and-maintenance

Context: Dependencies

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

Context: Thinkwise versions

  • Thinkwise platform version
  • Universal GUI version

/run-and-maintenance/infra/app-tiers/thinkwise/trainee-platform/

Section titled “/run-and-maintenance/infra/app-tiers/thinkwise/trainee-platform/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/thinkwise/trainee-platform.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

Context: Thinkwise versions

  • Thinkwise platform version
  • Universal GUI version

/run-and-maintenance/infra/app-tiers/thinkwise/unimed/

Section titled “/run-and-maintenance/infra/app-tiers/thinkwise/unimed/”
  • File: src/content/docs/run-and-maintenance/infra/app-tiers/thinkwise/unimed.mdx
  • Section: run-and-maintenance

Context: Runtime & maintenance

  • How to restart safely (systemd unit name or compose project)
  • Logs location and where to check health

Context: Runtime version

  • Image
  • Version (tag or digest)
  • How to check running version

Context: Thinkwise versions

  • Thinkwise platform version
  • Universal GUI version

/run-and-maintenance/infra/operations/certificates/ca-lef/

Section titled “/run-and-maintenance/infra/operations/certificates/ca-lef/”
  • File: src/content/docs/run-and-maintenance/infra/operations/certificates/ca-lef.mdx
  • Section: run-and-maintenance

Context: What this covers

  • Where the Root CA lives (offline machine vs secured VM) and who has access.
  • Backup/recovery approach for the CA key and database.
  • How AD CS is configured for Windows servers (CA name, templates, auto-enrollment).

Context: Windows Server certificates (AD CS)

  • Document the AD CS CA name and enrollment method (MMC vs auto-enrollment).
  • Document templates used for RDP/server certificates and required SANs.

/run-and-maintenance/infra/operations/certificates/remote-desktop-ssl/

Section titled “/run-and-maintenance/infra/operations/certificates/remote-desktop-ssl/”
  • File: src/content/docs/run-and-maintenance/infra/operations/certificates/remote-desktop-ssl.mdx
  • Section: run-and-maintenance

Context: Prerequisites

  • Document where AD CS runs and which CA name/templates to select.
  • Confirm whether auto-enrollment is enabled (GPO) for RDP/server certificates.

/run-and-maintenance/infra/proxy/cors-proxy/

Section titled “/run-and-maintenance/infra/proxy/cors-proxy/”
  • File: src/content/docs/run-and-maintenance/infra/proxy/cors-proxy.mdx
  • Section: run-and-maintenance

Context: Update allowlists / behavior (backend)

  • Capture where the allowlist lives (repo/config path/service unit) and how to deploy changes safely.
  • Capture the minimal logging that should exist for auditing (request origin + target), without logging secrets.

/run-and-maintenance/infra/proxy/nginx-vhost-templates/

Section titled “/run-and-maintenance/infra/proxy/nginx-vhost-templates/”
  • File: src/content/docs/run-and-maintenance/infra/proxy/nginx-vhost-templates.mdx
  • Section: run-and-maintenance

Context: Current vhosts by pattern (observed)

  • List the hostnames intended to be served via the VPN-only VIP (192.168.20.111 / public IP 177.136.240.174).

/run-and-maintenance/infra/proxy/provision-web-ingress-proxy/

Section titled “/run-and-maintenance/infra/proxy/provision-web-ingress-proxy/”
  • File: src/content/docs/run-and-maintenance/infra/proxy/provision-web-ingress-proxy.mdx
  • Section: run-and-maintenance

Context: 1) Create/update the server definition page (Reference)

Context: 2) Provision the VM (platform)

  • Capture the exact EVEO/Proxmox workflow for requesting/creating a new VM (who does it, required inputs, where to confirm VMID).

Context: 8) Cutover (warm standby only)

  • Document whether EVEO firewall requires any additional coordination when a VIP moves to a different host (e.g. ARP/MAC pinning), or if it self-heals via ARP.

/run-and-maintenance/infra/proxy/tcp-proxy/

Section titled “/run-and-maintenance/infra/proxy/tcp-proxy/”
  • File: src/content/docs/run-and-maintenance/infra/proxy/tcp-proxy.mdx
  • Section: run-and-maintenance

Context: 3) Update HAProxy routing

  • Capture the canonical HAProxy config file path(s) on proxy.core.lef.
  • Capture the canonical reload command (systemd unit name) and any validation check (haproxy -c, etc).

/run-and-maintenance/infra/proxy/virtual-ips/

Section titled “/run-and-maintenance/infra/proxy/virtual-ips/”
  • File: src/content/docs/run-and-maintenance/infra/proxy/virtual-ips.mdx
  • Section: run-and-maintenance

Context: Add a DB endpoint VIP (proxy.core.lef)

  • Capture the canonical HAProxy config file path and reload command on proxy.core.lef (then replace this TODO with concrete steps).

/run-and-maintenance/platforms/thinkwise/installation/

Section titled “/run-and-maintenance/platforms/thinkwise/installation/”
  • File: src/content/docs/run-and-maintenance/platforms/thinkwise/installation/index.mdx
  • Section: run-and-maintenance

Context: Environment notes (capture per project)

  • Add a canonical “Thinkwise environment install notes” section to the environment template (if we want these fields standardized across installs).

/run-and-maintenance/security/vulnerability-management-procedure/

Section titled “/run-and-maintenance/security/vulnerability-management-procedure/”
  • File: src/content/docs/run-and-maintenance/security/vulnerability-management-procedure.mdx
  • Section: run-and-maintenance

Context: Records / evidence

Context: Records / evidence

Context: Records / evidence