Skip to content

Feature/#96#100

Merged
vkehfdl1 merged 3 commits intodevfrom
feature/#96
Apr 10, 2026
Merged

Feature/#96#100
vkehfdl1 merged 3 commits intodevfrom
feature/#96

Conversation

@vkehfdl1
Copy link
Copy Markdown
Contributor

@vkehfdl1 vkehfdl1 commented Apr 10, 2026 •
edited
Loading

Summary

  • add an executable zipcode_search.py helper that returns official ePost postcode + English address results
  • update zipcode-search docs/tests to point at the integrated ePost English-address surface
  • keep repository CI green on the current Python 3.14 toolchain with a narrow KIPRIS XML parsing fallback

Verification

  • python3 -m unittest scripts.test_zipcode_search
  • node --test scripts/skill-docs.test.js
  • python3 scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123"
  • ./scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123"
  • npm run build
  • PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search
  • npm run ci

@vkehfdl1
Enable official English address lookup for Korean postcode searches
5c95e9e 
The zipcode-search feature now uses the official ePost integrated search surface
for postcode plus English-address lookups, ships a runnable helper, and
locks the behavior with regression coverage plus aligned docs.

A narrow compatibility fallback was also added to the KIPRIS XML parser so
repository CI stays green on the current Python 3.14 environment where
pyexpat is unavailable.

Constraint: Must use official public ePost output instead of custom romanization rules
Constraint: Repository verification must pass under the current local Python 3.14 toolchain
Rejected: Implement our own Hangul-to-English address formatter | would diverge from the official postal rendering
Rejected: Leave the KIPRIS parser untouched | npm run ci currently fails in this environment without the XML fallback
Confidence: medium
Scope-risk: moderate
Reversibility: clean
Directive: Keep zipcode-search tied to the official ePost integrated surface unless a new approved source is added
Tested: python3 -m unittest scripts.test_zipcode_search
Tested: node --test scripts/skill-docs.test.js
Tested: python3 scripts/zipcode_search.py '서울특별시 강남구 테헤란로 123'
Tested: npm run build
Tested: PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search
Tested: npm run ci
Not-tested: Live no-result and multi-result zipcode queries beyond the verified Teheran-ro example
@vkehfdl1
Copy link
Copy Markdown
Contributor Author

vkehfdl1 commented Apr 10, 2026

Code review complete for PR #100 (origin/dev...feature/#96). I ran the requested $code-review workflow and did live verification on the branch.

Recommendation: APPROVE

Findings

  • CRITICAL: none
  • HIGH: none
  • MEDIUM: none
  • LOW: none
  • I did not find a blocking correctness, security, or maintainability issue in the changed files.

Real Result

  • python3 -m unittest scripts.test_zipcode_search → 4 tests passed
  • node --test scripts/skill-docs.test.js → 86 tests passed
  • python3 scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123" → returned:
    • zip_code: 06133
    • road_address: 서울특별시 강남구 테헤란로 123 (역삼동, 여삼빌딩)
    • english_address: 123, Teheran-ro, Gangnam-gu, Seoul, 06133, Rep. of KOREA
  • npm run build → passed
  • PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search → 16 tests passed
  • npm run ci → passed end-to-end (lint, typecheck, root/workspace tests, pack dry-run)

Concrete evidence

  • The new zipcode helper is wired to the official integrated ePost HTTPS surface and the live CLI run returned the expected postcode + English-address payload for the sample address.
  • The KIPRIS helper fallback did not regress the existing patent helper suite; the targeted patent tests and full npm run ci both stayed green.
  • Docs/tests/source references for zipcode search stayed aligned with the new ePost integrated search flow.

@vkehfdl1
Keep the zipcode helper directly executable
35c91a0 
The feature branch already routed zipcode lookup through the integrated ePost English-address surface, but the helper scripts themselves still lacked a shebang and executable mode. This follow-up locks the packaging/CLI contract with a regression test and marks both entrypoints executable so the documented helper can be invoked directly as a script.

