Update wehago matching logic and exclude reports

.dockerignore

@@ -0,0 +1,15 @@
+.git
+.env
+.venv
+__pycache__
+*.pyc
+data.db
+data.db-wal
+data.db-shm
+backups
+runtime_cache
+static/exports
+scripts/.chrome-wehago-profile
+scripts/data_download
+reports
+dump.sql

.env.docker.example

@@ -0,0 +1,19 @@
+INTRANET_PORT=8010
+# Windows Docker Desktop에서 compose를 실행할 때는 아래 UNC 경로를 사용합니다.
+INTRANET_RUNTIME_ROOT=\\wsl.localhost\Ubuntu\home\b17301\intranet-runtime
+WEHAGO_HOST_SOURCE_ROOT=\\wsl.localhost\Ubuntu\home\b17301\WEHAGO_DB
+# WSL 내부 docker CLI를 정상 사용할 수 있는 환경이면 아래 Linux 경로도 사용할 수 있습니다.
+# INTRANET_RUNTIME_ROOT=/home/b17301/intranet-runtime
+# WEHAGO_HOST_SOURCE_ROOT=/home/b17301/WEHAGO_DB
+APP_UID=1000
+APP_GID=1000
+INTRANET_DB_PATH=/home/b17301/intranet-runtime/db/data.db
+INTRANET_BACKUP_DIR=/home/b17301/intranet-runtime/backups
+INTRANET_CACHE_ROOT=/home/b17301/intranet-runtime/cache
+INTRANET_COMPARE_EXPORT_DIR=/home/b17301/intranet-runtime/exports/wehago_compare
+INTRANET_HANMAC_EXPORT_DIR=/home/b17301/intranet-runtime/exports/hanmac
+WEHAGO_SOURCE_ROOT=/home/b17301/WEHAGO_DB
+INTRANET_REQUIRE_SAFE_SQLITE=0
+INTRANET_WAL_WARN_BYTES=268435456
+INTRANET_WAL_BLOCK_HEAVY_BYTES=536870912
+HM_APP_MAINTENANCE_ENABLED=0

.gitignore

@@ -1,5 +1,26 @@
 .venv/
+.env
 __pycache__/
 *.pyc
 data.db-shm
 data.db-wal
+backups/
+tmp_*.py
+static/exports/
+scripts/data_download/
+scripts/.chrome-wehago-profile/
+runtime_cache/
+intranet-runtime/
+.dev-state/
+reports/
+static/reports/
+runtime_diagnostics/
+.local-tools/
+*.pdf
+*.xls
+*.xlsx
+WORK_SUMMARY_*.md
+DB_HEALTH_CHECK_*.md
+backup_snapshots/**/*.md
+reports/hanmac_related_party_loans_*.xlsx
+reports/wehago_account_fixes/

DB_HEALTH_CHECK_20260409.md

