讓手機也能免費同步+編輯 Obsidian 筆記：一場 vibe coding 實驗

前陣子又開始用 Obsidian 當筆記軟體，File over app 的設計概念在這個時代剛好成為它的核心優勢，資料夾結構和純文字檔(Markdown 或各種格式)不只在 Obsidian 裡使用，隨便用個 AI IDE 或 CLI 工具，打開筆記檔案所在的資料夾，輸入一些 prompt，就能生成一些新內容，甚至連上其它自動化流程。

小時候第一個用的筆記軟體應該算是 Evernote，後來它的「商業化發展」，讓人對這種線上服務多少都有點心理陰影。
這幾年陸續又用了不少方式來記錄筆記，有時候隨著平台結束服務或政策大改變，又要連夜跑路。

或是某天用一用會突然進入「聖人模式」，覺得奇怪，筆記用意是想要有一天可以派上用場，為什麼花這麼多時間在「學習筆記軟體如何操作」跟「整理資料」勒?

我的意思不是軟體應該設計到不用學就能用，整理資料也牽涉很多圖書館學、教育領域的知識，肯定都需要學習才能做得好的，但有時候似乎有點本末倒置了?

在 LLM 的時代，我想有些筆記其實沒有存在的必要，有時候不需要再回頭翻閱冗長的參數表、逐一確認參數與指令的用途，也不必重看自己過去踩過的坑。有些知識與經驗可以即時被 AI 重建、優化，講難聽一點，有些事物的迭代速度和資訊量比單一人類做筆記還快，一個人類是有多能學、多會背? 讓筆記的角色逐漸從「死板的紀錄」轉向「提供上下文，幫助 AI 產生更好輸出」的工具。

數位囤積症患者碰上 Obsidian 這種產品真是非常舒服，所有資料都可以是本機的獨立檔案，或是把整個資料夾備份到任何地方，完全不怕被平台鎖死。

甚至操作上有任何不滿意的地方，都可以 vibe coding 自幹一套。

本文就來做一個實驗，vibe coding 一個網頁版的 Obsidian 筆記，在任何平台的電腦、手機、iPad 上都可以輕鬆新增、修改、瀏覽筆記。

Obsidian 的跨裝置同步難題

Obsidian 在 2020 年左右就有出一個跨裝置同步的功能，要付費。記得當時市場上還有其它筆記軟體，差不多價位，但功能更多、同步額度更大。老實講，要是不放圖片，額度也許根本用不完，但就是怕會用完。

後來 Obsidian 在去年(2024 年 3 月)又出了一個更便宜的同步服務套餐，月費要 4 美元，付費之後方案也不是無限使用的，vault 數量、儲存容量、修改紀錄保存時間都有限制。

• 1 synced vault
• 1 GB total storage
• 5 MB maximum file size
• 1 month version history

另外還有一個更高階的 Plus 方案，使用額度更大，但仍然不是無限。
一般人看的是月費 4~8 美元，我看到的是人家團隊要整年監控機器運作狀態、萬一筆記臨時要用時打不開，準備被使用者罵得狗血淋頭。要負擔使用者各種客服問題，要開發 Android, iOS, macOS, iPadOS, Windows 等各種平台的 app，還要提心吊膽保證每次出新的 os 版本，app 不會閃退會或幹嘛的，還要保障資訊安全。

網路上找一些 Obsidian 大神如何處理跨裝置筆記這回事，大致有三種:

• 把筆記放在 iCloud 或各種雲端硬碟，然後用麻煩的方式來同步。
• 把筆記同步到 GitHub 上，然後在手機或平板上安裝各種 git 客戶端，然後讓官方的手機 app 來讀檔案。
• 碰到喜歡玩開源的工程師，寫給工程師，或寫給 Android 手機使用者看的，還會有各種花式雜耍技巧。

可以到一些國外論壇爬文，看看大家對於 Web Version of Obsidian 或是 A Hacky Solution for Obsidian Sync 有些什麼奇思妙想。

以第二種方法而論，稍微用過 git 的人，尤其是那些常常在解 merge conflict 的，都心知肚明，雖然也許比較不會遇到雲端同步災難「軟體卡住一直轉圈圈，轉了 2 天不知道到底在同步什麼?」或是「莫名其妙檔案被刪光光/檔案被回溯」的問題，但 git 操作邏輯和一般的雲端同步軟體相比，在這種使用情境也絕對談不上什麼無縫絲滑、輕鬆無腦。