Constraint: Issue #96 requires an executable zipcode_search.py helper in both the repo script wrapper and bundled skill helper

Rejected: Document python3-only invocation and leave file modes unchanged | would not satisfy the executable-helper requirement or catch future regressions

Confidence: high

Scope-risk: narrow

Reversibility: clean

Directive: Keep the wrapper and bundled helper executable together because tests assert the pair as the public entrypoints

Tested: python3 -m unittest scripts.test_zipcode_search; node --test scripts/skill-docs.test.js; python3 scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123"; ./scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123"; npm run build; PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search; npm run ci

Not-tested: Direct execution of the bundled zipcode-search/scripts/zipcode_search.py helper against the live endpoint
@vkehfdl1
Copy link
Copy Markdown
Contributor Author

vkehfdl1 commented Apr 10, 2026

Follow-up landed for the approved issue #96 branch.

  • added a regression test that asserts both scripts/zipcode_search.py and zipcode-search/scripts/zipcode_search.py are executable Python entrypoints
  • added #!/usr/bin/env python3 shebangs to both helper scripts and committed the executable mode bits so the documented helper is truly runnable directly
  • reran the required verification, including direct script execution

Verification rerun:

  • python3 -m unittest scripts.test_zipcode_search
  • node --test scripts/skill-docs.test.js
  • python3 scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123"
  • ./scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123"
  • npm run build
  • PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search
  • npm run ci

@vkehfdl1
Copy link
Copy Markdown
Contributor Author

vkehfdl1 commented Apr 10, 2026

Code review complete for PR #100 (origin/dev...feature/#96). I reran the requested $code-review workflow and live verification on the current branch after the executable/shebang follow-up.

Recommendation: APPROVE

Findings

  • CRITICAL: none
  • HIGH: none
  • MEDIUM: none
  • LOW: none
  • I did not find a blocking correctness, security, or maintainability issue in the 10 changed files.

Real Result

  • python3 -m unittest scripts.test_zipcode_search → 5 tests passed
  • node --test scripts/skill-docs.test.js → 86 tests passed
  • python3 scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123" → returned 06133 with official Korean road/jibun + English address
  • ./scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123" → returned the same JSON payload successfully
  • ls -l scripts/zipcode_search.py zipcode-search/scripts/zipcode_search.py → both helpers are executable (-rwxr-xr-x)
  • npm run build → passed
  • PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search → 16 tests passed
  • npm run ci → passed end-to-end (lint, typecheck, root/workspace tests, pack dry-run)
  • git diff --check origin/dev...HEAD → clean

Concrete evidence

  • The follow-up executable fix is now genuinely locked: scripts.test_zipcode_search asserts both scripts/zipcode_search.py and zipcode-search/scripts/zipcode_search.py are executable Python entrypoints, and both files now carry executable mode bits plus #!/usr/bin/env python3 shebangs.
  • The live helper output returned:
    • zip_code: 06133
    • road_address: 서울특별시 강남구 테헤란로 123 (역삼동, 여삼빌딩)
    • english_address: 123, Teheran-ro, Gangnam-gu, Seoul, 06133, Rep. of KOREA
  • The KIPRIS XML parsing fallback did not regress the adjacent Python helper path; the targeted patent suite and full npm run ci both stayed green.

@vkehfdl1
Document direct zipcode helper execution so the executable follow-up …
a6ad86d 
…stays discoverable

The approved Issue #96 branch already shipped the ePost English-address helper
and executable shebang/mode fix. This follow-up only locks the last user-facing
surface: docs and docs regression now mention the direct `./scripts/zipcode_search.py`
entrypoint alongside the `python3` form, so the published guidance matches the
actual executable helper behavior.