@@ -1,169 +0,0 @@
-# DB Health Check 2026-04-09
-
-## Summary
-
-- Current SQLite size and row counts are still within a manageable range for this app.
-- Main medium-term risks were:
-  - concurrent writes causing `database is locked`
-  - all users sharing one `project_page_state` row
-  - growing scan cost around billing-link and project-status entry access
-- These were addressed without data loss.
-
-## Current Scale
-
-- `transactions`: about 49k rows
-- `project_contract_info`: 760 rows
-- `project_billing_entries`: 1,774 rows
-- `project_related_links`: 1,276 rows
-- `project_status`: few rows now, but each row can contain many logical sub-entries
-
-## Improvements Applied
-
-### 1. SQLite concurrency and durability tuning
-
-Applied on every DB connection in [main.py](/home/b17301/my-intranet-app/main.py#L39):
-
-- `PRAGMA journal_mode=WAL`
-- `PRAGMA synchronous=NORMAL`
-- `PRAGMA foreign_keys=ON`
-- `PRAGMA busy_timeout=5000`
-- `PRAGMA temp_store=MEMORY`
-
-Effect:
-
-- better concurrent read/write behavior
-- lower chance of write collisions during multi-user editing
-- safer long-running usage than SQLite defaults
-
-### 2. Added indexes for growth hotspots
-
-Added in [main.py](/home/b17301/my-intranet-app/main.py#L119):
-
-- `transactions`
-  - `idx_transactions_support_category`
-  - `idx_transactions_support_account`
-  - `idx_transactions_source_file`
-  - `idx_transactions_updated_at`
-- `project_billing_entries`
-  - `idx_project_billing_entries_raw_code`
-  - `idx_project_billing_entries_round_code`
-  - `idx_project_billing_entries_source_file`
-  - `idx_project_billing_entries_updated_at`
-- `project_related_links`
-  - `idx_project_related_links_related`
-- `project_page_state`
-  - `idx_project_page_state_page_session`
-
-Effect:
-
-- faster changed-round grouping
-- better support/account based project aggregations
-- faster source-file based reimport paths
-- safer scaling as billing and transaction history grows
-
-### 3. Page state changed from shared row to session-scoped rows
-
-The old structure used one shared record:
-
-- `project_page_state(page_key PRIMARY KEY, ...)`
-
-This meant different users could overwrite each other's selected project, year, and open/closed detail state.
-
-It now migrates to:
-
-- `project_page_state(page_key, session_id, ...)`
-- primary key: `(page_key, session_id)`
-
-Relevant code:
-
-- schema migration: [main.py](/home/b17301/my-intranet-app/main.py#L264)
-- load/save logic: [main.py](/home/b17301/my-intranet-app/main.py#L1970)
-- API: [main.py](/home/b17301/my-intranet-app/main.py#L3473)
-- browser session id: [templates/base.html](/home/b17301/my-intranet-app/templates/base.html#L538)
-- client page-state save/load: [templates/projects.html](/home/b17301/my-intranet-app/templates/projects.html#L4880)
-
-Effect:
-
-- browser A and browser B no longer fight over one shared project-search state
-
-### 4. Project status JSON blobs normalized into child tables
-
-Previously, logical row collections were stored only inside JSON columns in `project_status`:
-
-- `collection_entries_json`
-- `task_plan_entries_json`
-- `exec_budget_entries_json`
-- `actual_input_entries_json`
-
-This has now been normalized into child tables:
-
-- `project_collection_entries`
-- `project_task_plan_entries`
-- `project_exec_budget_entries`
-- `project_actual_input_entries`
-
-Relevant code:
-
-- row extraction and migration helpers: [main.py](/home/b17301/my-intranet-app/main.py#L987)
-- child-table schema: [main.py](/home/b17301/my-intranet-app/main.py#L273)
-- migration from legacy JSON: [main.py](/home/b17301/my-intranet-app/main.py#L1201)
-- project status read paths: [main.py](/home/b17301/my-intranet-app/main.py#L2143)
-- project status save path: [main.py](/home/b17301/my-intranet-app/main.py#L3323)
-
-Effect:
-
-- less dependence on large JSON blobs for active reads
-- cleaner future path for per-section editing
-- safer long-term maintainability
-
-## Backward Compatibility
-
-Legacy JSON columns are still kept in `project_status` for compatibility and rollback safety.
-
-Current behavior:
-
-- reads prefer normalized child rows
-- if child rows do not exist, legacy JSON/scalar fallback still works
-- writes update both:
-  - scalar summary fields
-  - legacy JSON cache
-  - normalized child rows
-
-This avoids data loss during migration.
-
-## Remaining Structural Risk
-
-The biggest remaining architectural limitation is:
-
-- `project_status` still acts as one large parent record for many independently editable sections
-
-So while row collections are normalized now, parent-level fields such as:
-
-- project type
-- expected rates
-- contract amount
-- dates
-- notes
-
-still live together in one row and one update flow.
-
-This is acceptable for now, but if many users edit the same project simultaneously, the next best improvement would be:
-
-1. split edit APIs by section
-2. add per-section revision tracking
-3. optionally move more parent fields into section-specific tables
-
-## Recommendation
-
-Current DB can continue operating efficiently with the applied changes.
-
-Recommended next step if the app keeps expanding:
-
-- introduce section-level save endpoints for
-  - collection
-  - task plan
-  - exec budget
-  - actual input
-  - project metadata
-
-That would reduce cross-section write conflicts even more.

Dockerfile

@@ -0,0 +1,54 @@
+FROM python:3.12-slim-bookworm
+
+ARG SQLITE_ARCHIVE=sqlite-autoconf-3530100.tar.gz
+ARG SQLITE_URL=https://www.sqlite.org/2026/sqlite-autoconf-3530100.tar.gz
+ARG SQLITE_SHA3_256=36ca143645cf76997d07b66e9244c636b8ccdec64a1d50558259c4e415e6558b
+ARG APP_UID=1000
+ARG APP_GID=1000
+
+ENV PYTHONDONTWRITEBYTECODE=1 \
+    PYTHONUNBUFFERED=1 \
+    LD_LIBRARY_PATH=/usr/local/lib \
+    INTRANET_DB_PATH=/runtime/db/data.db \
+    INTRANET_BACKUP_DIR=/runtime/backups \
+    INTRANET_CACHE_ROOT=/runtime/cache \
+    INTRANET_COMPARE_EXPORT_DIR=/runtime/exports/wehago_compare \
+    INTRANET_HANMAC_EXPORT_DIR=/runtime/exports/hanmac \
+    WEHAGO_SOURCE_ROOT=/source/wehago \
+    INTRANET_REQUIRE_SAFE_SQLITE=1
+
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends build-essential ca-certificates curl \
+    && curl -fsSL "${SQLITE_URL}" -o "/tmp/${SQLITE_ARCHIVE}" \
+    && python -c "import hashlib, pathlib; p=pathlib.Path('/tmp/${SQLITE_ARCHIVE}'); actual=hashlib.sha3_256(p.read_bytes()).hexdigest(); expected='${SQLITE_SHA3_256}'; assert actual == expected, (actual, expected)" \
+    && mkdir -p /tmp/sqlite-src \
+    && tar -xzf "/tmp/${SQLITE_ARCHIVE}" -C /tmp/sqlite-src --strip-components=1 \
+    && cd /tmp/sqlite-src \
+    && ./configure --prefix=/usr/local --enable-shared --disable-static \
+    && make -j2 \
+    && make install \
+    && ldconfig \
+    && python -c "import sqlite3; assert sqlite3.sqlite_version_info >= (3, 51, 3), sqlite3.sqlite_version" \
+    && rm -rf /tmp/sqlite-src "/tmp/${SQLITE_ARCHIVE}" \
+    && apt-get purge -y --auto-remove build-essential curl \
+    && rm -rf /var/lib/apt/lists/*
+
+WORKDIR /app
+
+COPY requirements.txt /app/requirements.txt
+RUN pip install --no-cache-dir -r /app/requirements.txt
+
+COPY . /app
+
+RUN mkdir -p /runtime/db /runtime/backups /runtime/cache /runtime/exports/wehago_compare /runtime/exports/hanmac \
+    && groupadd --gid "${APP_GID}" intranet \
+    && useradd --create-home --uid "${APP_UID}" --gid "${APP_GID}" intranet \
+    && chown -R intranet:intranet /app /runtime
+
+USER intranet
+EXPOSE 8010
+
+HEALTHCHECK --interval=30s --timeout=5s --start-period=20s --retries=3 \
+    CMD python -c "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8010/health', timeout=3).read()"
+
+CMD ["python", "main.py"]

WORK_SUMMARY_20260408.md

@@ -1,23 +0,0 @@
-# 작업 요약
-
-작업일: 2026-04-08
-
-## 핵심 변경
-
-- 프로젝트 검색 성능 저하 구간을 줄이기 위해 검색 목록 렌더 흐름을 정리하고 표시 개수를 제한했습니다.
-- 프로젝트 정보 페이지의 상세 레이아웃을 재구성해 상단 정보 카드의 중첩 박스를 제거하고 주요 지표 배치를 정리했습니다.
-- 계획 대비 실제 비교에서 인건비, 외주비, 제경비, A/S비, 판관비 세부 로직과 실제 집행 합산 기준을 여러 차례 보정했습니다.
-- 실투입 관리, 실행예산계획, 과업수행계획 입력 UI와 저장 구조를 정리했습니다.
-- 대시보드 상단을 재구성해 사업현황 요약과 수금/지출 구성 그래프를 다시 배치했습니다.
-- 프로젝트 페이지 상태 저장은 버튼 클릭 시 DB에 저장되도록 연결했습니다.
-
-## 주요 파일
-
-- `main.py`
-- `templates/base.html`
-- `templates/dashboard.html`
-- `templates/projects.html`
-
-## 참고
-
-- 템플릿 백업은 `template_backups/20260408_ko/`에 생성했습니다.

WORK_SUMMARY_20260409.md

@@ -1,50 +0,0 @@
-# 작업 요약 2026-04-09
-
-## 이번 반영 범위
-
-- 프로젝트 정보 페이지 안정화
-  - 저장 후 프로젝트 정보 화면이 비거나 모달이 갑자기 닫히는 문제 구조 개선
-  - 프로젝트 검색/상세/미계약 비용 발생 현황의 데이터 흐름 및 자동 최신화 충돌 완화
-  - 바로가기, 연관 프로젝트, 세부 내역 정렬/표시 개선
-
-- 사업현황 추가/수정 저장 구조 보강
-  - 프로젝트 저장을 DB 기준으로 즉시 반영되도록 보강
-  - 수금정보 분류값 정리
-    - 기성구분: `선급금 / 기성금 / 준공금`
-    - 청구구분: `계약분 / 기타`
-  - 실행예산/실투입/예상 배분 설정 연계 보강
-
-- 계약/청구/변경계약 데이터 반영
-  - 계약현황, 기성청구현황, 변경계약금액현황(총괄/차수) 파일을 DB에 반영
-  - 변경차수/보완/연계 프로젝트 자동 연결 로직 보강
-  - 본계약과 연결 가능한 건은 상세 페이지와 연관 프로젝트 태그/집행내역에 합산 반영
-
-- DB 구조 및 안정성 개선
-  - 설정성 하드코딩 일부를 DB 설정 테이블로 이동
-  - 프로젝트 입력 데이터의 섹션 분리 구조 확장
-  - 건강 점검 문서 추가: `DB_HEALTH_CHECK_20260409.md`
-
-- 대시보드 / 연도별 수익·비용 UI 개선
-  - 대시보드 카드/그래프 구조 정리
-  - 연도별 수익/비용 그래프 크기, 라벨, 축, 카드 활용도 개선
-  - 페이지 공통 여백 구조 정리
-
-## 주요 수정 파일
-
-- `main.py`
-- `templates/projects.html`
-- `templates/annual_summary.html`
-- `templates/base.html`
-- `templates/dashboard.html`
-- `templates/index.html`
-- `data.db`
-
-## 참고 데이터 파일
-
-- `변경계약금액현황(회계)_총괄_20210101_20260409_260409.xlsx`
-- `변경계약금액현황(회계)_차수_20210101_20260409_260409.xlsx`
-
-## 비고
-
-- SQLite 기반 운영은 현재 데이터 규모에서는 가능하지만, 동시 작업과 화면 상태 저장은 계속 점검이 필요함
-- `data.db-wal`, `data.db-shm` 같은 런타임 임시 파일은 커밋 대상에서 제외함

backup_snapshots/20260410_0900/DB_HEALTH_CHECK_20260409.md

@@ -1,169 +0,0 @@
-# DB Health Check 2026-04-09
-
-## Summary
-
-- Current SQLite size and row counts are still within a manageable range for this app.
-- Main medium-term risks were:
-  - concurrent writes causing `database is locked`
-  - all users sharing one `project_page_state` row
-  - growing scan cost around billing-link and project-status entry access
-- These were addressed without data loss.
-
-## Current Scale
-
-- `transactions`: about 49k rows
-- `project_contract_info`: 760 rows
-- `project_billing_entries`: 1,774 rows
-- `project_related_links`: 1,276 rows
-- `project_status`: few rows now, but each row can contain many logical sub-entries
-
-## Improvements Applied
-
-### 1. SQLite concurrency and durability tuning
-
-Applied on every DB connection in [main.py](/home/b17301/my-intranet-app/main.py#L39):
-
-- `PRAGMA journal_mode=WAL`
-- `PRAGMA synchronous=NORMAL`
-- `PRAGMA foreign_keys=ON`
-- `PRAGMA busy_timeout=5000`
-- `PRAGMA temp_store=MEMORY`
-
-Effect:
-
-- better concurrent read/write behavior
-- lower chance of write collisions during multi-user editing
-- safer long-running usage than SQLite defaults
-
-### 2. Added indexes for growth hotspots
-
-Added in [main.py](/home/b17301/my-intranet-app/main.py#L119):
-
-- `transactions`
-  - `idx_transactions_support_category`
-  - `idx_transactions_support_account`
-  - `idx_transactions_source_file`
-  - `idx_transactions_updated_at`
-- `project_billing_entries`
-  - `idx_project_billing_entries_raw_code`
-  - `idx_project_billing_entries_round_code`
-  - `idx_project_billing_entries_source_file`
-  - `idx_project_billing_entries_updated_at`
-- `project_related_links`
-  - `idx_project_related_links_related`
-- `project_page_state`
-  - `idx_project_page_state_page_session`
-
-Effect:
-
-- faster changed-round grouping
-- better support/account based project aggregations
-- faster source-file based reimport paths
-- safer scaling as billing and transaction history grows
-
-### 3. Page state changed from shared row to session-scoped rows
-
-The old structure used one shared record:
-
-- `project_page_state(page_key PRIMARY KEY, ...)`
-
-This meant different users could overwrite each other's selected project, year, and open/closed detail state.
-
-It now migrates to:
-
-- `project_page_state(page_key, session_id, ...)`
-- primary key: `(page_key, session_id)`
-
-Relevant code:
-
-- schema migration: [main.py](/home/b17301/my-intranet-app/main.py#L264)
-- load/save logic: [main.py](/home/b17301/my-intranet-app/main.py#L1970)
-- API: [main.py](/home/b17301/my-intranet-app/main.py#L3473)
-- browser session id: [templates/base.html](/home/b17301/my-intranet-app/templates/base.html#L538)
-- client page-state save/load: [templates/projects.html](/home/b17301/my-intranet-app/templates/projects.html#L4880)
-
-Effect:
-
-- browser A and browser B no longer fight over one shared project-search state
-
-### 4. Project status JSON blobs normalized into child tables
-
-Previously, logical row collections were stored only inside JSON columns in `project_status`:
-
-- `collection_entries_json`
-- `task_plan_entries_json`
-- `exec_budget_entries_json`
-- `actual_input_entries_json`
-
-This has now been normalized into child tables:
-
-- `project_collection_entries`
-- `project_task_plan_entries`
-- `project_exec_budget_entries`
-- `project_actual_input_entries`
-
-Relevant code:
-
-- row extraction and migration helpers: [main.py](/home/b17301/my-intranet-app/main.py#L987)
-- child-table schema: [main.py](/home/b17301/my-intranet-app/main.py#L273)
-- migration from legacy JSON: [main.py](/home/b17301/my-intranet-app/main.py#L1201)
-- project status read paths: [main.py](/home/b17301/my-intranet-app/main.py#L2143)
-- project status save path: [main.py](/home/b17301/my-intranet-app/main.py#L3323)
-
-Effect:
-
-- less dependence on large JSON blobs for active reads
-- cleaner future path for per-section editing
-- safer long-term maintainability
-
-## Backward Compatibility
-
-Legacy JSON columns are still kept in `project_status` for compatibility and rollback safety.
-
-Current behavior:
-
-- reads prefer normalized child rows
-- if child rows do not exist, legacy JSON/scalar fallback still works
-- writes update both:
-  - scalar summary fields
-  - legacy JSON cache
-  - normalized child rows
-
-This avoids data loss during migration.
-
-## Remaining Structural Risk
-
-The biggest remaining architectural limitation is:
-
-- `project_status` still acts as one large parent record for many independently editable sections
-
-So while row collections are normalized now, parent-level fields such as:
-
-- project type
-- expected rates
-- contract amount
-- dates
-- notes
-
-still live together in one row and one update flow.
-
-This is acceptable for now, but if many users edit the same project simultaneously, the next best improvement would be:
-
-1. split edit APIs by section
-2. add per-section revision tracking
-3. optionally move more parent fields into section-specific tables
-
-## Recommendation
-
-Current DB can continue operating efficiently with the applied changes.
-
-Recommended next step if the app keeps expanding:
-
-- introduce section-level save endpoints for
-  - collection
-  - task plan
-  - exec budget
-  - actual input
-  - project metadata
-
-That would reduce cross-section write conflicts even more.

backup_snapshots/20260410_0900/WORK_SUMMARY_20260408.md

@@ -1,23 +0,0 @@
-# 작업 요약
-
-작업일: 2026-04-08
-
-## 핵심 변경
-
-- 프로젝트 검색 성능 저하 구간을 줄이기 위해 검색 목록 렌더 흐름을 정리하고 표시 개수를 제한했습니다.
-- 프로젝트 정보 페이지의 상세 레이아웃을 재구성해 상단 정보 카드의 중첩 박스를 제거하고 주요 지표 배치를 정리했습니다.
-- 계획 대비 실제 비교에서 인건비, 외주비, 제경비, A/S비, 판관비 세부 로직과 실제 집행 합산 기준을 여러 차례 보정했습니다.
-- 실투입 관리, 실행예산계획, 과업수행계획 입력 UI와 저장 구조를 정리했습니다.
-- 대시보드 상단을 재구성해 사업현황 요약과 수금/지출 구성 그래프를 다시 배치했습니다.
-- 프로젝트 페이지 상태 저장은 버튼 클릭 시 DB에 저장되도록 연결했습니다.
-
-## 주요 파일
-
-- `main.py`
-- `templates/base.html`
-- `templates/dashboard.html`
-- `templates/projects.html`
-
-## 참고
-
-- 템플릿 백업은 `template_backups/20260408_ko/`에 생성했습니다.

backup_snapshots/20260410_0900/WORK_SUMMARY_20260409.md

@@ -1,50 +0,0 @@
-# 작업 요약 2026-04-09
-
-## 이번 반영 범위
-
-- 프로젝트 정보 페이지 안정화
-  - 저장 후 프로젝트 정보 화면이 비거나 모달이 갑자기 닫히는 문제 구조 개선
-  - 프로젝트 검색/상세/미계약 비용 발생 현황의 데이터 흐름 및 자동 최신화 충돌 완화
-  - 바로가기, 연관 프로젝트, 세부 내역 정렬/표시 개선
-
-- 사업현황 추가/수정 저장 구조 보강
-  - 프로젝트 저장을 DB 기준으로 즉시 반영되도록 보강
-  - 수금정보 분류값 정리
-    - 기성구분: `선급금 / 기성금 / 준공금`
-    - 청구구분: `계약분 / 기타`
-  - 실행예산/실투입/예상 배분 설정 연계 보강
-
-- 계약/청구/변경계약 데이터 반영
-  - 계약현황, 기성청구현황, 변경계약금액현황(총괄/차수) 파일을 DB에 반영
-  - 변경차수/보완/연계 프로젝트 자동 연결 로직 보강
-  - 본계약과 연결 가능한 건은 상세 페이지와 연관 프로젝트 태그/집행내역에 합산 반영
-
-- DB 구조 및 안정성 개선
-  - 설정성 하드코딩 일부를 DB 설정 테이블로 이동
-  - 프로젝트 입력 데이터의 섹션 분리 구조 확장
-  - 건강 점검 문서 추가: `DB_HEALTH_CHECK_20260409.md`
-
-- 대시보드 / 연도별 수익·비용 UI 개선
-  - 대시보드 카드/그래프 구조 정리
-  - 연도별 수익/비용 그래프 크기, 라벨, 축, 카드 활용도 개선
-  - 페이지 공통 여백 구조 정리
-
-## 주요 수정 파일
-
-- `main.py`
-- `templates/projects.html`
-- `templates/annual_summary.html`
-- `templates/base.html`
-- `templates/dashboard.html`
-- `templates/index.html`
-- `data.db`
-
-## 참고 데이터 파일
-
-- `변경계약금액현황(회계)_총괄_20210101_20260409_260409.xlsx`
-- `변경계약금액현황(회계)_차수_20210101_20260409_260409.xlsx`
-
-## 비고
-
-- SQLite 기반 운영은 현재 데이터 규모에서는 가능하지만, 동시 작업과 화면 상태 저장은 계속 점검이 필요함
-- `data.db-wal`, `data.db-shm` 같은 런타임 임시 파일은 커밋 대상에서 제외함

compose.dev.yaml

@@ -0,0 +1,6 @@
+services:
+  intranet-app:
+    environment:
+      INTRANET_AUTO_RELOAD: "1"
+    volumes:
+      - ./:/app:ro

compose.yaml

@@ -0,0 +1,33 @@
+services:
+  intranet-app:
+    build:
+      context: .
+      dockerfile: Dockerfile
+      args:
+        APP_UID: "${APP_UID:-1000}"
+        APP_GID: "${APP_GID:-1000}"
+    image: my-intranet-app:sqlite-3.53.1
+    container_name: my-intranet-app
+    restart: unless-stopped
+    environment:
+      INTRANET_PORT: "8010"
+      INTRANET_AUTO_RELOAD: "0"
+      INTRANET_REQUIRE_SAFE_SQLITE: "1"
+      INTRANET_WAL_WARN_BYTES: "268435456"
+      INTRANET_WAL_BLOCK_HEAVY_BYTES: "536870912"
+      HM_APP_MAINTENANCE_ENABLED: "0"
+      INTRANET_DB_PATH: /runtime/db/data.db
+      INTRANET_BACKUP_DIR: /runtime/backups
+      INTRANET_CACHE_ROOT: /runtime/cache
+      INTRANET_COMPARE_EXPORT_DIR: /runtime/exports/wehago_compare