如果我是什麼心靈健康主題類的部落格，這時候應該要提倡什麼工作之餘就放下手機好好休息，Obsidian 就在電腦上使用就好。然後開始放一些心靈成長課程、宗教師父的話、旅遊分潤連結、推銷 eSIM、VPN...

既然沒有官方 Web 版本，那就自幹一套

理由一大堆，什麼官方付費方案有限制，什麼 git 在這種場景不好用，反正數位客家人是不想花這筆錢的，Obsidian 好像也根本沒有出什麼 web 網頁版本。

突然想到，既然我是把筆記備份到 GitHub 私人 repo，然後我之前有用過 GitHub 的 API，它的 API 也有各種檔案操作功能，那我直接自幹一套網頁筆記程式不就好了嗎? 然後弄成 PWA，操作起來可以滿足 87% 的需求。

醜話講在前面

為了怕大家一時衝動，覺得這個辦法可以完全替代官方的 Obsidian Sync 或其他跨裝置同步筆記的奇巧淫計，先把醜話講在前面:

GitHub API 的限制

這個實驗的概念是透過 GitHub API 去操作檔案，所以要看人家 API 的臉色，GitHub API 有 rate limit 跟一些限制，而且不是付錢就能解決的。

如果沒有 rate limit 等相關概念，建議先去理解搞懂再繼續看下去，以免筆記跑不出來，還以為程式有問題。

其他的限制在後面的段落中會再提，例如剛剛新增的筆記內文不能馬上被搜尋之類的。

GitHub 平台的爭議

GitHub 現在是微軟的，目前宣稱不會拿 private repo 去訓練，個人帳號預設也不會開啟拿資料去訓練的設定(在帳號設定層級有Allow GitHub to use my data for AI model training，而不是在 repo 個別控制)，

有時候會有人會被 GitHub 莫名其妙被封帳號，不過至少本地還有一份 Obsidian 的 vault，比較不用擔心。

前幾年 GitHub 因為美國的一些政策，禁止伊朗等一些國家的使用者使用 private repo，把功能鎖起來，雖然後來解開了，但也難保未來不會再發生。

運作成本

這套網頁程式需要找到地方佈署和維持它的運作，前後端程式有各種地方需要維護，我只是順便利用一下手上機器的資源，用起來不爽的時候就讓 AI 去改程式，沒有什麼額外成本。

普通人如果到一個月動輒 $5 美金起跳的 PaaS 平台開幾個服務，讓這套程式跑起來，然後網頁發生任何前後端或 SRE 問題，還要再花個美金幾十塊起跳的月費租 AI 去處理? 如果有成本考量，那不如乖乖用官方的 Obsidian Sync 就好了。

替代方案的替代方案

本來討論的是自幹一套網頁筆記程式，來替代 Obsidian Sync 或各種麻煩的跨裝置的同步方式。

但有可能我們根本不用自幹一套筆記軟體，這種 File over app 的邏輯有其他的替代方案。

如果 vault 放在 GitHub 上，理論上可以用網頁瀏覽器去檢視跟修改筆記檔案，GitHub 網頁版的 online editor，或是 https://vscode.dev/ 這種 cloud IDE 都能輕鬆辦到。

另外還有 GitJournal 這種產品，專門設計給手機用，可以跟 git repo 同步檔案，還有一個基本的檔案編輯器功能，專為 Obsidian、Notable 這種筆記軟體設計。
不過 GitJournal 的 Android 版本免費，iOS 版本美金 $3.99，一次性付費，不用每個月繳費，非常佛心。

但畢竟它不是 Obsidian，操作起來有說不出的難受，而且很多 Obsidian 的功能都不支援。

還有 SilverBullet 這種產品，提供一套 Docker 自架程式，或雲端版的程式，讓人管理自己的 Markdown 筆記。

只有筆記功能

承上點，主要只有先做處理 markdown 格式筆記的功能，其它一些 Obsidian 的功能，像是 Canva、Database/檔案開頭的 YAML 格式資訊、各種有的沒的 Link 功能之類的，社群插件能做到的功能，本文完全沒有去碰。

沒辦法離線使用

設計邏輯是透過網頁程式直接讀寫 GitHub repo 的檔案，完全沒特別設計什麼沒網路要如何使用，也沒有考慮切換應用程式時被殺後台時，編輯到一半的內容怎麼辦...之類的問題。

自幹網頁版筆記軟體的好處

不佔空間

