The existing health-food-ingredient route only covers individually-approved
ingredients (I-0040/I-0050), missing gazetted ingredients like psyllium husk
(차전자피). I0030 (건강기능식품 품목제조 신고사항) has 44k+ registered
products with raw materials, functionality, intake precautions, and standards.
The new /v1/mfds/food-safety/product-report route queries I0030 with
server-side PRDLST_NM and RAWMTRL_NM filters in parallel, deduplicates
by report number, and returns normalized results. Live-verified with
FOODSAFETYKOREA_API_KEY returning 차전자피 products with full precautions.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The existing food-safety skill only queried recall/sales-suspension records
(I0490), which was too edge-case for "can I eat this?" questions. This adds
two new foodsafetykorea.go.kr surfaces through k-skill-proxy:
- /v1/mfds/food-safety/health-food-ingredient (I-0040 + I-0050):
official health food ingredient recognition, daily intake, precautions
- /v1/mfds/food-safety/inspection-fail (I2620):
domestic inspection failure records with test results and standards
All three routes share the same FOODSAFETYKOREA_API_KEY with sample-feed
fallback. Python helper gains health-food-ingredient and inspection-fail
subcommands. SKILL.md updated with new surfaces, workflow, and CLI examples.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Move direct API calls out of the skill Python scripts and into shared
proxy routes so end-users no longer need their own DATA_GO_KR_API_KEY
for MFDS surfaces. Adds mfds.js helper, proxy tests, and updates all
docs and setup guidance to reflect the hosted proxy workflow.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The PR changes the published blue-ribbon-nearby package behavior, so it needs a changeset for the automated version-packages PR and publish pipeline. This keeps the release metadata aligned with the repository's Changesets workflow without touching package versions by hand.
Constraint: Node package releases in this repo must use Changesets rather than manual version bumps
Rejected: Skip the changeset and rely on the feature PR alone | the automated release PR would have no release intent to consume
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep feature PRs release-ready by adding a changeset whenever published package behavior changes
Tested: npm --workspace packages/blue-ribbon-nearby test; npm run ci (fails in this environment because tsc is unavailable)
Not-tested: Full repo typecheck/test pipeline with TypeScript installed
Merged origin/dev into feature/k-schoollunch-menu and resolved the stale
conflict surfaces by matching the current dev tree. The branch keeps its
review history, but its content now aligns with the already-verified dev
integration so the cross-repo PR stops reporting merge conflicts.
Constraint: The school-lunch and household-waste changes already live on dev and should remain the source of truth
Rejected: Force-reset the contributor branch to origin/dev | destructive for a cross-repo PR and unnecessary
Rejected: Keep branch-only drift on docs/tests/proxy files | preserves conflict noise without new shipped behavior
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: For long-lived cross-repo follow-up PRs, prefer sync merges that converge to the verified base branch
Tested: Tree equality against origin/dev after merge resolution
Tested: npm run ci before final tree convergence on this branch; origin/dev npm run ci at commit 7b82d4d
Not-tested: Separate full CI rerun after replacing the remaining branch-only files with origin/dev equivalents
Merged origin/dev into feature/#0 and resolved the stale conflict surfaces by
matching the current dev tree. This preserves the branch history while making
the branch content equivalent to the already-verified integration branch so the
open PR no longer carries outdated merge blockers.
Constraint: The approved household-waste and school-lunch work is already integrated on dev
Rejected: Force-reset feature/#0 to origin/dev | would drop branch history and require a force push
Rejected: Preserve stale branch-only doc/test drift | kept the PR conflicting without new product value
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: If this PR stays open for coordination only, prefer merge-sync commits over force-push rewrites
Tested: Tree equality against origin/dev after merge resolution
Tested: origin/dev npm run ci at commit 7b82d4d
Not-tested: Separate full CI rerun on feature/#0 after the tree-equivalent merge commit
Merged origin/main into feat/blue-ribbon-browser-fallback so the feature branch
carries the latest main-branch packaging and documentation context while
preserving the blue-ribbon browser fallback implementation. No manual conflict
resolution was required.
Constraint: PR #94 still needs its browser-fallback feature diff intact while main keeps moving
Rejected: Rebase the feature branch onto main | unnecessary risk for an already-reviewable cross-repo branch
Rejected: Leave the branch behind main | makes future review and merge harder as main continues to move
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep package-lock and optional dependency behavior validated whenever this branch is re-synced with main
Tested: npm test --workspace blue-ribbon-nearby
Tested: npm run lint --workspace blue-ribbon-nearby
Not-tested: Full workspace npm run ci on the feature branch after the merge-sync commit
Merged origin/main into dev so the branch regains direct ancestry with the
mainline release history while preserving newer dev-side docs, proxy, and
helper updates. Conflict resolution kept the richer dev documentation and
proxy behavior, took the mainline Naver blog skill files as the canonical
source, and preserved the released package-version/changelog updates from
main where they were the authoritative record of published state.
Constraint: dev already contained newer docs/proxy work that would have regressed if main-side older variants won
Constraint: main carried release metadata that should remain authoritative for published package versions
Rejected: Cherry-pick main-only commits again | fixes content but does not restore formal dev<-main merge ancestry
Rejected: Prefer main on all conflicts | would drop newer dev-only skill and proxy guidance
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: On future dev<-main syncs, preserve newer dev docs/proxy behavior first, then re-run full workspace CI before concluding
Tested: npm run ci; inspected README/proxy/setup/package metadata after conflict resolution
Not-tested: push to origin/dev; GitHub mergeability after remote update
The GeekNews follow-up review found two merge blockers outside the new helper itself: rejected NEIS upstream fetches escaped as Fastify 500s, and the documented selective install block split into two shell commands. This change adds regression coverage first, catches rejected NEIS fetches at the route boundary with the established proxy_error/502 contract, and locks the multiline install snippet so copy-paste works.
Constraint: Keep NEIS proxy failures aligned with existing public proxy error handling
Constraint: Preserve the published GeekNews verification commands and current PR scope
Rejected: Wrapping fetch inside the NEIS helper functions | route-level handling matches the surrounding Fastify endpoint pattern
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep public proxy routes fail-closed on rejected upstream fetches and keep multiline install snippets copy-pasteable
Tested: PYTHONPATH=.:scripts python3 -m unittest scripts.test_geeknews_search; node --test scripts/skill-docs.test.js; node --test packages/k-skill-proxy/test/server.test.js; python3 scripts/geeknews_search.py list --limit 3; python3 scripts/geeknews_search.py search --query Claude --limit 3; python3 scripts/geeknews_search.py detail --id 28439; node NEIS rejected-fetch repro; npm run ci
Not-tested: Live NEIS upstream success responses against the real public API in this follow-up
Issue #108 needs a dedicated read-only skill that can browse,
search, and inspect GeekNews posts using the public feed alone.
The implementation adds a fixture-backed Atom helper, skill/docs
surfaces, and install/README wiring, then verifies the helper
against the live GeekNews feed.
Constraint: Must stay RSS-first and avoid new dependencies or unofficial APIs
Constraint: Skill development requires syncing the skill into ~/.claude/skills and ~/.agents/skills during verification
Rejected: Fetch article pages directly for v1 | expands scope beyond the approved RSS-driven workflow
Rejected: Use XML parser modules | current python3 environment has expat issues, so regex + HTML parsing is safer here
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep the root helper and geeknews-search/scripts copy behaviorally identical because the installed skill must remain self-contained
Tested: PYTHONPATH=.:scripts python3 -m unittest scripts.test_geeknews_search; node --test scripts/skill-docs.test.js; python3 scripts/geeknews_search.py list --limit 3; python3 scripts/geeknews_search.py search --query Claude --limit 3; python3 scripts/geeknews_search.py detail --id 28439; npm run ci
Not-tested: Non-default feed mirrors or future Atom schema changes beyond the current public GeekNews feed shape
Related: Issue #108
* feat: 네이버 블로그 리서치 스킬 추가
API 키 없이 python3 표준 라이브러리만으로 네이버 블로그 검색, 원문 읽기, 이미지 다운로드를 수행하는 스킬.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Restore Naver blog search paging and newest-sort behavior
Naver's current blog search surface does not honor the older
where=blog + sort query pattern used by this skill. The request
now targets the blog tab surface, uses the observed NSO sort
controls, and trims each parsed page to the visible 15-result
window so count-based pagination returns distinct results.
Constraint: Must keep using stdlib-only HTTP scraping without adding dependencies
Constraint: Current Naver blog tab behavior requires ssc/tab parameters plus nso sort controls
Rejected: Keep where=blog and tune start values only | still returned repeated first-page results
Rejected: Leave sort=date as-is | current endpoint ignored it and returned relevance ordering
Confidence: medium
Scope-risk: narrow
Reversibility: clean
Directive: Re-verify request params against live Naver markup before changing paging or sort semantics again
Tested: python3 -m py_compile on naver-blog-research scripts and new regression test; PYTHONPATH=.:scripts python3 -m unittest scripts.test_naver_blog_search; npm run lint; live naver_search.py --count 20/30 --sort sim; live naver_search.py --count 10/20 --sort date
Not-tested: Full npm run test remains blocked by unrelated local pyexpat/libexpat environment failures in patent-search tests
* Surface the new Naver blog skill in the main README
PR 107 adds the skill and feature guide, but the repository landing page
still omitted it from the user-facing capability list. This commit keeps the
README aligned with the actual shipped skill set so users can discover the
new entry point from the main docs.
Constraint: README capability tables and feature lists should stay aligned with docs/features entries
Rejected: Leave README unchanged until merge | hides the new skill from the main index during PR review
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: When adding a new skill guide, update both the summary table and the included-features list together
Tested: README diff review; verified docs/features/naver-blog-research.md link target exists
Not-tested: Full npm run ci (docs-only change)
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Jeffrey (Dongkyu) Kim <vkehfdl1@gmail.com>
Review follow-up found that mixed alias pagination params could still bypass the narrowed public route contract even after duplicate scalar handling was added. This tightens the query normalizer so pageNo/page_no and numOfRows/num_of_rows must appear exactly once and match the fixed allowed values, expands regression coverage for those alias combinations, and aligns the public docs/examples with the exact pageNo=1 + numOfRows=100 contract. The household-waste test setup was also de-duplicated within the scoped suite to keep the follow-up readable without widening behavior.
Constraint: The public household-waste proxy route must stay narrow and reject ambiguous scalar query shapes before any upstream fetch
Rejected: Keep alias resolution as first-non-null | mixed pageNo/page_no and numOfRows/num_of_rows would still bypass the documented 400 path
Rejected: Broaden the route to support alternate page sizes | outside the approved issue scope and contrary to the fixed-value contract
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep household-waste docs and regression tests aligned whenever the allowed query surface changes, including alias handling
Tested: node --test packages/k-skill-proxy/test/server.test.js
Tested: node --test scripts/skill-docs.test.js
Tested: npm run lint
Tested: npm run typecheck
Tested: npm run test
Tested: local proxy smoke on port 4121 for mixed pageNo/page_no 400, mixed numOfRows/num_of_rows 400, and returnType override reaching upstream with fixed pagination
Not-tested: Live successful household-waste upstream response with a real DATA_GO_KR_API_KEY
Fastify parses repeated query parameters as arrays, so the household-waste
normalizer now rejects repeated scalar fields before any upstream request.
This adds a regression test for duplicated cond[SGG_NM::LIKE] values and keeps
invalid requests on the documented 400 bad_request path.
Constraint: Household-waste validation must fail before any upstream fetch
Rejected: Join repeated query values into one filter | ambiguous request semantics
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep repeated scalar query params on the 400 path unless the public contract is expanded intentionally
Tested: node --test packages/k-skill-proxy/test/server.test.js; npm test; npm run lint; npm run typecheck; local proxy smoke on duplicated cond[SGG_NM::LIKE]
Not-tested: Live household-waste upstream success path with a real DATA_GO_KR_API_KEY
The setup skill had drifted behind docs/setup.md after the household-waste
and school-lunch proxy follow-ups. This updates the skill guidance and locks it
with a regression so future doc edits keep the hosted-proxy and server-only-key
story consistent across the user-facing setup surfaces.
Constraint: Follow-up scope is limited to the approved docs/setup consistency gap from PR #103 review
Rejected: Broad setup-doc sweep | unnecessary beyond the approved drift fix
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep k-skill-setup/SKILL.md aligned with docs/setup.md whenever hosted proxy coverage changes
Tested: npm run lint; npm run typecheck; node --test packages/k-skill-proxy/test/server.test.js; bash scripts/validate-skills.sh; node --test scripts/skill-docs.test.js; local buildServer smoke for /health and household-waste pagination
Not-tested: Live upstream NEIS/Data.go.kr network calls with real server credentials
Related: PR #103
The feature/#0 follow-up already had the proxy/runtime fixes in place,
but the branch still needed the final regression locks and doc wording
that keep the review fixes durable. This commit adds lower-bound
household-waste pagination tests and aligns install/security docs with
the proxy-only KEDU_INFO_KEY policy so the school lunch feature stays
on the hosted-proxy / no-user-key path.
Constraint: Follow-up had to stay on feature/#0 so PR #103 updates in place
Constraint: User-facing secrets guidance must not imply KEDU_INFO_KEY belongs in the default client env file
Rejected: Broaden the pass into more proxy/doc rewrites | unnecessary beyond the approved Issue #0 follow-up
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep school lunch docs and regression text aligned with the hosted proxy policy whenever setup/security wording changes
Tested: npm run lint; npm run typecheck; node --test packages/k-skill-proxy/test/server.test.js; bash scripts/validate-skills.sh; node --test scripts/skill-docs.test.js; local proxy smoke for /health, invalid household-waste 400, valid household-waste 200, NEIS without KEDU_INFO_KEY 503
Not-tested: Live NEIS curl against a valid KEDU_INFO_KEY-enabled proxy
Related: PR #102
Related: PR #103
The approved PR #103 follow-up extends the setup-doc regression
coverage so it checks the hosted KSKILL_PROXY_BASE_URL guidance and
both household-waste + school-lunch setup entries, then updates the
guide text to match the shipped hosted-proxy behavior.
Constraint: Must stay within the approved PR #103 follow-up scope
Rejected: Broader setup-doc wording sweep across unrelated features | unnecessary for this approved follow-up
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep docs/setup.md and scripts/skill-docs.test.js aligned whenever hosted proxy coverage changes
Tested: node --test scripts/skill-docs.test.js
Tested: npm run lint
Tested: npm run typecheck
Tested: node --test packages/k-skill-proxy/test/server.test.js
Tested: bash scripts/validate-skills.sh
Tested: local buildServer(...).inject(...) smoke for /health and household-waste pagination
Not-tested: Live NEIS curl smoke with a real KEDU_INFO_KEY
The setup guide already described proxy-hosted household-waste and NEIS flows elsewhere, but the opening summary still omitted school lunch from the no-user-key hosted-proxy list. This adds a regression test first, then aligns the intro sentence and test label so the doc stays consistent with the shipped proxy-backed feature set.
Constraint: Keep the follow-up scoped to existing Issue #0/PR #103 documentation surfaces
Rejected: Broader setup guide rewrite | unnecessary for the approved follow-up
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep hosted-proxy/no-user-key summaries aligned with the per-feature setup matrix when adding new proxy-backed skills
Tested: Targeted red/green skill-docs regression; npm run lint; npm run typecheck; node --test packages/k-skill-proxy/test/server.test.js; bash scripts/validate-skills.sh; node --test scripts/skill-docs.test.js; buildServer runtime smoke for /health, household-waste validation, and NEIS missing-key behavior
Not-tested: Live NEIS upstream call with a real KEDU_INFO_KEY
Related: PR #102
Related: PR #103
Issue #0's core proxy and NEIS changes were already present on feature/#0, but the
setup guide still omitted the hosted/self-host household-waste entry that users
need when checking which features require local secrets. Add a regression test
first, then document the household-waste row and guide link so the setup matrix
stays aligned with the shipped proxy routes.
Constraint: Keep the follow-up diff narrow and avoid touching already-approved proxy behavior
Rejected: Leave the setup matrix as-is | it would keep user-facing docs inconsistent with the shipped route list
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: When proxy-backed skills move between hosted and self-host flows, update docs/setup.md alongside the feature docs
Tested: node --test scripts/skill-docs.test.js
Tested: npm run lint
Tested: npm run typecheck
Tested: node --test packages/k-skill-proxy/test/server.test.js
Tested: bash scripts/validate-skills.sh
Not-tested: Live hosted proxy deployment docs rendering on GitHub
The existing school lunch feature branch was mergeable in shape, but review
found that the public household-waste route still forwarded unchecked
pagination inputs, user-facing secrets docs suggested storing a server-only
KEDU key locally, and the proxy/operator docs omitted the new
household-waste env requirements. This follow-up validates the public query
surface before fetch, aligns docs with the proxy-only secret policy, and
keeps the requested validation workflow green by ignoring hidden metadata
folders in the skill-layout checker.
Constraint: Public proxy routes must stay narrow and keep upstream keys server-only
Rejected: Forward arbitrary pageNo values | violates the documented public-route contract
Rejected: Leave validate-skills unchanged | hidden metadata directories break the requested verification flow
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep household-waste parameter support and docs/tests in lockstep when widening this route
Tested: npm run lint
Tested: npm run typecheck
Tested: node --test packages/k-skill-proxy/test/server.test.js
Tested: node --test scripts/skill-docs.test.js
Tested: bash scripts/validate-skills.sh
Tested: local proxy smoke (/health, household-waste invalid 400, household-waste valid 200)
Not-tested: Live NEIS curl smoke test (KEDU_INFO_KEY unavailable locally)
The helper's emitted POST example still timed out against LOST112 in live
verification because the 20-second timeout budget was too short for the
observed form-submit path. Raise the generated timeout to 60 seconds,
lock that contract in the regression, and align the skill/doc wording so
users receive guidance that matches the runnable command.
Constraint: LOST112 live POST latency can exceed 20 seconds even when reachability probes succeed
Rejected: Keep 20 seconds and rely on manual retry | still ships a broken default curl_example
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: If the timeout budget changes again, rerun the exact emitted curl_example against LOST112 rather than only the lightweight reachability probe
Tested: python3 -m unittest scripts.test_subway_lost_property
Tested: python3 scripts/subway_lost_property.py --station 강남역 --item 지갑 --days 14 --verify-live
Tested: npm run ci
Not-tested: Long-term LOST112 latency drift beyond the currently observed 60-second budget
The review found that the generated subway lost-property curl example still timed out even when the helper's reachability probe passed. This change updates the helper to emit the command shape that actually succeeds against LOST112, tightens the regression test to lock that contract, and aligns the published skill/docs text with the runnable output users now receive.
Constraint: LOST112 POST flow requires a referer and does not behave reliably with the prior redirect-following command shape
Constraint: Keep the v1 scope hybrid/guidance-only without adding new dependencies or scraping guarantees
Rejected: Only add a referer header while leaving the rest of the curl shape unchanged | still reproduced timeouts with the generated command during verification
Rejected: Add a live network regression test for the emitted curl command | would make CI flaky and violate deterministic regression expectations
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: If the LOST112 request shape changes again, re-verify the emitted curl command end-to-end before updating docs or tests
Tested: python3 -m unittest scripts.test_subway_lost_property; python3 scripts/subway_lost_property.py --station 강남역 --item 지갑 --days 14 --verify-live; generated curl_example executed via shell and wrote lost112-search-result.html; npm run ci
Not-tested: Alternate LOST112 item/station combinations beyond the verified 강남역/지갑 example
Issue #98 was approved as a conservative implementation: structure the official LOST112 and 서울교통공사 workflows instead of pretending a stable public API exists. The new helper builds the documented search payload, the docs explain the v1 hybrid scope, and regression coverage locks the helper plus repo docs into the shipped flow.
Constraint: Public subway lost-property APIs remain unconfirmed, so v1 must stay guidance-first
Rejected: Full automated scraping of live result tables | unstable without confirmed API/session guarantees
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep this skill on official HTTPS entry points until a stable public API is verified end-to-end
Tested: python3 -m unittest scripts.test_subway_lost_property; python3 scripts/subway_lost_property.py --station 강남역 --item 지갑 --days 14 --verify-live; npm run ci
Not-tested: Browser-only user journey through LOST112 search submission beyond payload generation
The browser fallback landed without regenerating package-lock, so npm ci failed immediately. Once the lockfile was synced, the blue-ribbon-nearby direct-API tests also showed that structured 403 domain errors were being retried through Playwright whenever the optional dependency was present.
This commit refreshes the workspace lockfile and restricts browser fallback to unclassified 403 automation blocks so PREMIUM_REQUIRED and other structured upstream errors still surface deterministically.
Constraint: CI runs npm ci from the root lockfile and installs optional dependencies when they are captured there
Rejected: Update tests to stub browser fallback | would hide the incorrect production retry path
Confidence: high
Scope-risk: narrow
Directive: Preserve structured upstream 403 errors from bluer.co.kr; only browser-fallback opaque automation blocks
Tested: npm ci
Tested: npm test --workspace blue-ribbon-nearby (python3.12 first on PATH)
Tested: npm run ci (python3.12 first on PATH)
Not-tested: GitHub Actions rerun on ubuntu after push
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
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
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
Discounted goods pages are currently exposing original-price and image data
through retail/showable fields that the detail normalizer was not reading,
so the follow-up fix prefers those live fields and locks the behavior with
a discounted-detail regression fixture.
Constraint: Kurly detail payloads do not mirror the search API price field semantics
Rejected: Trust top-level basePrice alone | discounted live pages currently use retailPrice/showablePrices for the original price
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep detail normalization aligned with live goods-page payloads; verify real discounted products before changing price precedence again
Tested: node --test packages/market-kurly-search/test/index.test.js; npm run ci; live Node smoke for countProducts('우유'), searchProducts('우유'), getProductDetail(5063110), getProductDetail(5048935) on 2026-04-09
Not-tested: Additional undiscovered Market Kurly detail payload variants beyond the covered discounted fixture and live sample
Implement a reusable Market Kurly workspace package plus a repo skill/doc set
that uses the unauthenticated Kurly search and goods-page surfaces.
The change keeps the scope read-only, adds regression coverage, updates
release/docs metadata, and records the new publishable package through
Changesets.
Constraint: Must rely on unauthenticated public web surfaces instead of login/session flows
Constraint: Release workflow requires Changesets for publishable Node packages
Rejected: Docs-only skill | issue approval called for real lookup helpers and live verification
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Kurly endpoints are web-internal surfaces; verify schema behavior before extending fields or adding action flows
Tested: npm run ci; live node smoke for countProducts/searchProducts/getProductDetail on 2026-04-09
Not-tested: Pagination beyond page 1; long-term stability of Kurly internal response schema
bluer.co.kr이 자동화 접근을 차단(403)할 때,
rebrowser-playwright가 설치되어 있으면 실제 Chrome 브라우저를 통해
자동으로 fallback하여 zone 카탈로그와 nearby 검색을 수행한다.
- browser-fallback.js: stealth 패치 적용 브라우저 모듈 (8개 패치)
- index.js: fetchZoneCatalog/fetchNearbyMap에서 403 시 자동 fallback
- package.json: rebrowser-playwright를 optionalDependencies로 추가
- SKILL.md: 브라우저 fallback 사용법 안내
rebrowser-playwright 미설치 시 기존 동작과 완전히 동일하다.
The dev backport matches the approved hotfix by deleting the
used-car-price-search assertion that scanned .changeset entries.
That assertion fails after changeset versioning consumes release
notes, while the remaining docs and pack coverage still protect the
published workspace invariants that matter here.
Constraint: Repository policy forbids tests that assert .changeset/*.md files exist after release automation consumes them
Rejected: Add replacement coverage that still reads .changeset | keeps the same brittle release-flow dependency
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep release-flow regression coverage focused on durable docs/package invariants, not transient .changeset files
Tested: node --test scripts/skill-docs.test.js
Tested: npm run ci
Tested: LSP diagnostics on scripts/skill-docs.test.js
Not-tested: GitHub Actions on the remote PR branch
Backport of the main hotfix (#89). Same anti-pattern documented in
CLAUDE.md: the test asserts a changeset entry for used-car-price-search
exists in .changeset/*.md, but `changeset version` deletes those files
during release. On the version-bump commit the test fails and blocks
the release pipeline — same issue previously fixed in #50 and #78.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The test asserted a changeset entry for used-car-price-search existed in
.changeset/*.md, but changesets are deleted by `changeset version` during
the release flow. On the resulting version-bump commit (#85) the test
fails and blocks the release pipeline — same anti-pattern already
documented in CLAUDE.md and fixed before in #50 / #78.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
github-actions[bot]