Beyond passing tests

A wrong venue or a misleading fee can make it harder for someone to decide whether to attend an event.

On October 27, 2026, we improved the Japanese and English event-detail pages on the Miyako de IT website. The change presented venue, access and ticket-specific fees from the official listing in both visible content and structured data. AI-assisted implementation and independent review exposed gaps that the existing tests had not covered.

The change and verification record are available in PR #374. Three parts of the work are useful for other AI-assisted development projects.

A starting price can turn into a fixed price

An English fee formatter that extracts only a number can lose its conditions. Translating a Japanese input meaning “from 1,000 yen” as “¥1,000” makes a starting price look fixed. This counterexample became a required correction during review.

We preserved the meaning of ranges and lower bounds:

The first column translates the meanings of the parser test inputs. These examples are not a price list for a particular event; the linked pull request contains the original Japanese fixtures.

Machine-readable prices need conditions too. In this implementation, ranges, unknown fees and fees with eligibility conditions beyond payment method are not emitted as exact prices in JSON-LD. JSON-LD is a format that helps search engines and other systems interpret page information.

Where there are multiple ticket types, we retain their names and prices together and ask readers to check each ticket's conditions on the official registration page. One free ticket type must not turn into a claim that everyone can attend free.

The expected result must cover whether someone can safely use the amount to make a participation decision.

HTML extraction can silently lose information

Ticket extraction depended on an exact class string. A parser supporting class="ptype" could miss the same ticket element written as class="ptype selected".

The fix matches the individual whitespace-separated class token rather than the entire string. A regression test also checks that a similar token, ptypes, is not mistaken for ptype.

Access extraction had a different gap: it stopped at the first tag or newline after the label. A link, emphasis tag or line break could therefore remove the rest of the instructions.

We changed it to read to the end of the access item and normalize tags and line breaks into display text. Additional tests check that the following item is not included.

This is a parser for the connpass HTML patterns we checked. It does not establish compatibility with every future HTML change.

No horizontal overflow does not guarantee readable Japanese

Narrow screens split the two-character Japanese words for “on foot” and “check” between their characters. The page could fit horizontally while the text remained awkward to read.

We kept the original text and protected only short semantic units from breaking. Keeping an entire sentence on one line would create problems on narrow screens, so protection was limited to parts such as station names, walking times and short instructions.

We checked both language versions, including mobile widths. After changing the CSS, we had to read each line ending together with the start of the next line.

Keep each discovered counterexample

The final candidate passed 1,068 tests, independent code review and the required GitHub CI. Production checks then covered the Japanese and English event-detail pages at five widths each: ten cases. They verified matching venue, access, ticket fees and structured data, zero horizontal overflow and no JavaScript exceptions.

Those counts describe the tested scope. They do not cover every page or future input. Effects on AI citations, registrations and actual attendance remain unmeasured.

For your own project, start with one input that could cause a user to make the wrong decision. Write the expected output, demonstrate that the test fails before the fix, then run it and the relevant surrounding tests after the fix. Finally, inspect the interface the user will actually see.

When asking another person for feedback, explain both what has passed and what remains unchecked. That makes the review request more concrete.

If you want to bring a development question to a session, browse Miyako de IT events. Check the topic and participation conditions before choosing one.

Case checked on October 27, 2026. The evidence concerns PR #374 and its production verification. It is not a controlled comparison of AI products or proof that all defects can be prevented.

Related development reading

See role-separated AI agent workflows for assigning responsibilities, or the four-line question note for preparing a request for help. Browse all articles for more.