Filed by /printing-press-retro from a run of TNSTC OTRS
(scorecard Not formally run, Build + live smoke tests passed).
Summary
TNSTC delivers all search results and seat layouts as server-rendered JSP/Struts pages, encoding data within JavaScript function calls (e.g. showLayOut(...)) inside the HTML body. There is no skill recipe for extracting data from these "HTML-wall APIs", leaving the agent to re-discover the encoding pattern, regex extraction, and session-based form-POST structure through extensive trial and error. A recipe would significantly speed up generation for similar portals.
Where to look
- Component: skill
- Likely area:
skills/printing-press/SKILL.md (specifically under "Spec source: none / browser-sniffed")
- Triggered when: The API lacks a spec and embeds data as JS function arguments inside HTML responses, typical of many legacy JSP/Struts or PHP portals (e.g. regional government transport/utility portals).
What we observed
The agent spent ~45 minutes discovering the showLayOut('svcID,classID,...','slNo','seats') encoding and writing a regex parser, compared to an estimated ~5 minutes if a recipe existed.
tnstc-pp-cli required multiple iterations on buses.go and seats.go to correctly identify and parse embedded JS data.
Suspected root cause
The main skill (SKILL.md) lacks guidance for portal-style APIs where the only data surface is JavaScript embedded in HTML responses.
Suggested direction
Add a ## Portal-style APIs (HTML-embedded JS) section to the main skill's "Spec source: none / browser-sniffed" handling. This section should cover:
- Identifying the data-in-JS pattern.
- Building a regex parser for extracting packed CSV/JSON from JS call signatures.
- Form field structure probing and session cookie tracking (e.g., JSESSIONID).
Acceptance criteria
- positive: An agent given a similar JSP portal (e.g. KSRTC.in) successfully builds the extraction command without exploratory trial-error loops.
- negative: Normal REST CLIs are unaffected (recipe is explicitly gated on "no spec + data-in-HTML-JS pattern detected").
Frequency
subclass:portal-html-embedded-js
Complexity
medium
Scope boundary
Does not cover SPAs; only covers traditional server-rendered JSP/PHP portals with embedded JS data.
Dependencies
None.
Artifacts
| Artifact |
Link |
| Retro document |
Upload failed — see local copy |
| Manuscripts (research + proofs) |
Upload failed — see local copy |
| Generated CLI source code |
Upload failed — see local copy |
Generated by /printing-press-retro · CLI Printing Press
Summary
TNSTC delivers all search results and seat layouts as server-rendered JSP/Struts pages, encoding data within JavaScript function calls (e.g.
showLayOut(...)) inside the HTML body. There is no skill recipe for extracting data from these "HTML-wall APIs", leaving the agent to re-discover the encoding pattern, regex extraction, and session-based form-POST structure through extensive trial and error. A recipe would significantly speed up generation for similar portals.Where to look
skills/printing-press/SKILL.md(specifically under "Spec source: none / browser-sniffed")What we observed
The agent spent ~45 minutes discovering the
showLayOut('svcID,classID,...','slNo','seats')encoding and writing a regex parser, compared to an estimated ~5 minutes if a recipe existed.tnstc-pp-clirequired multiple iterations onbuses.goandseats.goto correctly identify and parse embedded JS data.Suspected root cause
The main skill (
SKILL.md) lacks guidance for portal-style APIs where the only data surface is JavaScript embedded in HTML responses.Suggested direction
Add a
## Portal-style APIs (HTML-embedded JS)section to the main skill's "Spec source: none / browser-sniffed" handling. This section should cover:Acceptance criteria
Frequency
subclass:portal-html-embedded-js
Complexity
medium
Scope boundary
Does not cover SPAs; only covers traditional server-rendered JSP/PHP portals with embedded JS data.
Dependencies
None.
Artifacts
Generated by
/printing-press-retro· CLI Printing Press