A local-first system for official-document work, task and file tracking, drafting, weekly reports, document export, and controlled private synchronization.
HxHwang Gw is a pnpm monorepo that shares one domain model across a public GitHub Pages demonstration, separate Internet and intranet Web builds, and separate Internet and intranet Electron clients. It stores operational data locally first, separates network capabilities at build time, and provides explicit adapters for synchronization and AI requests.
Version 0.3.1 builds on the /gw/ deployment, real four-digit date validation, reusable people and organizations, deterministic task summaries, DOCX/HTML/TXT import, local custom formats, and edition-specific AI paths. It also fixes edition-specific Debian package names and expands the module-by-module user manual.
The public demonstration does not display private controls, import real business snapshots, call the private API, or enable AI. Use it to inspect the interface with sample data: GitHub Pages demonstration.
| Area | What is implemented |
|---|---|
| Work management | Tasks, reusable assigners/handlers/organizations, Chinese statuses, stage tracking, deterministic work summaries, attachments, and searchable local records |
| Writing | Rich-text drafting, DOCX/HTML/TXT import with sanitization, reusable custom formats, deterministic weekly reports, editable versions, and historical archives |
| Documents | A shared A4-oriented engine for DOCX and PDF export; browser print is used on the Web and Electron printing on desktop |
| Migration | Importers for two legacy prototype export shapes, with warnings when their shared version marker cannot identify the source reliably |
| Local data | IndexedDB-backed repositories, snapshots, attachment references, and explicit recovery/export operations |
| Edition services | Internet builds use a session-only API key with an OpenAI-compatible endpoint; intranet builds use authenticated private sync and the internal AI gateway only |
Historical Skills, configuration, weekly reports, and unmapped source fields remain visible as read-only plain text. Imported HTML or script text is not executed.
| Variant | Private controls | Intended use | Important boundary |
|---|---|---|---|
| Public Pages | Disabled | Product demonstration with built-in sample data | No business JSON, real attachments, snapshot restore, private API, or AI |
| Internet Web / desktop | Direct AI only | Non-classified use with an OpenAI-compatible HTTPS endpoint | The API key stays in session memory; browser use also requires provider CORS |
| Intranet Web / desktop | Internal sync and AI gateway | Use on a controlled internal origin | Provider keys stay on the server; the intranet desktop main process blocks direct public-AI IPC |
All variants remain local-first. Private synchronization begins only after a user supplies a server address and access code.
- Node.js
24, matching the GitHub Actions toolchain. - pnpm
11.9.0, declared through the rootpackageManagerfield. - Playwright Chromium for end-to-end tests and brand-asset generation.
- Windows for NSIS installers; Linux for AppImage/DEB packaging and final Linux compatibility checks.
- A Chromium-class browser for the Web builds.
The repository version is 0.3.1. Dependencies are locked by pnpm-lock.yaml; use the frozen lockfile for reproducible installs.
corepack enable
pnpm install --frozen-lockfile
pnpm dev:webThe default development server listens on the local interface. To exercise private controls with the intranet build mode:
pnpm dev:web:intranetTo exercise the Internet edition with an OpenAI-compatible endpoint:
pnpm dev:web:internetDo not point the public Pages build at a private API. Configuration, real attachments, and business snapshots belong only in a desktop or controlled intranet environment.
- Create or import tasks and file records, then review the migration report and read-only historical archive.
- Draft official-document content and maintain the relevant local knowledge entries.
- Generate a weekly report from the selected date range, edit it, save a version, and export it for review.
- Export a local snapshot before clearing browser data, changing devices, or uninstalling the desktop client.
- In a private build, explicitly connect to the server, pull the current master state, and push only locally newer records.
- Before any AI request, inspect and edit the redaction preview and confirm that the material is appropriate to send.
Generated documents are working outputs, not a substitute for editorial, policy, font, pagination, or secrecy review.
- The public and intranet Web builds keep application records in the current browser profile's IndexedDB.
- The desktop build uses the same local model and adds a restricted Electron bridge for native PDF export.
- Clearing site data, removing a browser profile, or uninstalling without a snapshot can make local records unavailable.
- Local redaction recognizes common phone numbers, email addresses, identity numbers, and labeled names, but cannot prove that a document is anonymous.
- Sensitive, classified, or otherwise prohibited material must not enter this application or a public model.
- Model keys, database credentials, and provider configuration stay on the private server, never in client storage.
Read docs/HELP.md before using migration, synchronization, attachments, or AI with real internal material.
The checked-in knowledge pack is generated only from the repository's licensed material and an explicit HTTPS source allowlist. pnpm content:sync is an intentional network operation: it follows the repository's redirect and response-size policy, records source metadata, and does not scrape commercial reference products or overwrite manually maintained templates.
Public Pages uses a restrictive CSP and no private connection targets. The intranet/desktop CSP allows HTTPS and local API endpoints needed for explicit private operation. Because an HTML CSP meta element cannot enforce frame-ancestors, production hosting must set Content-Security-Policy: frame-ancestors 'none' as an HTTP response header when framing protection is required.
pnpm lint
pnpm format:check
pnpm test
pnpm content:verify
pnpm assets:verify
pnpm exec playwright install chromium
pnpm test:e2e
pnpm test:e2e:internet
pnpm test:e2e:intranetpnpm test runs package tests plus content-policy, workflow-contract, and UI-contract checks. The Playwright suites cover desktop and narrow viewports, the public/private feature split, migration, local workflows, document export, attachments, CSP behavior, and the rule that the intranet client performs no external request before explicit connection.
lint and format:check currently delegate to TypeScript or JavaScript syntax/type validation in each workspace; no independent source formatter is configured.
pnpm build
pnpm build:web:internet
pnpm build:web:intranet
pnpm build:desktop
pnpm build:desktop:win:x64:internet
pnpm build:desktop:win:x64:intranet
pnpm build:desktop:linux:x64:internet
pnpm build:desktop:linux:x64:intranetThe public Web build is written to apps/web/dist/; Internet and intranet Web builds are isolated in dist-internet/ and dist-intranet/. Replace x64 with arm64 for ARM builds. Desktop packaging first builds a file://-compatible Web bundle and rejects absolute asset paths that Electron could not load.
Tags matching v* trigger Windows/Linux, x64/arm64, Internet/intranet packaging. A release is created only after all packages and Debian 10/12 startup gates succeed; the matrix produces 12 edition-specific installers plus SHA256SUMS.txt.
apps/web React/Vite UI and build-time public/private capability split
apps/desktop Electron main process, preload bridge, security policy, packaging
packages/domain Shared entities, validation, weekly-report and archive semantics
packages/local-data IndexedDB repositories, snapshots, attachments, local persistence
packages/documents DOCX/PDF-oriented document model and export helpers
packages/migration Legacy export recognition, mapping, warnings, archive preservation
packages/sync-client Explicit private sync, attachment, redaction, and AI client
content Licensed sources, allowlist, generated knowledge pack, attribution
scripts Content policy, asset generation, build and workflow contract checks
e2e Public, Internet, and intranet Playwright scenarios
UI components must use package APIs rather than reaching into persistence internals. Network behavior belongs in packages/sync-client; local storage must not acquire implicit network access. Electron keeps context isolation and sandboxing enabled and exposes only the narrow preload contract.
- The public demonstration targets
https://nextweb4.github.io/gw/; deployment and package checks do not make the private API's shared-code authentication production-ready. - The application is designed for public or internal non-classified work, not classified records.
- Browser storage durability depends on the browser profile and the user's snapshot practice.
- DOCX/PDF output depends on fonts and the final editor/viewer; formal documents still require manual review.
- Legacy prototypes used a shared version identifier and omitted one Skill collection from their standard exporter, so ambiguous imports produce an explicit warning instead of a guessed source label.
- Windows and Linux packages are not Authenticode/code-signed. Real ARM hardware remains an external verification item even though CI builds and emulated installation gates exist.
See docs/VERIFICATION_MATRIX.md for the maintained evidence matrix and RELEASE_NOTES.md for release history.
- Preserve the public/intranet/desktop capability boundary and their separate output directories.
- Add focused tests when changing domain invariants, persistence, migration, redaction, synchronization, Electron IPC, export behavior, or workflows.
- Run content verification before changing licensed or generated knowledge files; authorization metadata and attribution must stay consistent.
- Regenerate and verify PNG/ICO assets after changing
assets/brand/app-icon.svg. - Keep package versions, release notes, desktop artifact names, all three README files, and workflow assertions synchronized.
Dependency choices, licenses, rejected alternatives, and rollback boundaries are documented in OPEN_SOURCE_AUDIT.md. Visual and interaction rules are documented in docs/DESIGN_SYSTEM.md.
Copyright (c) 2026 HaoXiangHwang. All rights reserved.
The repository declares UNLICENSED; no permission to copy, modify, or redistribute the project's own code or content is granted without written authorization. Third-party dependencies remain subject to their respective licenses, and the scope of authorized reference material is recorded under content/licensed/. Read COPYRIGHT.md and content/ATTRIBUTION.md before reuse or distribution.