Gpt_Codex_HWP

Work with Korean HWP/HWPX documents in Codex—from legacy HWP analysis to validated, previewable HWPX results.

Comment 1

Inspiration

My background is in social science and education, not computer science. While working in Korean public administration, I produced and handled a large volume of HWP documents. HWP has played an important role in Korean-language document creation and software sovereignty, but it can also become a practical barrier when public institutions need to exchange information with people, companies, or organizations outside the Hancom Office ecosystem.

I felt that barrier directly. Codex could help me reason about language and content, but it could not reliably inspect the HWP files I actually received or produce a document that I could return through the same workflow. Legacy binary HWP files are also difficult for many AI tools to read directly. Gpt_Codex_HWP began as an attempt to solve a problem I had experienced firsthand.

What it does

Gpt_Codex_HWP is a local Codex plugin for Korean HWP/HWPX document workflows. It can read and analyze legacy HWP files, and it can create, edit, fill, validate, and preview HWPX documents.

The workflow is designed for cautious real-world use. A user can bring a public-agency form and source notes into Codex, map the notes to labels, tables, and sections, detect required information that is still missing, and create a new completed copy without silently overwriting the original. The plugin validates the result and generates an SVG-based preview, so the user can review the document even without a separate copy of Hancom Office Hangul.

This is especially useful for people, organizations, and international collaborators who must exchange documents with Korean public institutions but do not otherwise live inside the HWP ecosystem.

How I built it

The project started before GPT-5.6 with a narrower goal: make the HWP documents in my own workflow accessible from Codex. The early versions established the local plugin, legacy HWP reading, HWPX creation and editing, validation, preview generation, and safety rules such as preserving source files and refusing to bypass protected documents.

As the project grew, the hard work moved beyond parsing a file format. I had to connect document engines, native dependencies, XML and ZIP structures, font handling, preview rendering, and a Model Context Protocol server while keeping each operation bounded and reviewable.

What changed during Build Week

For the v0.2.1 release, I used Codex with GPT-5.6 to make the project substantially more public, inspectable, and portable. The work included publishing the TypeScript source and tests, isolating document engines from the MCP server lifecycle, adding cancellation and progress, bounding inputs and outputs, restricting allowed document roots, protecting diagnostic data, and building reproducible ZIP, SBOM, and provenance checks.

The release passed the required Windows x64, macOS arm64, Linux, and security CI gates and was published as an immutable v0.2.1 tag with a verified ZIP, SPDX SBOM, provenance, and SHA256 checksums. Windows x64 remains the primary real-document validation platform; physical-device use with Codex Desktop and Hancom Office Hangul on macOS remains unverified. The public commit history, merged PR #3, tests, release artifacts, and Codex session ID distinguish the Build Week work from the earlier v0.1.4 baseline.

How I used Codex and GPT-5.6

Codex was not only a code generator. I used it as a long-running engineering workspace for inspecting failures, changing the implementation, running tests, reviewing results, and connecting release evidence back to the architecture. GPT-5.6 was especially helpful when a failure crossed several layers at once—for example, a document-engine process, an MCP lifecycle rule, a platform-specific path, and a CI assertion.

Its long-horizon problem solving helped keep the safety contract visible through repeated diagnosis and verification. That made it possible to refactor a working personal tool without losing the behaviors that mattered: source preservation, bounded operations, privacy-safe diagnostics, and results that a user can inspect before submission.

Challenges I ran into

The hardest part of the v0.2.1 release was not adding another document feature. It was preserving the same safety guarantees across Windows, macOS, and Linux, where process lifecycles, paths, native dependencies, and resource diagnostics behave differently.

HWP/HWPX itself added another layer of difficulty. A useful result must preserve document structure, tables, fonts, and validation rules—not merely extract plain text. I also had to separate what CI could verify from what still requires physical-device testing, especially on macOS.

Accomplishments that I am proud of

I am proud that the project connects a very local document problem to a broader group of users. Someone who needs to work with a Korean public institution can ask Codex to inspect a legacy HWP, reason over the contents, produce a new HWPX result, validate it, and review an SVG-based preview without silently altering the source.

I am also proud that the Build Week revision made the engineering easier to inspect. The public source, tests, cross-platform CI receipts, immutable release assets, SPDX SBOM, provenance, and checksums let other people examine how the plugin reaches its result rather than simply trusting a black box.

What I learned

As a builder without a computer-science background, I learned Git-based release management, pull-request review, CI, refactoring, testing, SBOM generation, and provenance verification by solving real failures rather than only reading about them.

More importantly, I learned that reliability is part of the user experience. For public documents, a clear missing-information warning, an unchanged source file, a bounded process, or an honest platform limitation can matter as much as a successful edit.

What's next

Next I want to complete more physical-device validation, improve preview fidelity for complex documents, and make installation easier for people who are not developers. I also want to expand the synthetic examples and documentation so international users can test a Korean public-document workflow without needing private or sensitive source files.

Built With

Share this project:

Updates