有些 Obsidian 跨裝置同步方法，會在每個裝置保存整個 vault 的所有檔案，非常占手機跟平板的空間。
這大概是我想做這個網頁版的初衷，這種玩法沒有占裝置空間的問題。

當然後續可能因為夢想無限膨脹，想要離線閱讀筆記，或是用量大到要減少呼叫 GitHub API，或是要加速檔案搜尋，可能導致又要留一堆檔案在本地，網頁程式的伺服器上多產生一堆索引檔...

電腦上也能用

理論上電腦也可以用這個網頁版，這樣電腦上就不用多開一個 Obsidian 程式，而是多開一個瀏覽器分頁而已。

除了非常方便就能利用瀏覽器的內建翻譯功能，或第三方翻譯擴充套件之外，現代的網頁瀏覽器流行搞 AI 功能，叫出瀏覽器側邊欄的 AI，讓他根據文件生成一些東西，非常輕鬆。

GitHub REST API 的好處

GitHub API 實測之下算是非常的 vibe coding friendly:

• 似乎是 2022 年出的，市面上的幾個大模型(GPT5, Claude 4)的 knowledge cutoff 大都在 2023~2024 年間，符合年份。
• 近幾年官方比較常在搞 GitHub Actions 那邊的東西，還有到處塞 AI，其它功能比較少頻繁大改版，LLM 對它都很熟。

驗證機制比較沒這麼複雜，差不多就是呼叫的時候帶上一組 token 而已，也沒有 domain 限制，而且可以從 GitHub 那邊直接把 token 註銷或增減權限。

自由度

操作介面可以自己亂改、加功能。

所有操作都有紀錄

無論是檔案整個誤刪，內文有一段誤刪還是怎樣，基本上都可以找回來(只要不是人為上去下一些可怕的指令)，我也完全不需要設計一套複雜的機制，什麼檔案變更時要存 version history 跟一堆修改細節什麼的，畢竟這都是 git 天生就有的功能嘛。

反觀在電腦上使用 Obsidian ，操作了一整天可能才手動 push 幾次，碰到問題想要找回途中遺失的內容? 希望非常渺茫。或是要安裝一些編輯記錄相關的社群外掛，但有時候「編輯紀錄」跟「復原內容」是兩回事。

用免費的 AI IDE 做出初代版本

當時 AWS 團隊新出的 Kiro 剛好發布不久，還在新產品甜蜜期，免費帳號有好幾十次的 Claude Sonnet 使用額度，剛好拿來用一下。

Kiro 主打的是有一個 Spec Mode，大概跟 AI 說了一下:

• 指定前後端技術(Vue3+TailwindCSS+PHP)。
• 技術概述需求，先做一個精簡的功能測試版本 SPA，先不用任何需要 build 的開發方式，CSS&JS 直接引入套件的 CDN 路徑。也不用設計任何 router 機制。
• 操作 GitHub API，做出一個類似檔案瀏覽器、筆記瀏覽器的網頁程式。
• 一些一定要有的功能，要有一個檔案樹狀圖介面，筆記要可以新增跟修改，UI 要設計成大小螢幕都能正常操作...blahblah。

(原始的 prompt 是英文的，大概比上面更長，只是本文為了方便表達，換成中文要點清單)

Kiro 的 Spec AI 很快出了一套規劃，我仿效網路上常看到的vibe coding 的三不一沒有精神，

• 不需要看 API 文件
• 不需要學程式語言
• 不需要理解運作邏輯
• 沒有要負任何責任，任務沒辦法遂行都是 LLM 或是軟體太爛，絕對不是自己亂開需求或管理技術太差

AI 做的 design.md, task.md, requirements.md，我連看都沒看，多花時間去看這些東西就輸了! 跟現實一樣，有些客人或主管就是想到什麼做什麼，隕石開發法，基層工作人員能拿他們怎樣?

因為 GitHub 也是存在已久的 API，不需要把文件整理弄成機器可以方便讀取的格式，也不需要準備幾包官方 SDK 或 sample code 給 AI 參考，直接就可以開工了。

很快就做了第一版...那時候忘記仔細截圖，就想像有個 web 版的 Obsidian。

(假裝這裡有一張圖片)

細修才是痛苦的開始

稍微試了一下新增、修改、檢視檔案，看起來這概念是真的能用之後，就開始細修。功能開始無限膨脹，也請 AI 整個重構成 Vue 元件，把程式做成需要編譯與建置的。

