This article was originally written in Japanese and translated into English with AI assistance. Please note that some expressions may carry nuances from the original Japanese.
🇯🇵 日本語版はこちら / Japanese version
In the previous post (SP03), I wrote about completing the translation and structural unification of 16 files. Everything was running perfectly in my local development environment. All that was left was to just upload it to the production server.
“Just upload it.” These words may be the most dangerous in the world of development.
Pre-Deployment Status Check — Better to Be Overly Cautious
Session 16, the beginning of the project’s final session. 1:10 AM.
First, I had Claude Code run a seven-item status check. Git status, recent commit history, file listings and sizes for both English and Japanese versions. After confirming everything was as expected, I prepared the deployment file list.
Eight English files, about 257 KB; eight Japanese files, about 259 KB. 16 files total, about 505 KB. I also explicitly listed files excluded from deployment (journals, archived older versions, .DS_Store files, etc.).
The value of writing out the “exclusion list” wasn’t clear to me until I actually did it. Rather than the risk of missing uploads, the scarier risk is accidentally uploading extra files like .DS_Store (metadata files macOS creates without asking). Having a list in advance helps prevent the accident of “oops, select all” on the FTP file manager screen.
FTP Upload — This Part Is Human Work
I opened the file manager on Star Rental Server, and created new /en/ and /ja/ directories. Then I uploaded the 16 files to their respective directories.
This is manual work by a human (me). I had wanted to deploy directly from Claude Code, but I couldn’t get FTP authentication automated. I couldn’t find a way to route the Star Rental Server FTP connection through Claude Code, and ended up manually uploading via the browser-based file manager. This remains a task for the future.
The upload itself finished in a few minutes. The problem came next.
The .htaccess Trap — The Infinite Redirect Loop
After the upload finished, I accessed the root URL sr-works.net) in the browser.
“Too many redirects.”
The browser halted with an error. All pages unreachable. Immediately after going live, the entire site became inaccessible.
The cause was the configuration in the .htaccess file. I had written Redirect permanent / /ja/index.html as the setting to redirect visitors to the root URL /) to the Japanese top page /ja/index.html) — but this was causing an infinite loop.
Redirect permanent performs a prefix match on the path. In other words, it matches every URL starting with /. Since the redirect target /ja/index.html also starts with /, it triggers the redirect as well, which redirects to /ja/index.html again, which matches / again — infinite loop.
The solution was to rewrite it as RewriteRule ^$ /ja/index.html [R=301,L]. ^$ is an exact match for the empty string, meaning it only matches the root path itself and does not re-match /ja/index.html. Both Claude.ai chat and Claude Code proposed the same solution, so the fix was quick.
Engineers might think, “Isn’t that basic knowledge?” And I agree. But when someone with no programming experience builds a site collaborating with AI, you regularly step on this kind of “obvious” landmine. And since .htaccess behavior is hard to test in a local environment, it’s the kind of problem that only reveals itself in production.
The Iron Rule of Deployment Order — Delete the Old Last
Another thing I realized through this deployment is the importance of “leaving the deletion of old files for the very end.”
Directly at the root of the server, old HTML files from before the directory restructuring still remained. Once I had uploaded the new /ja/ and /en/ files, I was tempted to immediately delete the old files, but I intentionally left them in place.
This decision paid off. When the .htaccess redirect loop occurred, because the old files still existed, I could still access the old site by hitting URLs directly. If I had deleted the old files first, I would not have been able to verify any site contents during the redirect loop.
The “five-stage deployment order” established through this project is as follows.
(1) Pre-status check. (2) Create the deployment target list. (3) Upload new files. (4) Switch configuration + verify. (5) Delete old files.
By leaving (5) for the end in particular, you maintain a safety net for problems discovered in (4). The sequence “add new → switch → verify → delete old” is something I plan to adopt as a general protocol for static site production deployments in future projects.
All 16 Pages, Zero Broken Links
After fixing .htaccess, I verified operation in the production environment. Navigation links, language switching, transitions to the contact form, mobile hamburger menu, footer links, AI translation disclaimer display. All pages normal across these six verification points.
Additionally, Claude.ai chat used web_fetch to sequentially retrieve all 16 pages and exhaustively check internal, external, and mutual links. Zero broken links.
Past 2 AM. I deleted the old files, restructured the public layout to just the two directories /en/ and /ja/, and declared the project complete.
Looking Back on 6 Days and 16 Sessions
The HP English translation project was completed in 16 sessions across six days, from April 13 to 18, 2026. Newly creating 8 English files, modifying 8 Japanese files, unifying the navigation structure, 212 link-path modifications, and the production deployment.
Starting from discovering simultaneous HTML tail damage in three files on day one, and ending with facing the .htaccess infinite redirect loop on the final day. From start to finish, it was a project about continuously fixing things made by AI, together with AI.
The biggest feature of this project was that the four parties — Claude Code, Claude.ai chat, Microsoft Copilot, and the human (me) — coordinated with clear role divisions. In the DM series and UC series, the structure was “1 human + 1 AI,” but in the HP English translation, I combined multiple AIs for the first time into a coordinated structure that leveraged each one’s strengths.
From next time, we return to the original timeline and begin the DataMigrator story. A tale of data migration hell from four months ago.
Also, in the paid section that follows, I’m publishing the mechanism that made it possible to systematically preserve 16 sessions of records — the complete framework of the journaling system, together with the full set of prompts you can copy-paste into your own project. A hearing-based prompt that supports launching new projects is also included.
Why 16 Sessions Worth of Records Could Be Systematically Preserved — The Journaling Operation Mechanism
I’ve written three posts so far as SP02 through SP04, and there is a reason these posts could be written at this density. For all 16 sessions of the HP English translation project, detailed journals (work records) were systematically preserved.
It’s easy to say “Let’s keep a project record,” but it’s remarkably difficult to actually keep doing it. Especially when development enters critical phases, the feeling of “If I have time to write a journal, I’d rather write code” tends to win, and records fall off.
In the HP English translation project, 2,408 lines on the Code side and 5,223 lines on the Chat side — 7,631 lines total — of journals remained across 17 files. Here, I’ll share how this wasn’t accidental but the result of a mechanism.
A Three-Layer Journaling System
The mechanism for journal creation is composed of three layers.
First, the generation of a “specialization layer.” At the very first session of the project, five elements specific to that project — the roles of the AI agents and humans involved, project-specific terms and abbreviations, points of particular note to record, and project-specific stumbling patterns — are extracted and templated. For the HP English translation project, unique concepts like “three-way cross-review system,” “seven IP-protection observation points,” and “Copilot review loop counts” go into the specialization layer.
Next, using this specialization layer embedded into the general-purpose journaling prompt, a “customized version” is created for each of Claude.ai chat and Claude Code, forming two tracks.
The Chat customized version is designed to record “why a given instruction was issued,” “how judgments were made,” and “what was not chosen.” Register it in the project knowledge, and at session end, a single instruction like “Please generate a journal” will produce a structured output of the judgment flow from that session.
The Code customized version is designed to record “what was done.” File operations, grep verifications, commit history, technical tips — recorded in chronological order. This one is saved in the project directory, and similarly generated with a single instruction at session end.
Synchronizing Chat and Code — The session_id Mechanism
How do two journals, generated separately by different AIs, get reconciled with each other? The core of this mechanism lies here.
At the top of each journal, a YAML metadata block is output. Within it, there is a field called session_id, formatted as “project-abbreviation-date-same-day-sequence-number.” For example, srwhpen-20260414-01 means “SRW HP English project, April 14, 2026, the first session of the day.”
By having both Chat and Code record the same session_id, you can uniquely identify that “this Chat journal and this Code journal are records of the same session.” Someone reading the journals later (future-me or a blog reader) can reconcile the two by session_id to trace both “the reasoning behind a decision” and “the reality of the work.”
Operational Procedure for Synchronization — Code First, Chat Second
However, the session_id mechanism alone doesn’t achieve synchronization. The actual operation has a definite order.
First, create the Code-side journal first. When you instruct Claude Code, it numbers a session_id based on the file operations and commit history executed in that session, and generates the journal. Upon completion, a completion report is displayed on the Code-side screen, including the session_id, a list of main section headings, the number of stumbling items, and so on.
Next, paste this completion report, along with the body of the generated Code journal, into the Chat side. This is the key to synchronization. The Chat side does not know in advance what Code did or what session_id was numbered. By receiving the Code-side journal, the Chat side can, for the first time, grasp “what Code executed in this session” and “what the session_id is.”
Then, instruct the Chat side to generate a journal. The Chat side, referencing the Code-side journal and session_id, searches the chat history within the project and summarizes the instructions and judgment flow from that session. Two-viewpoint records, linked by the same session_id — “what Code did” and “what was decided in Chat” — are now complete.
If you reverse this order (generate the Chat side first), the Chat side will number its own session_id independently without knowing Code’s, and later reconciliation becomes impossible. “Code first, Chat second” is the iron rule.
An Honest Look at the Distance Between Ideal and Reality
Ideally, journals would be generated automatically at session end. But at this point that level of automation hasn’t been achieved, and at the end of each session a human has to do the work manually. Specifically: (1) instruct Code to generate the journal, (2) paste the Code completion report and journal body into Chat, and (3) instruct Chat to generate the journal — three steps.
Even so, because “what to record,” “how to structure the record,” and “how to sync the two tracks” are pre-defined in the prompts, following this procedure produces consistent-quality journals every time. Even though manual coordination is needed, the effort is entirely different from “writing a journal from scratch.”
Without this mechanism, 16 sessions of records probably would not have been preserved. At the very least, I wouldn’t have had the material to write SP02 through SP04 at this density.
As a Reproducible Methodology
This mechanism applies beyond just the HP English translation project, to any project collaborating with AI. What’s required is about 30 minutes of investment to create the specialization layer at the start of the project, plus 10 seconds at each session end to say “Please generate the journal.”
For anyone who wants to convert vibe coding development records into blog articles, or who wants to look back on their collaboration process with AI later on — I hope this is useful as a reference.
Below, I’ve included samples of the actual prompts I use. You can copy them and use them as-is.
[Appendix 1A] Specialization Layer Generation Prompt (For Existing Projects)
Precondition: The project is already underway, with context accumulated in chat history or project knowledge
Input target: A chat within the Claude.ai chat project (at the end of the first session)
Save destination for the generated result: Register as “Specialization Layer” in the Claude.ai chat project knowledge
# Request for Context Optimization of the Journaling Prompt
Based on the context of this project/session, please create a
"project specialization layer" for the journaling prompt.
It will be used as a diff to append to the general-purpose journaling prompt.
Name the file "Specialization Layer."
## Five Elements to Output
### 1. Project-Specific Role Assignment Table
A list of the AI agents, humans, and external tools involved in this project,
along with each party's area of responsibility. Concrete descriptions that
replace the "role assignments" section of the general-purpose version.
### 2. Points of Particular Note to Record in This Project
List important events that occurred in this session. To be reused in
subsequent sessions as observation points for recording events of the same type.
### 3. This Project's Specific Glossary of Terms and Abbreviations
Templates for first-time footnote explanations of abbreviations used
in the journal. Designed so that readers assumed to be beginners can
understand project-specific concepts.
### 4. This Project's Characteristic Stumble Types
Perspectives specific to this project that should be added to the
general-purpose version's "stumble extraction criteria."
Examples: for a translation project, "scenes where source and translated
text structures diverged"; for a website project, "scenes where browser
rendering differences became a problem."
### 5. This Project's Specific Sync Metadata Extensions
Fields specific to this project to add to the general-purpose version's
sync metadata block.
Examples: for a translation project, "name of translated file,"
"whether reviewed"; for a web build, "browser verification performed,"
"deployed or not."
## Output Format
Markdown in a form that is "appended to" or "replaces" the corresponding
section of the general-purpose journaling prompt.
Please output both a Claude.ai chat version and a Claude Code version.
## Judgment Criteria
- If project-specific elements are thin, it's fine to answer
"general-purpose version is sufficient, specialization layer unnecessary"
- Excessive specialization stiffens the journal, so the judgment point is
"does this have repeat-record value in subsequent sessions?"[Appendix 1B] Specialization Layer Generation Prompt (For New Projects, With Hearing)
Precondition: The project hasn’t started yet, or has just started with almost no context in chat history. This prompt handles “project discovery → definition → specialization layer generation” in one integrated flow.
Input target: Create a new Claude.ai chat project and input into the first chat
Save destination for the generated result: Register as “Specialization Layer” in the Claude.ai chat project knowledge
# New Project Definition + Journaling Specialization Layer Generation
I'm about to start a new development project.
First, let's organize the project definition together, then generate the
"specialization layer" for journal creation.
## Phase 1: Hearing the Project Definition
For the following items, please ask me one at a time in a dialogue format.
Don't ask everything at once — proceed one question at a time.
If my answer is vague, please deepen with concrete examples.
### Items to Ask About (In Order)
1. Project Purpose
- What do you want to build? What problem do you want to solve?
- Do you have a completion image? Or is it still vague?
2. Goal Definition
- What does "complete" mean? (A working prototype? A production
release? A finished design document?)
- Is there a deadline?
3. People and AI Involved
- How many humans are involved? What's each person's role?
- Which AI tools are you planning to use? (Claude Code, Claude.ai
chat, Copilot, others)
- How much will you delegate to AI? (Code generation, review, design,
everything?)
4. Technology Stack and Environment
- What language / framework / hosting will you use?
- If undecided, "undecided" is fine
- What's the development machine OS (Mac / Windows / Linux)?
5. How You'll Proceed
- How often will you work? (Every day? Weekends only?)
- What's the typical length of one session?
- Will you use version control like Git?
6. Purpose of Records
- What do you want to use the journals for?
(Personal retrospectives? Blog posts? Sharing with a team?)
- Who's the assumed reader? (Just you? Engineers? Non-engineers?)
## Phase 2: Generate Project Definition Document
Once the hearing is complete, please compile the answers into a
"Project Definition Document" in Markdown format.
This will be registered in project knowledge and referenced by all
subsequent sessions.
## Phase 3: Generate the Specialization Layer
Based on the project definition document, please generate a
"Specialization Layer" containing the following five elements.
1. Project-specific role assignment table
2. Points of particular note to record in this project
3. Project-specific glossary of terms and abbreviations
4. This project's characteristic stumble types
5. Project-specific sync metadata extensions
Name the file "Specialization Layer."
## Notes
- Please proceed with the Phase 1 hearing in dialogue format.
One question at a time, not all at once.
- I may be a programming beginner.
Please add footnotes when using technical terms.
- It's fine if answers like "not decided yet" come up during the hearing.
In that case, please propose tentative placeholders.
- If the project scale is small (e.g., a simple personal script),
feel free to judge "general-purpose version is sufficient,
specialization layer unnecessary."[Appendix 2] Chat Journal Generation Prompt (General-Purpose Version)
Integration procedure: Create a “customized version” by incorporating the specialization layer generated by Appendix 1 into this general-purpose version, then register it in the Claude.ai chat project knowledge as the “Chat Journal Prompt”
How to run: At session end, instruct in chat: “Please follow the Chat Journal Prompt in the project knowledge and generate a journal for this session”
Output destination: Output to chat as an artifact. Download as a file and save locally
# Claude.ai Chat Journal Creation Request
Please compile "the flow of instructions and judgments" from this session
into a journal. This will be used later as source material for blog articles.
## Position of This Journal
This journal complements the implementation-side journal (technical log
generated by Claude Code or similar), and is responsible for "why that
instruction was given," "how it was judged," and "what was not chosen."
Rather than the implementation procedure itself, it records the
decision-making process between humans and AI behind that procedure.
## Assumed Reader
A beginner Vibe coder (a non-engineer who doesn't write code directly,
but progresses development through dialogue with AI agents). Please add
brief footnotes for technical terms on their first appearance.
## Sync Metadata Block (Mandatory, Output at the Beginning of the Journal)
```yaml
session_id: [project-abbreviation]-[YYYYMMDD]-[same-day-sequence 01, 02...]
session_start: YYYY-MM-DD HH:MM (JST)
session_end: YYYY-MM-DD HH:MM (JST)
project_name: [Project Official Name]
session_number: [Cumulative session number]
journal_type: chat
counterpart_journal:
type: code
expected_path: docs/dev-journal.md (corresponding session section)
related_commits:
- hash: [commit hash]
timestamp: YYYY-MM-DD HH:MM
description: [Brief description]
key_phases_with_timestamps:
- phase: [Phase name]
time_range: HH:MM - HH:MM
summary: [One-line summary]
```
The session_id must match the Claude Code-side journal exactly.
For multiple sessions on the same day, distinguish by sequence (01, 02...).
## Structure Template
- Session theme, originally planned scope, actual outcome
- Role assignment (structure for this project)
- Chronological log (describe "what happened" and "what decisions were made"
phase by phase)
- Summary of stumbling points (situation, essence, learning)
- Good decisions / operational points
- Handover to next session
- Numerical notes for this session (session duration, number of exchanges,
number of commits, etc.)
## Writing Style
- Describe failures and stumbles candidly. Lessons are the main content
- Quote important user remarks in blockquotes
- Write so that the boundary between AI autonomous decisions and human
final approvals is visible
- Also record options that were considered and rejected ("we considered
an alternative and rejected it")
- For easy citation when turning into blog articles, include command
examples and diffs verbatim
## Stumble Extraction Criteria
Record events meeting any of the following as stumbles:
- Scenes where unexpected errors / anomalies surfaced
- Scenes where the human misunderstood a concept
- Scenes where the human revised or rejected an AI proposal, or vice versa
- Scenes where literal rule and rule intent diverged, requiring an
exception judgment
- Near-misses where "the problem would have expanded if unnoticed"
## Post-Completion Report
(a) The filename of the created journal
(b) Total line count
(c) Number of stumble items extracted
(d) One to three recommended title suggestions for blog article conversion[Appendix 3] Code Journal Generation Prompt (General-Purpose Version)
Integration procedure: Create a “customized version” by incorporating the specialization layer generated by Appendix 1 into this general-purpose version, and save it in the development project directory as docs/journal-prompt-code.md
How to run: At session end, instruct in Claude Code: “Following the instructions in docs/journal-prompt-code.md, please append this session’s content to docs/dev-journal.md“
Output destination: Directly appended to the project’s docs/dev-journal.md (existing content preserved, added to the end)
# Claude Code Journal Creation Request
Please compile what was done and what was stumbled on in this session
into a journal. It will be used later as source material to be formatted
and published as a blog article.
## File Specifications
- Location: Directly under the project root, /docs directory
(create new if it doesn't exist)
- Filename: dev-journal.md
- Operation: Append per session (preserve existing content, add to the end.
Preserve any project overview at the top)
- Character encoding: UTF-8
## Assumed Reader
A beginner Vibe coder (a non-engineer who doesn't write code directly,
but progresses development through dialogue with AI agents). Please add
brief footnotes for technical terms on their first appearance.
## Sync Metadata Block (Mandatory, Output at the Beginning of Each Session Section)
```yaml
session_id: [project-abbreviation]-[YYYYMMDD]-[same-day-sequence 01, 02...]
session_start: YYYY-MM-DD HH:MM (JST)
session_end: YYYY-MM-DD HH:MM (JST)
project_name: [Project Official Name]
session_number: [Cumulative session number]
journal_type: code
counterpart_journal:
type: chat
expected_path: [Filename of the Claude.ai chat-side journal]
related_commits:
- hash: [commit hash]
timestamp: YYYY-MM-DD HH:MM
description: [Brief description]
key_steps_with_timestamps:
- step: [Step name]
time_range: HH:MM - HH:MM
summary: [One-line summary]
```
The session_id must match the Claude.ai chat-side journal exactly.
For multiple sessions on the same day, distinguish by sequence (01, 02...).
## Structure Template
- Session goal (work originally anticipated)
- What was actually done (chronological)
- Stumbles and unplanned discoveries (situation, cause, response, learning)
- Technical discoveries / tips
- Reflection on role assignment
- Handover to next session
## Writing Style
- Don't hide failures or stumbles; describe candidly
- Write so that the boundary between AI autonomous decisions and human
final approvals is visible
- For easy republishing when turning into blog articles, include code blocks
and command examples verbatim
## Stumble Extraction Criteria
Record events meeting any of the following:
- Scenes where unexpected errors / anomalies surfaced
- Scenes where there were issues in AI-generated code / content
- Scenes where literal rule and rule intent diverged, requiring an
exception judgment
- Near-misses where "the problem would have expanded if unnoticed"
- Scenes where the same problem had propagated to other places
## Post-Completion Report
(a) The file path of the created file
(b) Total line count
(c) List of main section headings
(d) Number of stumble items extracted[Summary: How to Use the Appendices]
Step 1 (Once per project, about 30 minutes): Depending on the project’s situation, use either Appendix 1A or 1B. If the project is already underway and has context, use 1A. If it’s a new project with nothing decided yet, use 1B (with hearing). In the 1B case, the AI will draw out the project definition in dialogue format, so you’re fine even if you’re in a “I don’t know where to start” state. Register the generated specialization layer in the project knowledge.
Step 2 (Once per project, about 10 minutes): In the same chat, request: “Please incorporate the specialization layer from the project knowledge into the following general-purpose prompt to create a customized version,” and paste Appendix 2. Register the generated customized version in the project knowledge as the “Chat Journal Prompt.”
Step 3 (Once per project, about 10 minutes): Similarly create a customized version of Appendix 3, and save it in the development project directory as docs/journal-prompt-code.md. Instruct Claude Code: “Please save this file as docs/journal-prompt-code.md.”
Step 4 (At every session end, about 5 minutes): Proceed in the following order. Order matters.
(4-1) Code side first. Instruct Claude Code: “Please append a journal following docs/journal-prompt-code.md.” Code numbers a session_id and appends to docs/dev-journal.md. On completion, a completion report (session_id, heading list, number of stumbles, etc.) is displayed on screen.
(4-2) Bridge from Code to Chat. Paste the Code completion report and the body of the generated journal into the Claude.ai chat. This lets the Chat side know “what Code did” and “what the session_id is.”
(4-3) Chat side second. Instruct Claude.ai chat: “Please generate a journal.” The Chat side inherits the Code-side session_id, extracts the decision flow from the chat history, and generates a Chat-side journal linked by the same session_id.
Through this “Code first → bridge → Chat second” order, two-viewpoint records, synced by the same session_id, are completed.
Next Time
From next time, we return to the original timeline, and we’ll bring you the DataMigrator series (B01): “Falling into Data Migration Hell While Setting Up for Local AI Development.”
That was the plan — but I’m still not able to move on to DataMigrator just yet. The next post will be a short detour before we get there.
About Soul Resonant Works
Soul Resonant Works is a solo venture developing seven local AI systems.
Starting from zero programming experience, the development is progressing through collaboration with AI.
🌐 Soul Resonant Works:
→ https://www.sr-works.net/en/
📝 This blog publishes the entire development process as a serialized journal.
If you found this article useful, please share it.
Leave a Reply