Constraint: Keep the branch diff narrow and aligned with the already-approved Issue #96 scope
Rejected: Add more helper code changes | executable behavior was already correct and verified
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep docs/tests aligned whenever helper entrypoint contracts change
Tested: node --test scripts/skill-docs.test.js; python3 -m unittest scripts.test_zipcode_search; python3 scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123"; ./scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123"; npm run build; PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search; npm run ci
Not-tested: No additional live address samples beyond the documented Gangnam example
@vkehfdl1
Copy link
Copy Markdown
Contributor Author

vkehfdl1 commented Apr 10, 2026

Follow-up landed on feature/#96.

  • added a docs regression so zipcode-search guidance now locks direct ./scripts/zipcode_search.py execution in addition to the existing python3 helper path
  • updated docs/features/zipcode-search.md and zipcode-search/SKILL.md to advertise the executable helper invocation alongside the official ePost English-address workflow
  • reran the required verification plus direct executable checks after the docs/test follow-up

Verification rerun:

  • python3 -m unittest scripts.test_zipcode_search
  • node --test scripts/skill-docs.test.js
  • python3 scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123"
  • ./scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123"
  • npm run build
  • PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search
  • npm run ci

@vkehfdl1
Copy link
Copy Markdown
Contributor Author

vkehfdl1 commented Apr 10, 2026

Code review complete for PR #100 (origin/dev...feature/#96). I reran the requested $code-review workflow and live verification on the current branch after the docs regression follow-up.

Recommendation: APPROVE

Findings

  • CRITICAL: none
  • HIGH: none
  • MEDIUM: none
  • LOW: none
  • I did not find a blocking correctness, security, or maintainability issue in the 10 changed files.

Real Result

  • python3 -m unittest scripts.test_zipcode_search → 5 tests passed
  • node --test scripts/skill-docs.test.js → 86 tests passed
  • python3 scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123" → returned 06133 with official Korean road/jibun + English address
  • ./scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123" → returned the same JSON payload successfully
  • ls -l scripts/zipcode_search.py zipcode-search/scripts/zipcode_search.py → both helpers are executable (-rwxr-xr-x)
  • npm run build → passed
  • PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search → 16 tests passed
  • npm run ci → passed end-to-end (lint, typecheck, root/workspace tests, pack dry-run)
  • git diff --check origin/dev...HEAD → clean

Concrete evidence

  • The shipped zipcode helper is now documented and locked on both invocation paths: the docs regression asserts python3 scripts/zipcode_search.py ... and ./scripts/zipcode_search.py ..., and both commands succeeded in live execution.
  • The live helper output returned:
    • zip_code: 06133
    • road_address: 서울특별시 강남구 테헤란로 123 (역삼동, 여삼빌딩)
    • english_address: 123, Teheran-ro, Gangnam-gu, Seoul, 06133, Rep. of KOREA
    • jibun_address: 서울특별시 강남구 역삼동 648-23 (여삼빌딩)
  • README, docs/features/zipcode-search.md, zipcode-search/SKILL.md, and docs/sources.md now point at the same official integrated ePost English-address surface, and the updated skill-doc regression suite stayed green.
  • The narrow KIPRIS parsing fallback did not regress the adjacent Python helper path; the targeted patent suite and full npm run ci both stayed green.

@vkehfdl1
Copy link
Copy Markdown
Contributor Author

vkehfdl1 commented Apr 10, 2026

Verified the approved issue #96 follow-up on feature/#96 and confirmed no additional code delta was needed beyond the already-landed branch changes.

  • official ePost integrated postcode + English-address helper is present and works through both python3 scripts/zipcode_search.py ... and ./scripts/zipcode_search.py ...
  • zipcode-search docs/tests stay aligned on the integrated ePost English-address flow and direct executable helper usage
  • the narrow KIPRIS XML parsing fallback remains in place and the adjacent patent helper path stays green on the current Python 3.14 toolchain

Verification rerun:

  • python3 -m unittest scripts.test_zipcode_search ✅
  • node --test scripts/skill-docs.test.js ✅
  • python3 scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123" ✅ → 06133 / 123, Teheran-ro, Gangnam-gu, Seoul, 06133, Rep. of KOREA
  • ./scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123" ✅
  • npm run build ✅
  • PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search ✅
  • npm run ci ✅