然後像是按鈕跟訊息常常一下有中文一下有英文的，UI 對齊跟間距有許多不滿意的地方。
因為 Kiro AI 的使用額度是算次數的，而且 TailwindCSS 的前端架構，除了按鈕跟一些區域，大部分的東西都是一堆 atomic CSS 名稱，每次要改什麼都要 hashtag 檔案，選取起來或是報行數也很累，所以有些 UI 問題還是自己調比較快，省得來回反覆修改浪費次數。

最崩潰的一次修改是加上身分驗證，
先讓 AI 把未登入前不該被使用的東西都藏起來。
OK，確實很快藏好了。

接著 AI 經過漫長的來回修改，把登入驗證做完了。
OK，終於可以登入了。

登入之後一看，嗯? 怎麼之前正常的功能通通都壞了?
diff 之後發現「把未登入前不該被使用的東西都藏起來」那時候就把一堆東西都直接刪了。
但又不想退回好久以前的版本，於是又再慢慢補回來，並測試...

使用 AI 寫程式的靈異現象就不多談了，本文主要是來分享用 GitHub API 直接讀寫 Obsidian 筆記檔案這回事，甚至以後要用 GitHub API 作其他用途可能會發生什麼事。

GitHub API 的限制

GitHub 很不會做生意，沒有搞什麼要先付費升級到某個方案，才能申請 API，然後還要每個月依照用量算錢那套，反正就是免費的，感謝微軟爸爸。

REST API 基本功能

關於 GitHub REST API 的細部限制可參考官方說明 Rate limits for the REST API，摘錄幾個要點

• 個人版: rate limit of 5,000 requests per hour，組織帳號的額度會更高
• 單一 endpoint 每分鐘上限不能超過 900 點，它有一個點數表，有些 endpoint 跟 methods 耗費的點數特別高。
• 同時併發請求不能超過 100 個
• 會建立內容的，有 80 RPM 跟 500 RPH 的限制

因為筆記是放在 private repo，一定要驗證後才能撈，所以那些什麼未登入的使用額度就不用看了，詳情可參閱 About secondary rate limits 章節。

官方也提供方式讓人查剩餘額度，不用自幹一堆莫名其妙的東西。

另外不得不提一下 GitHub 這種版本控制服務的機制，雖然搬移檔案、檔案改名之類的操作，有時候像在操作 object storage 服務的 API，但這些東西之間無法類比，還是有很多不一樣的:

• 執行速度問題，有幾支 API 回應速度似乎特別慢，撈資料時要撈特別久，跟高貴的雲端服務不一樣，這不是錢可以解決的問題。
• 檔案搬完後，馬上根據新路徑去要內容顯示? 可能會暫時要不到檔案，要等一下下才會出來，畢竟這是一個實驗性質的專案，忍耐是一種美德。
• 要搬移檔案或新增檔案，如果碰到本來已經有一個同名的檔案? 系統的預設行為不會直接覆蓋檔案，要嘛多帶參數當成更新來處理，要嘛自己設計其他機制讓新舊檔案合併。

搜尋 API

筆記軟體一定會有個搜尋功能，好消息有 2 個:

• 每個檔案的原始字串非常乾淨，不是亂七八糟的 html，也不是像區塊編輯器軟體是一堆謎之 json。搜尋起來可以少費一點功夫。
• API 提供的搜尋功能不用擔心英文大小寫問題，無論內文是 "SEO" 或 "seo"，不用設計什麼奇怪機制，預設都能輕鬆搜尋到。

不過搜尋的使用額度跟剛剛另一邊是完全分開計算的，可參考 REST API endpoints for search

同樣摘錄幾點:

• search 的 RPM 是 30，code search 的 RPM 只有 10。
• 每次搜尋最多返回 1000 筆結果，而且如果同一個檔案中有 N 條符合，它會顯示成 N 條項目，我沒有仔細測，但實際能用的額度可能比想像中還少很多。
• 系統有查詢超時的設計，也許 repo 中確實有符合查詢條件的內容，但因為花太長時間查詢了，它就不管了，直接將已查到的內容返回，然後給個 incomplete_results:true。

有些拿 LLM 搞過一些功能的人，可能有寫過一種機制，當使用者輸入一個關鍵字，然後程式會將它拆解成 N 個查詢，然後讓 LLM 整理這 N 個查詢的結果，在 GitHub API 的限制之下，我們先單純的管理&檢視筆記就好，沒事最好不要加入其它的特別功能。

還有一大問題是搜尋索引時間，檔案就是搜尋不到? 這個在官方文件沒特別提，但是在 Reddit 和 GitHub Community 上一堆災情，索引時間等好幾天的都有，乖乖等就對了。

慶幸的是 API 的行為跟直接上去 GitHub 用網頁版，差不多是一致的，有時候晚上還找不到，隔天早上就有了。

也許有人想到了，那不要用 GitHub 的搜尋 API，而是把所有資料夾的所有檔案遍歷一次，把每個檔案的內容取出來比對?
那首先會被 5000 RPH 的限制卡到，檔案非常多的就不用想了。
然後這樣搞的話查詢一次要花很久時間，檔案有幾個，就要打幾次去要檔案然後比對內容，主機網路傳輸跟 CPU 資源用量圖表會瞬間上升，影響效能。

其實 AI 一開始寫的搜尋功能根本沒用到 search API，而是直接遍歷比對所有檔案，我還詫異為什麼這樣寫? 後來碰到索引問題，才發現 AI 真是有大智慧...。反正現在是在搜尋功能上面還做一堆選項，手動選擇要不要查詢所有檔案、選擇只搜尋哪些資料夾。

當然我想應該有人是用 Gitlab 之類的服務，或自架 git server 的，上文的限制根本不是問題。反正我先把問題擺在這，以後有人有大膽想法時，減少踩坑。

用 iOS 捷徑把分享的連結或文字傳給筆記

在電腦上可以使用 Obsidian Web Clipper 瀏覽器擴充套件，把網頁內容存起來。
但是在 iPad 跟 iPhone 上就武功全廢，因為只是一個 PWA web app，不是真的 APP，所以選「分享」，APP 不會出現這個網頁筆記程式。

後來想到用蘋果系統強大的捷徑功能，拉一套 shortcut:

可以接收分享資料、詢問筆記名稱、把內容用 JSON 格式發到網頁程式去，再做一支網頁程式去接收資料，還要幫程式做個 log 介面，方便 debug。

實際使用大概像這樣

捷徑這邊也有不用不知道，一用嚇一跳的問題，例如在 Safari 把網頁連結分享到捷徑，跟在 Facebook 或其他 app 裡面把連結分享到捷徑，後者能拿到的東西少很多。

只能在捷徑多拉幾段流程，然後把接收分享資料的網頁程式裡面再好好設計一番，例如根據 URL 抓網頁標題&內文，是圖片就自動 OCR 擷取文字，標題如果是某一個字元，就自動用 AI 生筆記標題......之類的。

再講下去又要長篇大論了，就此打住。

結語

目前的版本長這樣，程式碼已經多到懶得 review 的地步了。

閒暇時就上去改改，或是丟幾個需求看 AI 會如何達成，連 Obsidian for Windows 原來的官方程式也越來越少用了。寫這篇的時候在想說塞一些處理圖片的相關功能上去。

還要寫什麼呢? 對了，vibe coding 的心得文通常都會說...這種東西以前找公司做要好幾萬塊，然後日後維護和修改的維護都是無底洞之類的，可惜我本來就是做這個的，沒辦法說這種幹話。

vibe-coding 好玩嗎? 好玩的可能是不用管成本，不用管別人怎麼想，做自己要用的東西，回到解決問題的初衷，而不是先考慮這件事划不划算，有什麼價值。碰到 AI 改不動，人類也不想接手的 code，就不好玩了。

本來是沒有要寫這篇的，覺得不會有人想要操作 GitHub API 當雲端空間，聽起來跟拿 Excel 當繪圖軟體、ChatGPT 對話紀錄用來記帳、npm 被用来保存盗版视频、GitHub issue 當成部落格或留言板之類的用法一樣好笑。

直到前幾天看到 Huli 大大曾想過 自己做一個筆記軟體出來......拿 git 當 storage 用，自用所以不用考慮多裝置衝突的問題......，糟了，得趕快阻止他。

他想的可能是自幹整套筆記軟體出來，我想的是自幹在行動裝置上使用的那部分。如果有人也想這樣玩的話，出發點很好，但是建議不要出發。除了本文的 GitHub API 限制，編輯器本身就是水很深的東西，可以挑其它在行動裝置上設計得更好的筆記服務。

像本文一開始吐槽的，學習筆記軟體如何操作這件事，這幾天看到 Notion 3.0 的 Agent 功能，以前要弄個某某資料管理系統研究老半天，現在只要跟 AI 對話，它就會自動把欄位開好、選擇的項目加上去，設定好資料關聯，設定好檢視功能和篩選器。