@vkehfdl1
Copy link
Copy Markdown
Contributor Author

vkehfdl1 commented Apr 10, 2026

Verdict: APPROVE

Short reason
No blocking correctness, security, or maintainability issues found. The PR now ships a working executable zipcode helper against the official integrated ePost English-address surface, keeps docs/tests aligned, and preserves the adjacent KIPRIS helper path on the current Python 3.14 toolchain.

Real Result

  • python3 -m unittest scripts.test_zipcode_search → 5 tests passed
  • node --test scripts/skill-docs.test.js → 86 tests passed
  • python3 scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123" → returned 06133 plus the official road/jibun/English address payload
  • ./scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123" → returned the same JSON payload successfully
  • PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search → 16 tests passed
  • npm run build → passed
  • npm run ci → passed end-to-end
  • git diff --check origin/dev...HEAD → clean

Concrete evidence

  • Live helper output included:
    • zip_code: 06133
    • road_address: 서울특별시 강남구 테헤란로 123 (역삼동, 여삼빌딩)
    • english_address: 123, Teheran-ro, Gangnam-gu, Seoul, 06133, Rep. of KOREA
    • jibun_address: 서울특별시 강남구 역삼동 648-23 (여삼빌딩)
  • ls -l scripts/zipcode_search.py zipcode-search/scripts/zipcode_search.py shows both helpers are executable (-rwxr-xr-x), matching the added shebang/executable regression coverage.
  • The updated doc regression passed, and the changed README / feature doc / skill doc / sources now all point at https://www.epost.kr/search.RetrieveIntegrationNewZipCdList.comm.
  • The narrow XML parsing fallback in korean-patent-search/scripts/patent_search.py did not regress the patent helper path; the targeted patent suite and full CI both stayed green.

@vkehfdl1 vkehfdl1 merged commit 4bceaef into dev Apr 10, 2026
1 check passed
@vkehfdl1 vkehfdl1 deleted the feature/#96 branch April 10, 2026 02:13
@vkehfdl1
Copy link
Copy Markdown
Contributor Author

vkehfdl1 commented Apr 10, 2026

APPROVE

Short reason: No blocking correctness, security, or maintainability issues found. The PR now ships the official ePost postcode + English-address helper on both documented invocation paths, and the adjacent KIPRIS Python 3.14 fallback stayed green in targeted and full CI verification.

Real Result

  • python3 -m unittest scripts.test_zipcode_search ✅ (5 tests passed)
  • node --test scripts/skill-docs.test.js ✅ (86 tests passed)
  • python3 scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123" ✅
  • ./scripts/zipcode_search.py "서울특별시 강남구 테헤란로 123" ✅
  • ls -l scripts/zipcode_search.py zipcode-search/scripts/zipcode_search.py ✅ both helpers are executable (-rwxr-xr-x)
  • npm run build ✅
  • PYTHONPATH=.:scripts python3 -m unittest scripts.test_patent_search ✅ (16 tests passed)
  • npm run ci ✅ end-to-end
  • git diff --check origin/dev...HEAD ✅ clean

Concrete evidence

  • Live helper output returned zip_code 06133 and the official English address 123, Teheran-ro, Gangnam-gu, Seoul, 06133, Rep. of KOREA for 서울특별시 강남구 테헤란로 123.
  • Both scripts/zipcode_search.py and zipcode-search/scripts/zipcode_search.py have Python shebangs and executable mode, and both python3 ... and direct ./scripts/zipcode_search.py ... execution succeeded.
  • The docs/tests/source are aligned on the official integrated ePost endpoint (https://www.epost.kr/search.RetrieveIntegrationNewZipCdList.comm) and direct executable helper usage.
  • The narrow KIPRIS XML parsing fallback did not regress the adjacent patent helper path: the targeted patent suite passed, and full npm run ci stayed green.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@vkehfdl1