當然可能也跟 vibe-coding 一樣，如果有人真的不知道 Notion 有什麼功能，也不知道某某資料管理系統應該有什麼資料，從零開始製作時，提出的需求可能會亂七八糟。

然後在後續使用階段，當 Notion 放了滿滿的資料，人類敢隨便讓 AI 亂動整個資料庫結構嗎? 就不怕改一改之後某些欄位直接不見，還要想辦法復原?

prompt

能看到這裡真不簡單，文末提供這個網頁筆記最基本功能的 prompt，一些比較進階或個人化的部分沒寫，有需要的人可以拿回去，再延伸出 todo 跟 test 項目，讓 AI 開發一個偽 Obsidian 網頁版。

## Overview
- The core idea of this project is to provide a GitHub repo file reader, fully relying on a GitHub repository as the file storage backend.
- All file operations (create, read, update, delete) are done via the GitHub API, with commit records required.
- The functionality is a lightweight private note-taking web app, with authentication using ().
- Repo information, tokens, and API keys are loaded via ().
- Uses a single-page application (SPA) architecture with frontend-backend separation.
- Backend: written in (), using () framework, running on ().
- Authentication between frontend and backend uses (), with data format ().
- Project naming convention: ().

## Frontend Requirements
- Frontend: built with (), ensuring efficient development and excellent performance. Build method: ().
- Since this project is for private notes, add proper no-referrer and noindex configurations.
- Consider responsive design (RWD) for both desktop and mobile devices.
- Add PWA and apple-touch-icon settings to ensure icons display properly and the app runs when added to iOS/iPadOS home screen.
- As an SPA, no need to design routing to jump to specific pages or files.
- File and folder names may contain spaces, symbols, emojis, or Chinese characters — make sure encoding is handled correctly.
- Show a loading indicator after sending requests or fetching data to make progress clear.

## Feature Overview
### Login & Logout
- Authenticate with (), hide all content until the user is logged in. The following content is only visible after login.

### File Tree
- Display the repo directory structure and files, with subfolders collapsed by default.
- Prefer fetching the entire directory tree at once to avoid repeated API calls when expanding folders.
- Implement caching to avoid calling GitHub API every time. Provide a button to clear cache and reload the tree.

### Recent File Updates
- Fetch files modified in the past () days via GitHub API. Each item links to the file view.

### File Tabs Bar
- Since this runs in PWA fullscreen mode without browser navigation or tab tools, create a custom file tab bar.
- Each opened file shows as a tab. Tabs have equal width; long filenames truncated with CSS. Each tab has a close button. Duplicate tabs should be avoided.
- Save opened tabs using (), so they persist across sessions or devices.
- Switching tabs while editing should not affect other tabs’ editing states.

### Delete Notes
- Allow deleting files, with confirmation before deletion.

### Move Notes
- Move files to another folder via a modal showing the directory list.
- Check for duplicate filenames in the destination folder: if exists, ask to merge. Otherwise, copy content to new path and then delete the original.

### Create New Notes
- Use a modal to select the destination folder when creating a new note.

### Edit Notes
- Do not use modal windows or textarea to edit (to avoid multiple scrollbars). Use a `contenteditable` area to display raw Markdown. After saving, render it back to HTML.
- On iOS/iPadOS, symbol input is inconvenient. Provide a toolbar with quick Markdown buttons: H2, H3, ordered list, unordered list, quote, code block. Hitting Enter in a list should auto-generate a new list marker.

### View Notes
- Separate viewing mode and editing mode — don’t combine them.
- Notes are stored as Markdown strings; render them into HTML on the frontend. Even without `\n`, line breaks should display correctly.
- If the content includes raw HTML, display it as code instead of rendering it.
- Automatically detect and linkify URLs in the content.
- In the side panel, provide a collapsible and resizable TOC list automatically generated from H2 & H3 headings in the note.
- Convert Markdown image syntax to HTML img elements.
### GitHub API Status Panel
- Display API usage quotas and reset times.

### File Content Search
- Provide a modal for search interface and results.
- Use GitHub API to search file names and contents.
- Add folder filter to limit search scope.
- Add a checkbox for per-file matching. By default unchecked; when enabled, compare every file’s content against the keyword.
- Clicking a result should also open it in the file tab bar.

### Create Notes via iOS Shortcuts
- Accept POST requests with `content-type: application/json`.
- Fields: `title` (note name), `key` (for auth), `content`, `url`. Either `content` or `url` may be empty.
- Use GitHub API to create a new note in the root directory.
- Apply basic security: sanitize input strings. Respond with "success" or "failure".