CoBuild 憲章

前言

本文件是 HackIt 採用 CoBuild（共創制） 的正式運作憲章。採用本憲章後，組織內的正式權力來自本憲章，以及依本憲章產生的角色、圈子、政策、領域、紀錄與流程。

本憲章並非 HackIt 所有文化、政策與細節的完整集合。關於活動安全、未成年保護、財務規範、品牌使用、文件協作規範、志工培訓、贊助合作、對外溝通等其他實務細節，會由其他文件進一步定義。這些文件可以補充本憲章，但除非它們是依本憲章授權產生的正式政策，否則不得推翻本憲章。若其他文件與本憲章衝突，除非本憲章或上層政策另有規定，否則以本憲章為準。

HackIt 可以依本憲章定義的治理流程修改本憲章。任何修改都應被清楚記錄，包含版本、日期、修改內容、修改原因與採用方式，並讓受影響的夥伴能夠看見，也應盡到告知義務。

第一章：基本概念

1.1 組織

本憲章所稱的 「組織」，指 HackIt 及其依本憲章運作的專案、活動、團隊、平台、文件、社群與內部系統，包含但不限於長期運作的組織工作，也包含短期活動或一次性專案，例如一場黑客松、一個贊助合作計畫、一個內部工具、一場社群活動，或任何被 HackIt 正式承認的建造工作。

1.2 夥伴

「夥伴」 指被 HackIt 承認，並同意依本憲章參與 HackIt 運作的人。夥伴不一定是全職成員，也不代表他需要參與所有事情；成為夥伴的意思是，當他承接角色、參與圈子、提出治理變更、使用 HackIt 資源、代表 HackIt 行動，或參與 HackIt 內部協作時，他願意遵守本憲章，以及依本憲章產生的政策與紀錄。

HackIt 透過政策定義如何加入、暫停、恢復或移除夥伴身分。若尚未有相關政策，則由根圈暫時承接這項判斷與處理。

1.3 張力

「張力」 指的是：當一個人感覺到 HackIt 現在的狀態，與它可以變得更好的樣子之間存在落差時，那個落差就是張力。張力不等於抱怨，也不一定代表有人做錯；張力是組織進化的材料。

在 CoBuild 中，張力不應只停留在私下吐槽、情緒累積、群組抱怨或某個人的腦袋裡。當張力被感知到，它應該被處理成下一步行動、專案、請求、資訊同步、政策、角色調整、治理提案，或其他能讓組織向前的形式。

1.4 正式紀錄

「正式紀錄」 指 HackIt 依本憲章承認的角色、圈子、政策、領域、會議產出、治理決定、角色承接狀態與其他組織運作資料。

若正式紀錄與口頭說法衝突，以正式紀錄為準，除非該紀錄明顯過期、錯誤，或被書記依本憲章裁定為無效。若正式紀錄與現實長期不一致，相關角色或圈子應將其作為張力處理，而不是讓所有人繼續靠記憶、默契或私訊猜測。

1.5 高風險事項

本憲章所稱 「高風險事項」，指一項決定、行動、治理提案或臨時措施，可能對 HackIt 的安全、未成年保護、法律責任、品牌信任、財務責任、平台規則、個人資料、重要資產、管理權限或核心治理結構造成重大影響。

高風險事項至少包括：

• 修改 HackIt 的憲章、根圈政策、創辦人保留權、治理程序或重大權力結構
• 建立、修改或移除與安全、未成年保護、財務、品牌、法律、個資、平台規則或對外代表權有關的政策
• 任命、移除或長期空缺安全、財務、兒少保護、平台管理、資料保護、對外代表、書記、協調者、引導連接、代表連接等敏感角色
• 對 HackIt 平台、社群或活動參與者採取停權、封禁、移除、限制可見性、限制參與資格、限制管理權限等措施
• 使用公告式許可、非同步治理、個人倡議或創辦人保留權處理原本應透過正式治理、審查或升級程序處理的事項
• 任何可能使 HackIt 承擔未授權財務責任、法律責任、重大信任風險或未成年保護風險的行動

高風險事項不得只依一般默契、私訊共識、低可見度公告、臨時善意判斷或單一角色個人判斷處理。除非涉及立即安全、法律或兒少保護風險，否則高風險事項應透過正式治理、明確授權、書面紀錄、合理通知、必要覆核與可追溯程序處理。

第二章：角色

2.1 角色定義

「角色」 是 HackIt 分配工作、責任與權力的基本單位。一個人不是因為他比較像領導者、比較資深，或比較常出現在核心討論裡，就自動擁有某件事的決定權；一個人能夠代表 HackIt 在某個範圍內行動，是因為他承接了某個角色，而那個角色被賦予了相關宗旨、職責、領域或政策。意為權在角色而非在人身上，而角色是一組可以被承接、被調整、被移交、被拆解的工作結構。

一個角色至少應包含一個清楚的名稱，並可以包含 宗旨、領域、職責 與 政策。宗旨說明角色存在是為了實現或讓什麼事情變得可能（使命）；領域說明角色可以優先控制、管理的資源、流程、文件、系統或決策範圍；職責說明角色需要持續維護、推進或承接的工作；政策則是作用於該角色內部，或由該角色依授權建立的特殊規則。

2.2 角色承接者

承接某個角色的人，稱為該角色的 「角色承接者」。角色承接者有權在角色的宗旨、職責與領域範圍內行動與做決定；只要沒有違反本憲章、圈子政策、角色政策、領域限制、財務規範、安全政策或其他正式限制，角色承接者不需要先取得他人批准，才能推進該角色的工作。

同一個角色可以由多人共同承接。若一個角色由多人承接，該角色的所有角色承接者都可以代表該角色行動，除非角色定義、圈子政策、角色聚焦指派或其他正式分工另有規定。

2.3 角色承接者的責任

作為角色承接者，你有責任從你承接的角色出發，感知該角色宗旨與職責的實際狀態，並與你看見的更好可能性相比較。當兩者之間出現落差時，你有責任嘗試處理該張力。你可以透過行動、專案、請求、提案、治理變更、資訊同步或其他合適方式處理；你不需要處理所有人的所有張力，你主要處理的是你所承接角色能感知、能代表、能行動的張力。

角色承接者也有責任定期思考如何推進角色的宗旨與職責，並將工作整理為 下一步行動 與 專案。下一步行動是可以直接採取的具體動作；專案是需要多個行動才能完成的具體成果。專案應指向一個可被辨認的完成狀態，而不只是抽象願望。對於進行中的專案，角色承接者應定期定義至少一個可能推進它的下一步行動；若專案已經不重要、不適合、無法推進，或不再屬於該角色，也應處理這個狀態，而不是讓它死在清單裡。

角色承接者應以可被回顧的方式追蹤角色中的專案、下一步行動與重要張力。相關紀錄必須足夠清楚，同時讓需要協作的人在合理範圍內理解目前狀態。當角色承接者有時間為角色行動時，應在自己可用的時間、能力與情境下，選擇對角色與 HackIt 最有價值的下一步行動。

2.4 角色聚焦指派

「角色聚焦指派」 指引導連接將某個角色安排給特定的人承接時，將該承接限制在某個明確情境、範圍、活動、地區、語言、專案或時段中。使用角色聚焦指派時，整個角色定義仍必須在該焦點範圍內具有相關性；不能把一個角色切到只剩下完全不同的工作，卻仍然假裝它是同一個角色。

當角色被聚焦指派時，每一個聚焦指派都像一個獨立角色一樣運作。該角色的宗旨、職責、領域與政策仍然適用，但只在該指派焦點範圍內適用。若某個焦點範圍已經長期變成一組獨立工作，圈子應考慮是否需要建立新角色或子圈，而不是長期依賴聚焦指派。

2.5 角色承接安排

任何夥伴都可以感知並提出「某個角色需要有人承接」、「某個角色不適合繼續由目前的人承接」，或「某個角色需要被聚焦指派」的張力；但正式的角色承接安排，應由引導連接，或被政策授權的角色與流程處理。

引導連接可以在圈子中新增或移除角色承接者，也可以將角色聚焦指派給特定的人，使該角色只在某個明確的活動、專案、地區、語言、時段或其他範圍內被承接。任何人都不應被迫承接角色，除非該人已經透過正式協議承諾。

引導連接可以在緊急或短期空缺時安排臨時承接者，但臨時承接應不超過三十日，除非治理會議或相關政策另行確認。臨時承接者只能處理維持角色基本運作所需的事項，不得藉由臨時承接改變該角色的長期方向、重要政策、敏感資料存取範圍或重大權限配置。

當某個角色暫時無人承接時，引導連接可以協助維持最低限度的責任接續，但不得因此取得該角色所有權力。若空缺角色涉及高風險事項，引導連接應優先啟動臨時代理、公開徵求承接、治理調整或上層圈協助，而不是長期自行吸收該角色。

若角色承接安排出現爭議，相關夥伴應先判斷爭議屬於紀錄問題、流程問題、角色設計問題，還是安全、信任、利益衝突或根本邊界問題。紀錄問題由書記依本憲章處理；流程問題由協調者處理；角色設計問題應進入治理流程；安全、未成年保護、重大信任、財務責任、品牌風險等問題，則依本憲章的保護性介入與高風險事項規則處理。

第三章：圈子

3.1 圈子定義

「圈子」 是圍繞某個共同宗旨而組成的治理單位，用來把一組需要被共同治理的角色、領域與政策放在一起。圈子不是傳統部門，也不必然是小組；圈子的重點不在人數或組織層級，而在於讓相關的工作有一個共同的治理邊界。一個圈子的治理，由其角色與政策共同構成。圈子也包含了子圈、會議、治理紀錄、角色承接狀態與圈子策略。

3.2 圈子的形成

圈子可以由根圈、上層圈、既有角色，依政策與流程建立。圈子的形成可以是圍繞一個專案、一場活動、一段合作關係、一條長期工作流、一個平台、一個社群空間，或任何需要被共同治理的工作範圍而建立。

當某個角色的工作變得足夠複雜，需要更多角色、政策或分工時，該角色可以被展開為一個內部圈子。這種情況下，該圈子通常承接原本角色的宗旨，並成為持有該角色之圈子的子圈。持有該角色的圈子，稱為該子圈的上層圈。

當圈子是為了專案、活動、合作關係或其他工作範圍透過治理會議建立時，該圈子的宗旨、邊界、初始角色、引導連接、代表連接、協調者、書記與必要政策，應在正式創建時被記錄清楚。外部人士、新人或合作夥伴可以依政策參與圈子的工作或部分治理，但這不代表他們自動取得 HackIt 夥伴身分，或自動擁有超出該合作範圍的權力。

3.3 領域委託

「領域」 是某個圈子或角色被授權優先控制、管理或保護的範圍。領域可以是實體或數位資源、流程、文件、平台、品牌元素、預算、社群空間、資料庫、對外關係、決策邊界或其他重要資產。

當一個圈子將某個領域授予其角色時，該角色的角色承接者可以代表該圈子控制該領域。圈子只能將自己已經持有的領域、只與該圈子內部流程相關的領域，或上層圈與政策允許委託的領域授予其角色。

3.4 領域委託的優先規則

當圈子將領域委託給角色後，該角色可以在自己的治理範圍內建立管理該領域的政策。然而，委託該領域的圈子仍保留管理該領域的權力；若該圈子的政策與該角色的政策衝突，以委託該領域的圈子政策為優先。若多層圈子都對同一領域有政策，除非上層政策明確允許子圈覆寫，否則上層圈政策優先於子圈政策。

領域委託不代表財務支出權一併委託。除非政策或角色定義明確說明，否則獲得某個領域的角色，不因此自動取得花費該領域相關預算、資產或資源的權力，領域的目的，是讓責任、控制權與影響邊界更清楚。

3.5 領域委託程序

領域委託需要透過治理會議處理。當圈子希望將某個領域授予某個角色時，應由圈子成員提出治理提案，說明要委託的領域、承接該領域的角色，以及這項委託要處理的張力。若該領域並非由該圈子持有，或該圈子未被正式授權委託該領域，該提案不應被採用。

若領域委託提案通過，書記應將該領域正式記錄到對應角色中。從正式紀錄更新後，該角色即取得該領域的控制權；其他夥伴與角色應依正式紀錄理解該領域目前由誰承接，而不是依照口頭說法、過去習慣或私下默契判斷。

若未來需要修改、收回或重新委託該領域，也應再次透過治理會議處理，並由書記更新正式紀錄。領域委託不得只透過口頭、私訊或私下協議改變；若正式紀錄與實際運作不一致，相關夥伴應將其作為張力，透過治理流程修正。

3.6 連結進入圈子

「連結進入圈子」 指某個角色依另一個圈子或其上層圈的政策邀請，進入該圈子的治理範圍。這樣做的目的，是讓一個角色在不改變來源圈子的情況下，參與另一個圈子的治理，並協助處理跨圈子的張力。

例如，一個「安全政策」角色原本屬於根圈，但活動圈希望所有活動設計都能被安全角度檢視。這時活動圈可以透過政策邀請「安全政策」角色連結進入活動圈。連結後，安全政策角色仍然屬於原本的來源圈子，但它也會成為活動圈治理的一部分，活動圈可以在自己的治理範圍內，為這個角色增加與活動安全相關的職責、領域或政策。

角色連結進入某個圈子，不代表該角色被移到該圈子，也不代表目標圈子成為該角色的上層圈。接收該角色的圈子不得刪除該角色本身，不得修改該角色原本由來源圈子定義的內容，也不得修改或移除其他圈子為該角色增加的內容。目標圈子只能管理自己為該角色增加的部分。

3.7 連結進入圈子程序

連結進入圈子需要有明確政策作為依據。若某個圈子希望邀請外部角色連結進入，應透過治理流程建立政策，清楚定義哪些角色可以連結進入、連結的目的、適用範圍，以及該角色進入後可以參與哪些治理內容。沒有正式政策時，不應只靠口頭邀請、私訊共識或習慣，把某個外部角色視為圈子成員。

當角色依政策連結進入目標圈子後，該角色會成為目標圈子治理的一部分。目標圈子可以透過治理流程，為該角色增加職責、領域或政策；但這些新增內容只屬於目標圈子的治理範圍，不會改變該角色原本由來源圈子定義的宗旨、職責、領域與政策。

若未來需要解除連結，可以依目標圈子政策、來源圈子政策，或該角色本身的退出機制處理。解除連結後，目標圈子為該角色增加的內容應一併失效或移除；但該角色在來源圈子中的原始定義不受影響。若對某項內容到底屬於來源圈子、目標圈子或其他圈子產生爭議，應由書記依正式紀錄協助判斷。

3.8 引導連接

每個圈子都應有一個 「引導連接角色」，並由一位或多位夥伴承接成為該圈子的 「引導連接」。引導連接的存在，是為了將上層圈或根圈的宗旨、策略與需要連接到本圈子。

如果一個圈子是由某個角色展開而來，原本承接該角色的人，可以預設成為該圈子的引導連接，除非上層圈政策、角色定義或治理紀錄另有規定。如果一個圈子是為了專案、活動、平台、社群空間或其他工作範圍直接建立，則應在建立圈子時明確指定誰承接引導連接，或定義由哪個角色、政策或流程安排引導連接。

引導連接角色持有該圈子的整體宗旨，以及尚未被其他角色、政策或流程承接的職責。一旦某項職責、權力或領域已經被圈子透過治理流程放到其他角色、政策或流程中，引導連接就不應再以預設權力介入該事項。引導連接的作用不是把事情抓在自己手上，而是在空白尚未被治理清楚前，讓圈子不會失去方向或責任承接。

3.9 角色承接安排

引導連接預設可以安排圈子內一般角色由誰承接，也可以將同一角色安排給多人共同承接。但任何人都不應被迫承接角色，角色只能被安排給願意承接的人，除非該人已經透過其他正式協議承諾。

引導連接可以移除一般角色的承接安排，除非圈子政策或上層圈政策另有規定。圈子也可以透過政策，將角色承接安排交給其他角色或流程。一旦角色承接安排權被正式委託出去，引導連接就不應再以預設權力直接決定角色由誰承接。

若引導連接決定暫停或移除角色其承接者，應具備明確理由，並在合理範圍內留下紀錄，說明：

• 暫停或移除的原因
• 涉及的角色、權限與影響範圍
• 是否存在安全、兒少保護、財務、法律、利益衝突或重大信任風險
• 臨時承接安排
• 後續應回到哪個治理或覆核流程處理

若移除或暫停涉及敏感角色、重大權限或可能影響當事人聲譽，應避免在公開頻道揭露不必要細節，並依最小知悉原則處理相關資訊。

3.10 未被承接角色的覆蓋

當圈子中的某個角色無人承接時，每位引導連接會自動被視為該未承接角色的角色承接者。當某個角色只由非 HackIt 夥伴的人承接時，每位引導連接也會自動被視為該角色的角色承接者，但這個預設只適用於非夥伴沒有實際履行相關責任的範圍。

若某個角色空缺超過三十日，書記應將其標記為「長期空缺」。長期空缺應被視為治理張力處理。圈子應決定是否：

• 尋找正式承接者
• 建立臨時代理池
• 調整角色定義
• 拆分或合併角色
• 將責任委託給其他角色或流程
• 暫停或移除該角色

若空缺角色屬於高風險角色，空缺不得只由引導連接長期覆蓋。圈子應在合理期限內安排正式承接、代理、治理調整或上層圈協助；在此之前，任何敏感行動都應採取最小必要原則。

3.11 優先順序與策略

引導連接可以判斷圈子中不同潛在工作之間的相對價值，以協助解決跨角色的優先順序衝突。引導連接也可以為圈子定義一項或多項 「策略」。策略不是細部命令，而是協助角色排序工作的判斷原則。角色承接者在選擇工作時，應將圈子的正式策略視為比個人偏好更高的排序依據。

3.12 外部引用導向

當圈子外部的治理內容、政策、請求或正式文件引用某個圈子本身，或引用該圈子中的某個角色時，引導連接可以將該引用導向圈子內另一個更合適的角色。這種導向不被視為該圈子的治理變更。這項權力的目的，是避免外部請求停在圈子名稱或過時角色上，而是能被導向真正適合承接的角色。

3.13 引導連接角色不可被移除

圈子不得移除自己的引導連接角色，也不得修改該角色的核心宗旨。每個圈子都需要有一個最低限度的預設連接機制，確保當某些職責尚未被分配、角色暫時空缺，或圈子內部結構還不完整時，仍有人可以暫時接住整理、導向與連接工作。

圈子可以透過治理流程，將引導連接的部分權力委託給其他角色、政策或流程。只要委託仍然有效，引導連接就不再保留該部分權力。

3.14 新增到引導連接角色的內容

圈子可以為自己的引導連接角色增加職責或領域，也可以移除這些新增內容。但是，任何新增到引導連接角色的職責或領域，會自動遞迴適用於所有子圈的引導連接角色，除非政策明確限制其適用範圍，且該限制不違反上層圈治理。

圈子不得只為自己的引導連接角色增加某項只在本圈內有效、但不適合套用到子圈的職責。若某項工作只屬於本圈，應建立一般角色或政策，而不是塞進引導連接角色。這項規則的目的，是避免每個圈子偷偷把引導連接變成不同形式的主管。

3.15 敏感角色

圈子可以透過政策將特定角色列為 「敏感角色」。若尚未有相關政策，凡涉及安全、未成年保護、財務、法律、資料保護、平台管理、對外代表、品牌信任、治理紀錄、會議流程或重大權限配置的角色，預設視為敏感角色。

敏感角色應盡量具備以下安排：

• 明確的承接資格或最低訓練要求
• 明確任期或重新確認週期
• 清楚的權限範圍
• 利益衝突迴避規則
• 臨時代理機制
• 移除、暫停或替換程序
• 正式紀錄與必要覆核

敏感角色不得因為「目前沒有人做」、「大家都信任某個人」、「他比較核心」、「他是創辦人或引導連接」而長期繞過正式安排。若某人同時承接多個敏感角色，圈子應定期檢查是否造成權力過度集中、審查與被審查者重疊、紀錄與決策混同，或其他利益衝突。

第四章：根圈與創辦人

4.1 根圈

「根圈」 是 HackIt 最外層、承接整個組織宗旨的圈子。根圈沒有上層圈，並持有 HackIt 作為整體組織所擁有、但尚未委託給其他圈子、角色、政策或流程的正式權力與領域。

根圈可以定義 HackIt 的組織宗旨、核心政策、主要圈子、根本領域、初始角色，以及 CoBuild 的基本運作規則。根圈不是最高主管群，也不是所有事情的最終審批處；根圈的存在，是為了讓 HackIt 的整體方向、制度邊界、品牌信任、法律責任、安全底線與跨圈子張力，有一個正式承接處。

除非本憲章、根圈政策或創辦人保留權另有規定，根圈是 HackIt 最終處理組織層級張力的地方。適合進入根圈治理的事項，應涉及整個 HackIt、多個圈子、組織宗旨、核心政策、根本領域、安全邊界、品牌信任、法律責任或跨圈子權力結構；若某項張力只涉及單一角色的日常判斷、單一圈子的內部安排，或已被其他正式角色承接的工作，則不應放入根圈治理。

當某項權力已被根圈透過治理流程明確委託出去，根圈不應用口頭指令、私下共識或臨時判斷取代被授權圈子與角色的權力；若需要調整授權，應再次透過治理流程處理。根圈治理結果應由書記更新正式紀錄，並清楚標示變更內容、生效範圍、受影響的圈子或角色，以及必要的後續調整。

4.2 根圈與其他圈子的關係

根圈可以透過治理流程建立子圈、授予領域、制定政策，並將權力委託給其他圈子、角色、政策或流程。被委託權力的圈子與角色，應在授權範圍內自主行動，不需要在每一件事情上向根圈請求批准。

若根圈政策與下層圈政策衝突，除非根圈政策明確允許下層圈覆寫，否則以根圈政策為優先。若下層圈認為根圈政策造成限制，應透過代表連接、治理提案或其他正式流程，將張力帶回根圈處理。

根圈應避免處理單一角色或下層圈可以自行處理的日常工作。只有當張力影響整個 HackIt、多個圈子、組織宗旨、核心政策、根本領域、安全邊界、品牌信任、法律責任或跨圈子權力結構時，才應進入根圈治理。

4.3 創辦人與創辦人保留權

「創辦人」 指 HackIt 的創辦人，或由創辦人以書面形式指定承接其權利與責任的人。創辦人並非根圈的上層圈，也不是 HackIt 的最高主管；創辦人角色本身，不讓任何具體工作自動成為命令。

創辦人的存在，是為了保護 HackIt 的初始使命、品牌信任、根本資產、法律責任、安全底線、未成年保護與長期完整性。這些權利稱為 「創辦人保留權」。創辦人保留權只適用於 HackIt 的根本邊界，不應用於一般治理爭議、日常工作分歧、角色判斷，或創辦人個人偏好的實現。

創辦人可以保留採用、修訂或廢止本憲章的根本權利。當某項治理決定明顯違反 HackIt 使命、安全政策、未成年保護、法律要求、品牌信任、重大資產邊界，或可能使 HackIt 偏離其根本存在理由時，創辦人可以提出暫停、要求復核，或在必要時否決該治理決定。

創辦人行使保留權時，應留下正式紀錄，說明介入事項、依據的根本邊界、影響範圍，以及後續應回到哪個角色、圈子或治理流程處理。除非涉及立即安全、法律、未成年保護或重大資產風險，創辦人不應用口頭指令、私訊或臨時判斷取代正式流程。

若創辦人希望推進某項具體工作，應與其他夥伴一樣，透過承接角色、提出治理提案、處理張力、提出請求或參與正式流程來行動。

第五章：代表連接、協調者與書記

5.1 代表連接

任何圈子成員都可以請求舉行選舉，以選出或替換該圈子的 「代表連接」。代表連接的目的，是協助將該圈子中適合在上層圈處理的張力帶出去，並在更大的治理範圍中代表該圈子。

代表連接角色的宗旨是：將適合在更大圈子中處理的張力導出，並協助移除對本圈子的限制。 代表連接的職責包括理解圈子內角色承接者所感知的張力，辨識哪些張力適合在上層圈或更大圈子中處理，在上層圈中處理張力，以移除對本圈子的限制，並協助本圈子的聲音不只透過引導連接被代表。

5.2 代表連接的限制

代表連接必須由該圈子的圈子成員擔任，除非上層圈或本圈政策另有規定。擔任引導連接的人，不得同時擔任同一圈子的代表連接。除非包含該圈子的上層圈政策允許，否則同一時間不得有超過一人擔任某圈子的代表連接。代表連接並非主管，也不是專門反對引導連接的人，代表連接的作用，是讓圈子的張力有一條往外處理的正式通道。

5.3 代表連接進入上層圈

被選出的代表連接，會成為直接包含該圈子的上層圈之圈子成員，並有權在該上層圈中代表本圈子。上層圈可以透過政策限制或阻止子圈代表連接成為其圈子成員，但前提是子圈仍有另一種方式，在該上層圈中享有相當的代表性。

5.4 協調者

每個圈子都應設有 「協調者」 角色。協調者的宗旨是：讓圈子的治理、會議與運作流程符合本憲章，並協助圈子在不依賴情緒拉扯或權力壓制的情況下處理張力。

協調者負責協調治理會議，並在圈子政策未另行安排時協調戰術會議。協調者應維護會議流程與發言邊界，測試提案與反對是否符合標準，在必要時提醒圈子回到本憲章，並在流程失效時協助恢復正當流程。協調者不是裁判一切對錯的人；協調者主要保護流程，而不是替圈子做決定。

5.5 書記

每個圈子都應設有 「書記」 角色。書記的宗旨是：維護圈子的正式紀錄，讓角色、政策、領域、會議產出與治理變更可以被查閱、引用與信任。

書記負責記錄治理會議通過的內容，發布治理變更與必要會議紀錄，維護圈子的正式治理紀錄，並管理圈子允許使用的治理提案提交管道。當夥伴對本憲章、圈子政策或治理紀錄的文字有疑問時，書記可以依正式紀錄協助解釋。書記保護的是圈子的正式記憶，讓重要決定不只存在於某個人的腦中、私訊裡或模糊印象中，而是能被所有有權查閱的人確認。

5.6 書記的解釋與紀錄裁定

任何受影響的夥伴，都可以請求相關圈子的書記解釋本憲章、圈子政策或正式紀錄的適用方式。書記應依正式文字、治理紀錄、角色定義與圈子宗旨作出解釋，不得依個人偏好、私下默契或未被記錄的共識裁定。

書記的主要權力是維護正式紀錄的清楚、完整、可追溯與一致性。書記不得透過紀錄解釋創造新的角色、權力、政策、治理結果或實質決策，也不得以紀錄權取代治理權。

若某項治理內容是否有效、是否超出權限，或是否與本憲章、政策、角色定義或既有紀錄衝突產生疑問，書記可以作出初步紀錄判斷。除非屬於明顯錯字、格式錯誤、重複紀錄、引用錯誤或其他純技術性錯誤，書記不得單方面永久移除、改寫或使具爭議的治理結果失效。

當書記認為某項紀錄可能無效、超出權限或違反本憲章時，應優先採取以下程序：

• 將該項內容標記為「爭議紀錄」或「待覆核紀錄」
• 說明疑義、依據與可能影響範圍
• 通知受影響的角色、提案人與相關圈子成員
• 在必要時暫停該紀錄的新生效力，但不得抹除歷史紀錄
• 將爭議提交上層圈書記、指定覆核角色或治理流程處理

若爭議紀錄涉及安全、未成年保護、法律、財務、品牌、個資或重大治理權限，書記可以採取臨時保護標記，使相關行動暫緩生效；但該標記應在七日內進入覆核或治理處理。若七日內無法處理，應公開說明延長理由與預計處理方式。

受影響夥伴若不同意書記的解釋、爭議標記或初步判斷，可以提交上層圈書記重新判斷。上層圈書記可以維持、修正或推翻原判斷。若爭議涉及根圈、創辦人保留權或書記本人利益衝突，應由根圈指定無利益衝突的覆核者處理。

書記應保留爭議紀錄、裁定理由、覆核結果與修改歷史。正式紀錄的可信度，不只來自「最後留下什麼」，也來自「為什麼改、誰改、何時改、依什麼程序改」。

5.7 協調者與書記的代理人

當協調者或書記角色無人承接，或通常承接該角色的人在需要時無法出席、無法處理、請求他人代行，或存在利益衝突時，可以由代理人暫時代行。代理人依以下優先順序產生：由被代理者指定的人；若需要代理協調者，則由該圈子的書記代理；若需要代理書記，則由該圈子的協調者代理；若前述皆不可行，則由該圈子的引導連接代理；若仍不可行，則由第一位宣告自己擔任代理人的圈子成員代理。

代理人只在必要期間代行相關功能。代理人不得利用代行身分擴張原角色不具有的權力。

第六章：合作規則

6.1 透明義務

作為 HackIt 夥伴，當其他角色承接者基於角色需要向你請求資訊時，你應在合理範圍內提供透明資訊。這些資訊可能包括你正在追蹤的專案與下一步行動、你對某件事優先順序的判斷、你對完成時間的粗略預估、你負責的週期性工作是否完成、你掌握的指標、進度或狀態，以及你已經知道且分享後不會造成明顯傷害的其他資訊。

透明義務不表示任何人可以要求你交出所有私人訊息、情緒狀態、個人生活細節或與角色無關的資訊。CoBuild 要求的是與角色工作有關的透明，而不是對人的全面監控。

6.2 處理義務

當其他角色承接者向你的角色提出請求時，你應及時處理。及時不代表立刻，也不代表永遠秒回；但不應長期不讀、不回、不處理，讓協作卡在一個人身上。

請求可能包括請你釐清某件事的下一步、請你承接某個專案或行動、請你允許他影響你角色控制的領域，或請你提供某項資訊或判斷。你可以接受請求，也可以拒絕請求；但如果你拒絕，應提供足夠清楚的理由，或提出你認為更合適的替代方式。

6.3 優先順序義務

HackIt 的夥伴在承接角色時，應考量該角色、該圈子與其上層圈所定義的正式優先事項。正式優先事項可以來自圈子策略、角色職責、治理政策、專案目標、被授權角色所做出的排序判斷，或上層圈正式指定的優先方向。

當你選擇以 HackIt 的角色行動時，你不應只根據個人喜好決定什麼重要，而應尊重該角色所處圈子的正式方向。

6.4 不建議使用硬性 Deadline

HackIt 原則上不鼓勵在內部協作中使用硬性的 deadline 作為管理工具。CoBuild 更適合使用 目標日期、期望完成時間、外部約束 或 優先順序提示，而不是把某個日期寫成「無論如何都必須完成」的命令。

如果某個日期來自真實外部限制，例如活動開始時間、場地方要求、贊助合約、報名系統開放日、政府或學校文件期限，則可以記錄為 外部約束日期。但即使如此，它也不代表任何人必須犧牲健康、學業、安全、生活或基本判斷去完成它；它只代表為了面對該外部限制，相關行動應被提高優先順序，並及早處理範圍縮小、支援請求、目標調整或替代方案。

若某個日期已經不合理，角色承接者應處理這個張力，而不是假裝它不存在。處理方式可以是重新排序、縮小範圍、請求支援、調整目標、提出替代方案，或提出治理變更。

6.5 關係協議

HackIt 的夥伴之間可以建立 「關係協議」。關係協議是關於彼此如何一起工作的具體約定，例如溝通頻率、訊息格式、回饋方式、會議互動方式，或某些行為邊界。關係協議不能取代角色職責，也不能偷偷創造一個不在治理紀錄裡的權力結構；它只能用來讓人與人之間的協作更清楚、更舒服、更可預期。

關係協議應具體、可執行、可終止。不適合作為關係協議的例子包括「你要更積極」、「你要更有責任感」、「你要像 Lead 一樣成熟」或「你要更像核心成員」。更適合作為關係協議的例子包括「每週日前更新一次專案狀態」、「無法出席會議時，提前在指定頻道告知」、「需要修改我負責的文件時，先在文件留言，而不是直接重寫整段」。

6.6 青少年與成人協作邊界

HackIt 是以青少年為核心的組織。當成人志工、導師、講者、合作夥伴或其他外部人士參與 HackIt 時，必須遵守 HackIt 的安全政策與協作邊界。CoBuild 不會因為強調分散式權力，而取消對未成年人的保護。任何角色、政策、支出授權、對外合作或個人倡議，都不得凌駕於安全、法律與未成年保護政策之上。若角色權力與安全政策發生衝突，以安全政策為優先。

第七章：分散式權力

7.1 角色內的行動權

作為角色承接者，只要沒有違反本憲章、圈子政策、角色政策、領域限制、財務規範、安全政策或法律要求，你有權採取任何合理行動，以推進角色宗旨與職責。你不需要因為「怕被說越權」而停在原地。CoBuild 的基本假設是：如果某件事落在你的角色裡，你就有權處理它；如果它不清楚，就把不清楚本身作為張力處理。

7.2 不得違反政策

角色承接者在角色中行動時，不得違反作用於該角色的政策。這些政策可能來自角色本身、所在圈子、上層圈、根圈，或 HackIt 的安全、財務、品牌、法律與未成年保護相關文件。

7.3 影響領域前取得許可

如果某個領域已被授予某個角色或圈子，其他角色在實質影響該領域前，應先取得控制該領域者的許可，除非相關政策允許例外。若影響是容易撤回、風險很低，且不會妨礙該角色實踐宗旨與職責，領域控制者應傾向允許；若影響會難以撤回、造成明顯成本、破壞信任、影響安全，或改變該領域的實質狀態，則領域控制者應更慎重地評估該行動的必要性與後果，並可要求調整方案、設定條件，或在疑慮被處理前暫緩允許。

7.4 公告式許可程序

當某個行動可能影響他人的領域、資源或工作範圍，但又不值得開治理會議時，角色承接者可以使用 「公告式許可」：將打算做的具體行動公開說清楚，並給可能受影響的人一段合理時間提出反對。

公告式許可不是請大家批准，而是讓相關夥伴有機會阻止明顯有問題的低風險行動。公告式許可只適用於低風險、可逆、影響範圍有限，且不會造成重大權利、信任、安全、財務、法律、兒少保護、資料保護或治理結構影響的事項。

以下事項不得使用公告式許可取得授權：

• 修改憲章、根圈政策、治理流程或重大權力結構
• 建立、修改或移除安全、未成年保護、財務、法律、品牌、個資、平台規則或對外代表權政策
• 任命、移除、暫停或重新配置敏感角色
• 取得、擴張或移除平台管理權限、資料存取權限或財務權限
• 對外代表 HackIt 作出合作、付款、贊助、合約、聲明或重大承諾
• 影響未成年參與者安全、成人與青少年互動邊界、兒少保護流程或敏感事件處理
• 處理檢舉、申訴、停權、封禁、黑名單、內部紀律或重大信任事件
• 任何一旦執行後難以回復、會造成明顯成本、或可能破壞信任的事項

公告式許可的公告必須具體說明：

• 行動者代表哪個角色
• 打算做什麼
• 影響哪個領域、資源、文件、系統或角色
• 為什麼這件事需要使用公告式許可（為何不等到治理會議）
• 預計何時執行
• 反對期限（需為“合理期間”）

公告應發布在該圈子正式指定且足夠可見的位置。不得將公告藏在低可見度頻道、私人訊息、臨時群組、口頭說明或不易搜尋的訊息流中。若公告影響特定角色或領域控制者，行動者應主動通知該角色或領域控制者，而不是只等待對方偶然看到。

若合理時間內無人提出有效反對，該行動取得限定許可。這項許可只適用於公告中的具體行動，不會變成永久權力，也不會授權其他類似行動。若事後發現該事項不適合使用公告式許可，相關角色或書記可以要求暫停、回復、補正紀錄或提交治理處理。

7.5 支出授權

任何 HackIt 夥伴不得代表 HackIt 支出金錢、處分資產、承諾付款，或對外做出會造成財務責任的承諾，除非已依正式政策取得授權，且該支出有可用的預算或資源來源。

支出授權應主要由政策定義。相關政策可以規定誰控制哪一筆預算或資源、哪些支出可以自行決定、哪些支出需要公告或事前同意、金額上限、升級方式、報帳要求與紀錄方式。控制某個領域、資源或預算池，不代表可以無限制花錢；除非政策或角色定義明確授權，否則不得代表 HackIt 支出或承諾付款。

若沒有更明確的政策，夥伴在支出前應先確認該預算或資源由誰控制，並公開說明支出原因、金額、項目、目的、預算來源，以及自己代表哪個角色提出。若有人提出升級，支出應暫停，直到升級被解除。若合理時間內沒有有效升級，該次支出取得限定授權，但只適用於公告中的目的、金額與情境。

7.6 圈子預算池

每個圈子可以依根圈、上層圈或相關政策，被配置一個或多個 「預算池」。預算池是該圈子在授權範圍內可以調用的財務資源，用來支持該圈子的宗旨、角色、專案、活動與日常運作。

圈子只能在自己的預算池可用額度內支出。若某項支出超出該圈子的預算池、預算池沒有足夠金額，或該支出不符合預算池用途，即使理由合理，也不得直接動用 HackIt 資金。

若圈子需要超出自身預算池的資源，應依政策向上層圈、根圈或相關預算控制角色提出申請。上層圈或根圈可以透過政策定義預算分配、追加、轉移、審查與升級方式。所有預算調整與支出紀錄，都應依正式財務政策保存。

7.7 對外代表權

任何人代表 HackIt 對外溝通、承諾合作、簽署文件、接受贊助、發布正式聲明或使用 HackIt 品牌時，必須依照相關角色與政策行動。「我是 HackIt 的人」不自動代表「我可以代表 HackIt 對外承諾」。對外代表權必須來自角色、政策或明確授權。

7.8 個人倡議

在少數情況下，夥伴可以採取「個人倡議」，也就是在尚未取得完整授權，或超出原角色邊界的情況下，為了避免 HackIt 遭受明顯且即將發生的重大損害，或為了保存即將流失的重要價值，而先行採取有限行動。

個人倡議是例外機制，不是一般授權方式。只有在以下條件全部成立時，個人倡議才被允許：

• 行動者是出於善意，並且是為了服務 HackIt 或某個角色的宗旨
• 行動者合理相信不行動會造成更大的張力、損失或風險
• 等待正式流程會使重要價值明顯流失，或使損害無法及時避免
• 行動採取的是最小必要範圍
• 行動不會讓 HackIt 承擔未授權的財務責任
• 行動不會違反安全、法律、未成年保護、資料保護、重大信任或核心資產邊界
• 行動者願意承接事後說明、修復、轉交、紀錄與覆核責任，以及處理任何後續產生的新張力

個人倡議不得用於以下事項

• 繞過治理程序修改角色、政策、領域、圈子或正式權力結構
• 繞過支出授權、對外代表授權或合約授權
• 取得或擴張敏感資料、平台管理、財務、兒少保護或安全事件處理權限
• 對他人作出長期停權、封禁、移除資格、公開指控或重大名譽影響
• 處理與行動者存在利益衝突的事件
• 讓 HackIt 承擔不可逆或難以修復的重大後果

採取個人倡議後，行動者應在二十四小時內完成正式報備。報備至少應包含：

• 自己做了什麼
• 為什麼不能等待正式流程
• 服務了哪個角色、圈子或宗旨
• 影響了哪些人、角色、領域、資源或紀錄
• 是否涉及安全、兒少保護、法律、財務、品牌、個資或敏感權限
• 行動是否可逆
• 需要誰接手、修復、確認或覆核

個人倡議應在七十二小時內進入覆核。覆核可以由受影響角色、圈子、書記、協調者、上層圈或被政策指定的角色處理。覆核結果應至少判斷：

• 該行動是否符合個人倡議條件
• 是否需要維持、修改、撤回或修復
• 是否需要補充治理、政策或正式授權
• 是否存在濫用、越權或利益衝突
• 是否需要更新正式紀錄

若個人倡議未在二十四小時內報備，或未在七十二小時內進入覆核，該行動不得被視為已取得正式授權。相關角色應視情況暫停、撤回、修復或重新提交正式流程處理。

個人倡議若造成損害，行動者有責任協助修復，但這不代表行動者必然受到懲罰。CoBuild 鼓勵善意行動，但善意不能取代程序、授權、紀錄與責任。

第八章：政策

8.1 政策定義

「政策」 是依本憲章產生的正式規則，用來授予權力、限制權力、定義流程，或改變本憲章允許被改變的預設規則。政策一旦有效，就會對其作用範圍內的角色與圈子產生正式約束力。

8.2 政策範圍的精確定義

一項政策只能包含以下一項或多項內容：

• 限制圈子內一個或多個角色的權力
• 將圈子或引導連接持有的某項權力授予一個或多個角色
• 允許原本未被授權的人或角色控制或影響圈子的某個領域，或限制原本已被授權的人如何影響該領域
• 改變本憲章中的某項預設規則或流程，但前提是本憲章明確允許該規則或流程被政策修改
• 定義某個圈子、會議、選舉、角色承接、文件存取、預算使用或決策流程的參與資格與條件
• 或定義某類工作、文件、支出、對外溝通、安全處理或活動流程必須符合的最低標準

政策不能用來直接指定某個人必須完成某個一次性任務，不能替代角色的日常工作判斷，不能做出不屬於治理範圍的營運決定，不能要求某人展現抽象人格特質，不能在未授權情況下推翻上層圈政策，也不能使角色權力變得比政策文字更模糊。

8.3 政策的遞迴適用

授予或限制權力的政策，會遞迴適用於所有子圈，除非政策明確說明不適用。改變本憲章預設規則或流程的政策，預設只適用於持有該政策的圈子；若政策明確說明遞迴適用於子圈，則會套用到所有子圈；上層政策僅在上層圈政策允許子圈覆寫時，子圈才可透過自己的政策覆寫。

8.4 政策與角色職責的差異

角色職責定義的是某個角色需要持續承接的工作；政策定義的是權力、限制、流程或規則。如果一段文字是在說「誰要持續做什麼」，它通常應該是角色職責。如果一段文字是在說「誰可以或不可以做什麼」、「做之前需要什麼條件」、「流程如何運作」，它應是政策。

第九章：治理與治理會議

9.1 治理是什麼

「治理」 指的是修改圈子的正式結構。只要一件事會改變角色、職責、領域、政策、子圈、圈子邊界、選舉角色，或其他正式權力安排，它就屬於治理。治理處理的是「組織如何被設計」，不是「今天某件工作要怎麼做」。

例如，新增一個「社群溝通」角色、把「報名系統」領域委託給某個角色、建立一條 Discord 私訊政策、把一場活動整理成活動圈、選出協調者、書記或代表連接，這些都屬於治理。相反地，某張海報要用哪個版本、今天要先回哪封信、活動現場桌椅怎麼擺、某篇文案要怎麼寫，通常不屬於治理；這些應由相關角色在自己的權限內處理。

治理的目的是讓 HackIt 的角色、權力與邊界可以隨著真實張力被調整。當現有角色或政策不夠清楚、不夠合適，或讓工作卡住時，夥伴可以透過治理提案修改組織本身。

9.2 誰可以參與治理

每個圈子的治理，原則上由該圈子的 圈子成員 參與。圈子成員包括該圈子的引導連接、圈子內各角色的角色承接者、代表連接，以及依政策被允許參與治理的其他夥伴或角色。

若某個角色由多人共同承接，圈子可以透過政策定義哪些人代表該角色參與治理。若沒有相關政策，則所有角色承接者都可以參與治理；但如果人數過多，圈子應透過政策整理參與方式，避免治理變成混亂討論。

代表連接可以將下層圈的張力帶入上層圈治理。這不代表代表連接比其他人更高位，而是讓下層圈有一條正式通道，能把需要上層圈處理的限制、衝突或政策問題帶出去。

9.3 什麼時候應該提出治理提案

當你感覺某件事不是單靠行動、請求、溝通或戰術會議就能解決，而是需要改變角色、政策、領域或圈子結構時，就應該考慮提出治理提案。

治理提案通常來自這些情境：

• 某件工作一直沒人承接，需要新增角色
• 某個角色太模糊，需要調整職責
• 某個資源一直被多人混用，需要設定領域
• 某個行為反覆造成問題，需要建立政策
• 某個工作範圍變大，需要成立圈子
• 某個圈子沒有清楚代表，需要選出代表連接
• 某個流程一直卡住，需要修改正式規則。

9.4 治理提案應該包含什麼

一個治理提案應該盡量清楚寫出三件事：第一，這個提案要處理什麼張力；第二，它要修改哪一段正式紀錄；第三，修改後的文字或結構會變成什麼。

提案不需要一開始就完美，但不能只有抽象想法。例如「我們需要更重視安全」還不算清楚的治理提案；比較清楚的寫法是：「在活動圈新增一條『安全回報』政策，規定所有現場安全事件都必須被記錄到指定表單，並由安全角色在活動結束後整理回顧。」這樣圈子才知道要處理的不是一種感覺，而是一個具體的治理變更。

提案人不需要證明所有人都會喜歡這個提案，也不需要事先說服所有人。提案人只需要說明：這個提案處理了什麼張力，以及它如何改變正式結構。治理會議的目的，是讓這個提案被快速檢查、修正、整合，並在沒有有效反對時前進。

9.5 治理會議的目的

治理會議 是圈子用來即時處理治理提案的會議。治理會議不處理一般日常工作，它只處理修改圈子的正式治理紀錄。治理會議中可以新增、修改或移除角色，可以建立或調整政策，可以授予、收回或重新委託領域，可以建立子圈，可以選出協調者、書記、代表連接或其他選舉角色，也可以處理其他屬於治理範圍的變更。

治理會議不是靠共識決，也不是靠投票決。治理會議的基本原則是：不是所有人都同意才可以做，而是沒有有效反對就可以前進。

9.6 治理會議的基本流程

治理會議由協調者維護流程，由書記記錄正式結果。除非圈子政策另有規定，治理會議依以下順序進行。

第一，簽到輪。 每位參與者分享自己目前、近期的狀態，等待所有人到齊，在這一輪暫不處理任何議題。

第二，建立議程。 每位參與者可以提出自己想處理的張力，只需要給一個簡短標籤（而非攏長的描述），例如「報名系統權限」、「新增安全角色」、「Discord 公告政策」。此時不解釋、不討論、不提前處理。

第三，選擇議程。 協調者依序處理議程。若是特別治理會議，則依該會議的指定範圍處理。若有人提出選舉議程，協調者可以依本憲章規則優先處理。

第四，呈現提案。 輪到某個議程時，請提案人說明張力，並提出具體治理提案。提案應說明要改什麼、加什麼、移除什麼，或要如何調整正式紀錄。

第五，釐清問題。 其他參與者可以問問題，幫助自己理解提案。提案人可以回答，也可以說「尚不清楚」或「這不是我提案的一部分」。這一階段不能表達意見、建議或反對（提出的問題僅是幫助獲取更多資訊、釐清問題）。

第六，反應輪。 除提案人外，每位參與者依序分享對提案的反應。這一輪可以表述擔心、支持、建議或感受，但不能互相回應、辯論或說服，需依序一次一人進行。

第七，提案人修正。 提案人可以根據剛剛聽到的反應修改提案，也可以不修改。這一階段由提案人決定是否調整，其他人不再討論。

第八，反對輪。 協調者依序詢問每位參與者是否有正式反對。反對必須符合本章的反對標準；不喜歡、不習慣、覺得還可以更好，通常不構成反對。

第九，整合。 如果有有效反對，提案人、反對者與協調者一起尋找修正方式，讓提案仍然處理原本張力，同時避免反對指出可能造成的其他張力。整合完成後，回到反對輪。

第十，通過與記錄。 當沒有有效反對時，提案通過。書記更新正式紀錄，並清楚標示變更內容、生效範圍與必要後續事項。

9.7 什麼是有效反對

反對不是不同意。 反對也不是「我不喜歡」、「我覺得怪」、「我有另一個更好的想法」。在治理會議中，反對是一種保護機制，用來指出：如果這個提案通過，會對某個角色、圈子或 HackIt 的能力造成實質張力，而且這個張力不是可以安全嘗試後再修正的小問題。

一項反對通常需要同時說明四件事：

• 第一，這個提案會如何降低圈子實踐宗旨或職責的能力
• 第二，它會如何限制反對者所代表角色的工作能力
• 第三，這個問題是提案造成的新問題，而不是原本就存在的問題
• 第四，如果先通過再觀察，圈子是否來不及在傷害發生前修正。

如果提案明顯違反本憲章、正式政策、安全規範、未成年保護要求、財務限制或法律要求，也可以構成反對。這類反對不需要包裝成個人感受，而應直接指出它違反了哪一項正式限制。

9.8 反對如何被測試

當有人提出反對時，協調者應協助測試它是否有效。協調者不是判斷自己同不同意，而是判斷這個反對是否符合規則。

協調者可以依序詢問：這個提案會造成什麼具體傷害？它會影響你代表的哪個角色？這個傷害是提案造成的，還是原本就存在？如果先試行，圈子是否還有足夠機會在傷害發生前修正？它是否違反本憲章或正式政策？

如果反對無法通過測試，協調者可以駁回該反對，並繼續流程。如果反對有效，圈子應進入整合，而不是進行投票或長時間辯論。

9.9 整合怎麼進行

整合的目的不是讓所有人都滿意，而是讓提案可以安全前進。有效的整合，必須同時保留提案人要處理的原始張力，並處理反對者指出的實質傷害。

整合時，協調者應避免讓討論散開。一次只處理一個反對，並聚焦在「怎麼修改提案，才能讓這個反對不再成立」。如果修改後的提案已經無法處理提案人的張力，該整合就不成立；如果修改後仍然造成反對者指出的傷害，該整合也不成立。

當提案人確認修正後仍能處理原張力，且反對者確認原本的反對不再成立，該反對即被視為解決。之後協調者應回到反對輪，確認是否還有新的有效反對。

9.10 治理會議的通知與出席

圈子只有在書記已合理提前通知所有圈子成員時，才可以舉行治理會議。通知應包含會議時間、地點或連結、會議類型、參與方式，以及必要準備；若是特別治理會議，也應說明這次會議的目的與範圍。除非圈子政策明確規定法定人數，否則治理會議不需要法定人數。只要書記已合理通知所有圈子成員，治理會議即可進行；缺席者被視為已有機會參與與提出反對。

若圈子依政策邀請外部夥伴協助擔任協調者或書記，該夥伴只能為了維護流程或紀錄而參與會議，不因此取得該圈子的治理權。

9.10.1 重大治理事項的通知、出席與冷靜期

一般治理會議在合理通知後可以不設法定人數；但若提案涉及高風險事項，則應適用更高的通知、出席與冷靜期要求。

高風險治理提案至少應符合以下要求，除非涉及立即安全、法律或未成年保護風險：

• 會議前至少七十二小時發布提案摘要
• 提案應清楚標示其為高風險事項
• 通知應主動送達受影響角色、敏感角色與相關圈子
• 會議中應確認是否有足夠代表性參與
• 若缺席者包含明顯受影響角色，協調者應判斷是否仍適合處理
• 通過後應有至少二十四小時冷靜期，除非治理會議明確確認立即生效的必要性

圈子可以透過政策為高風險治理提案設定更高門檻，例如最低出席比例、必要角色出席、第二次確認、上層圈覆核或外部專業意見。這些門檻的目的不是恢復投票制或批准制，而是避免重大權力變更在低注意度、低出席或資訊不足的情況下通過。

若有人認為某項提案被錯誤地標示為非高風險事項，可以在治理會議中提出程序性反對。協調者應先處理該程序性反對，再繼續一般治理流程。

9.11 特別治理會議

當某個張力需要在一般治理會議前被處理，或只適合處理某個明確範圍時，圈子成員可以請求書記安排 特別治理會議。特別治理會議應清楚標示目的與範圍，例如「只處理活動安全政策」、「只處理報名系統領域歸屬」、「只處理代表連接選舉」。

特別治理會議不得擴張成一般治理會議。會議中只能處理通知中列出的範圍；超出範圍的提案應留到一般治理會議，或另行安排新的特別治理會議。特別治理會議仍然依本章的治理會議流程處理提案、反對、整合與紀錄，不因為它是特別會議就可以跳過正式流程。

9.12 非同步治理

圈子可以透過政策允許 非同步治理。非同步治理適合處理簡單、清楚、影響範圍有限、低風險且容易回復的治理提案，例如修正角色文字、補上明確職責、整理小型政策、調整不具爭議的領域紀錄等。

非同步治理不得用於以下事項，除非上層圈政策明確允許，且已設置額外通知、覆核與冷靜期：

• 修改本憲章、根圈政策或重大治理流程
• 建立、修改或移除安全、未成年保護、財務、法律、品牌、資料保護、平台規則或對外代表權政策
• 任命、移除、暫停或重新配置敏感角色
• 建立、解散或重組重要圈子
• 授予、收回或重新配置重大領域、預算池、平台管理權限、資料存取權限或對外代表權
• 處理檢舉、申訴、紀律、停權、封禁、重大信任事件或利益衝突事件
• 任何被合理指出可能屬於高風險事項的提案

非同步治理應至少包含：

• 提案全文
• 張力說明
• 影響範圍
• 是否涉及高風險事項的自我檢查
• 開放釐清的時間
• 開放反應的時間
• 提出反對的期限
• 預計生效時間

非同步治理的提案應發布在圈子正式指定且高可見度的位置，並主動通知受影響角色。不得將非同步治理藏在一般聊天訊息流、私人訊息、臨時群組或低可見度工具中。

若在期限內沒有有效反對，提案可以被採用並更新正式紀錄。若有人提出有效反對，提案人與反對者可以非同步整合；若無法清楚整合，任何圈子成員都可以要求將提案轉入治理會議處理。

若事後發現某項非同步治理實際上屬於高風險事項，書記應將其標記為爭議紀錄，並提交治理會議、上層圈或指定覆核角色處理。在覆核完成前，該治理結果不得被用來擴張敏感權力、處理重大資源或限制他人權利。

9.13 治理結果如何生效

治理提案只有在通過並由書記更新正式紀錄後，才成為正式治理結果。口頭通過、群組共識、會議印象或私下說法，不應取代正式紀錄。

書記發布治理結果時，應盡量寫清楚：改了什麼、影響哪些角色或圈子、從什麼時候開始生效，以及是否需要相關角色採取後續行動。若治理結果與既有紀錄衝突，書記應協助整理並更新，使正式紀錄保持一致。

治理結果生效後，相關角色與圈子應依更新後的正式紀錄行動。若實際運作中發現治理結果不合適、不清楚或造成新的張力，應再次透過治理流程修正，而不是靠私下默契跳過正式紀錄。

9.14 治理捷徑防濫用

有些程序是為了讓組織更快行動，例如公告式許可、非同步治理、個人倡議、臨時代理與創辦人保留權。但這些程序都是例外或輔助機制，不得被用來取代正式治理、長期授權或正當程序。

若某個角色、圈子或個人反覆使用例外程序處理相似事項，相關夥伴應將其視為治理張力。圈子應檢查是否需要：

• 建立正式角色
• 建立政策
• 明確授權
• 調整流程
• 增加訓練
• 設定值班或代理機制
• 限制某項例外程序的使用範圍

若例外程序被用來規避反對、降低可見性、排除受影響者、繞過敏感角色、壓縮討論時間、逃避紀錄或集中權力，協調者、書記、代表連接、上層圈或受影響夥伴可以提出程序性反對，並要求該事項回到正式治理或覆核流程。

第十章：角色選任與整合式選舉

10.1 適用原則

圈子可以依政策或實際需要，選擇合適的方式安排協調者、書記、代表連接，或其他需要明確承接的角色。角色選任的目的不是選出最受歡迎的人，而是讓某個角色在一段明確時間內，被合適的人承接。

對於長期圈子、影響多個圈子的角色，或可能產生爭議的角色，圈子可以使用整合式選舉流程。對於一次性活動圈、小型專案圈、臨時合作圈，圈子可以使用較簡化的選任方式，只要角色、承接者、範圍與期限被記錄清楚即可。

10.2 簡化選任

一次性活動圈、小型專案圈或臨時圈子，可以用簡化方式安排角色承接。圈子可以由夥伴自願承接、由現場參與者提名，或由建立該圈子的角色與夥伴提出建議人選，再確認是否有人有重大反對。

若沒有人提出重大反對，該角色承接即成立，書記應記錄角色名稱、承接者、承接範圍、任期或結束條件。若有人反對，反對者應說明該人承接角色會造成什麼具體風險，而不只是表示不喜歡或另有偏好。

10.3 整合式選舉

當圈子需要更正式地選出某個角色時，可以使用整合式選舉。整合式選舉的目的是整合圈子對於「誰最適合承接這個角色」的觀點，而不是透過投票競爭。

流程如下：

1. 說明角色：協調者說明要選出的角色名稱、責任範圍、任期或結束條件。
2. 提名輪：每位圈子成員依序提名一位候選人（可以提名自己），並簡要說明理由。
3. 理由分享輪：所有提名完成後，再依序讓每位成員補充或說明提名理由，讓圈子理解各候選人的適配性。
4. 更改提名輪：在聽完所有理由後，每位成員可以選擇維持或更改自己的提名。
5. 提案形成：協調者根據提名與理由，提出一位候選人作為選舉提案。

候選人被提出後，應先確認該候選人是否願意承接該角色。若候選人明確表示不願意承接，協調者應重新整合並提出其他候選人，而不應強行推進。若候選人願意承接，圈子進入反對輪。若沒有人提出有效反對，該候選人即承接角色。

若有人提出反對，反對者需說明該候選人承接角色會造成的具體風險或影響，而不只是表達偏好。協調者應協助釐清反對內容，並嘗試整合，例如調整角色範圍、確認支援條件，或重新提出另一位候選人。

若出現提名分散、難以整合，或多位候選人支持度相近（類似平手）的情況，協調者不應直接進行投票，而應回到理由與需求，協助圈子釐清角色真正需要的能力與條件，再提出新的整合提案。必要時，可以暫停選舉、收集更多資訊，或安排短期代理角色後再重新選任。

整合式選舉不應變成投票辯論，也不應用來比較誰比較受歡迎，而是透過結構化流程，讓圈子共同找到最適合承接該角色的人。

10.4 任期與重新選任

被選任的角色可以依圈子的性質與需要，決定是否設定任期或結束條件。對於短期活動或一次性圈子，角色承接通常隨活動結束而自然終止，不一定需要額外設定任期；對於長期運作的圈子，則建議設定明確任期、結束條件，或由圈子政策定義重新選任的時機。

若有設定任期，任期屆滿時，協調者應提醒圈子重新安排選任；若協調者未提醒，任何圈子成員都可以提出。若角色承接者不再適合承接該角色，或圈子出現新的張力，圈子可以依治理流程、圈子政策或本章規則重新安排選任。

第十一章：戰術會議

11.1 戰術會議目的

任何圈子可以定期召開 「戰術會議」，以協助角色承接者更新狀態、提出請求、處理阻塞，並讓日常工作向前推進。戰術會議不是治理會議，不應修改角色、政策或正式權力結構，戰術會議的重點是推動與同步工作。

11.2 戰術會議出席

戰術會議應邀請與當次工作有關的角色承接者參與。若是圈子定期舉行的戰術會議，除非圈子政策另有規定，預設邀請該圈子中所有角色的承接者；若是臨時召開的戰術會議，召集者應說明這次會議要處理什麼，並邀請相關角色或夥伴參與。

參與者在戰術會議中，主要代表自己承接的角色更新狀態、提出請求、回應請求或協助處理阻塞。若一位夥伴承接多個角色，可以在會議中代表不同角色發言，但應盡量說清楚自己是以哪個角色在回應。

沒有被邀請參與某次戰術會議，不代表被排除在圈子外，而是那次會議不一定需要所有人參與。若會議內容會影響某個未出席角色，召集者或相關角色應在必要時補充邀請，或在會後同步必要資訊。

11.3 戰術會議流程

戰術會議由協調者維持節奏，戰術會議不需要像公司會議一樣冷冰冰；它可以有問候、近況、玩笑與自然交流，但當會議進入正式議程時，協調者應幫助大家回到流程，避免聊天取代工作推進。

第一，簽到輪。 會議開始時以近況分享開始，讓大家進入狀態，每位參與者簡短說明自己目前的狀態、近況、有趣的生活事情等等。該輪不討論議程相關事項。

第二，工作狀態同步。 相關角色承接者可以簡短回報週期性工作、重要數據、目前進度或卡住的地方。這一步只同步重點，不做檢討、不開策略討論，也不展開長篇報告。

第三，建立議程。 每位參與者可以提出想處理的事項，只需要給一個簡短標籤，例如「講師聯絡卡住」、「報名頁更新」、「場地物資確認」。此時不解釋、不討論。

第四，處理議題。 協調者依序處理議程。處理每個議題時，協調者可以先問議題提出者：「你需要什麼？」議題提出者可以提出請求、詢問資訊、請某個角色接住下一步、要求更新狀態，或把事情整理成下一步行動或專案。協調者應幫助議題保持聚焦，並在適當時確認：「你獲得你需要的東西了嗎？」若已經獲得，該議題即可結束，進入下一個議題。

戰術會議可以處理阻塞、同步資訊、提出請求、確認下一步與專案，但不得修改角色、政策、領域或正式權力結構。若議題需要改變正式結構，應轉為治理張力，透過治理流程處理。

第五，收尾與自由交流。 會議結束前，每位參與者可以簡短分享自己計畫的下一步任務、目前感受，或對會議節奏的回饋。正式會議結束後，參與者可以留下來自由聊天、延伸討論等。

11.4 戰術會議中的請求

在處理議題時，重點不是讓大家一起討論到有共識，而是幫助議題提出者獲取他需要的東西/資訊/請求等。議題提出者可以向其他參與者提出具體請求，例如請對方完成一個下一步行動、承接一個專案、提供資訊、更新狀態，或確認某件事是否可行。

請求應盡量說清楚：希望對方做什麼、這件事服務哪個角色或專案，以及是否有希望完成或回覆的時間。被請求的人可以接受、拒絕、提出替代做法，或說明自己需要更多資訊。

協調者可以限制每個議題的處理時間，並在議題開始散掉時把大家拉回來：「這個議題現在需要什麼？」或「你已經拿到你需要的東西了嗎？」戰術會議的目的不是把所有問題一次聊完，而是讓工作被看見、阻塞被處理、下一步變清楚。

第十二章：文件與正式來源

12.1 正式紀錄內容

HackIt 的正式治理內容應被記錄在可查閱的位置。正式紀錄至少應包含圈子的宗旨、圈子中的角色、角色的宗旨、職責、領域與政策、角色承接者、圈子政策、治理會議產出、重要決策與其來源，以及憲章版本與修改紀錄。

12.2 文件系統

HackIt 可以使用多個工具協作文件，但應透過政策定義哪些地方是正式來源，並且所有夥伴必須遵循該政策來保存紀錄。每個圈子應盡量讓重要資訊有地方可查，而不是只存在某個人的腦中、私訊裡，或某個沒人敢問的神秘資料夾。

12.3 公開與內部

HackIt 可以將文件分為公開、內部、限制存取或私密等不同層級。文件是否公開，應依照角色權限、活動安全、個資保護、未成年保護、合作協議與組織策略判斷。CoBuild 鼓勵透明，但透明不等於所有東西都公開；好的透明，是讓該知道的人能知道，讓需要協作的人能協作，並讓敏感資訊受到保護。

第十三章：流程失效

13.1 流程失效定義

當一個圈子長期無法依本憲章運作，或其行為與產出反覆違反本憲章時，即可能發生 「流程失效」。流程失效可能包括角色與政策長期不被記錄、治理會議不依流程處理提案、反對被當成投票或情緒否決、引導連接把自己當成主管、角色承接者長期不處理請求且不說明狀態、文件與現實長期分裂、權力被私下關係取代、書記不維護紀錄、協調者不保護流程，或代表連接被阻止向上處理張力。

13.2 流程失效的提出與確認

任何夥伴如果發現某個圈子長期無法依本憲章運作，可以提出流程失效張力。這不應只是因為不喜歡某個人、某個決定或某種風格，而應指出具體模式，例如治理紀錄長期缺失、會議不依流程進行、角色權力被私下關係取代，或代表連接無法向上處理張力。

提出流程失效張力後，應優先依相關政策處理。若政策未涵蓋，夥伴可以請求該圈子的引導連接，或上層圈的協調者、書記協助檢查。檢查者應根據正式紀錄、會議狀況、角色運作與本憲章規則判斷。若確認圈子已無法可信地維持流程，檢查者可以宣告該圈子發生流程失效，並說明原因、影響範圍，以及接下來應由哪個圈子、角色或流程接手恢復。

13.3 流程恢復

當圈子被宣告流程失效後，上層圈或被授權角色可以採取必要措施協助恢復流程。這些措施可能包括暫時協助主持治理會議、整理正式紀錄、暫停有爭議的權力、要求圈子重新整理角色與政策，或安排臨時承接者。

流程恢復的目的不是懲罰圈子，也不是讓上層圈永久接管，而是讓圈子重新具備可信的治理能力。恢復措施應盡量明確、有限，並在必要時留下紀錄，說明介入原因、介入範圍與預期恢復條件。

當圈子重新能依本憲章運作，正式紀錄被整理清楚，角色與政策能被查閱並實際使用，會議流程也能被正常維護時，上層圈或相關角色可以宣告流程恢復完成。流程失效與恢復結果都應留下正式紀錄。

13.4 流程失效的升級

如果一般恢復措施無法讓圈子恢復基本運作，流程失效可以向上升級。上層圈可以採取更強的臨時措施，例如直接接管部分治理權、重新配置角色與職責，或在必要時解散該圈子，並將其職責、領域與專案重新分配。

一個子圈的流程失效，不會自動代表上層圈也失效。但如果上層圈長期不處理子圈失效，或放任失效影響整個組織，上層圈也可能被視為發生流程失效。若流程失效一路升級到根圈，應依根圈政策、創辦人保留權或其他正式保護機制處理。

流程失效的升級不是為了懲罰，而是為了確保 HackIt 的整體治理仍然可信、可查、可運作。

13.5 權力集中與濫用檢查

HackIt（圈子與其上層圈）應定期檢查圈子的運作是否造成非預期的權力集中。

檢查項目至少包含：

• 是否有敏感角色長期空缺
• 是否有引導連接長期覆蓋多個未承接角色
• 是否有同一人同時承接過多敏感角色
• 是否有角色承接者被頻繁更換而缺乏清楚紀錄
• 是否有公告式許可被用於高風險事項
• 是否有非同步治理被用於重大權力變更
• 是否有個人倡議反覆出現但沒有轉化為正式政策
• 是否有創辦人保留權被用於一般治理爭議
• 是否有書記裁定反覆影響治理結果
• 是否有正式紀錄與實際運作長期不一致
• 是否有受影響夥伴難以看見、理解或參與相關流程

若檢查發現明顯權力集中、程序捷徑濫用或正式制度被架空，相關圈子應將其作為治理張力處理。必要時，上層圈可以要求該圈子提出修正計畫，包含角色調整、政策補充、紀錄整理、訓練安排或流程恢復措施。若圈子長期無法做出有效調整，則其上層圈需評估是否達到了流程失效並作出相關處理。

13.6 例外程序使用紀錄

凡使用下列程序，應留下可追溯紀錄：

• 公告式許可
• 非同步治理
• 個人倡議
• 創辦人保留權
• 高風險角色的臨時承接
• 敏感角色的暫停、移除或重新指派
• 書記對紀錄的爭議標記或初步無效判斷
• 流程失效宣告與恢復措施

紀錄至少應包含：

• 使用程序
• 使用者或角色
• 事項摘要
• 使用理由
• 影響範圍
• 是否涉及高風險事項
• 開始時間
• 結束或覆核時間
• 後續處理結果

這些紀錄不一定全部公開。若涉及安全、兒少保護、個資、檢舉、申訴、法律、財務或重大信任事件，應依最小知悉原則限制存取。但即使不公開，仍應保留足夠紀錄，使 HackIt 能在必要時進行覆核、稽核與制度修正。

第十四章：憲章修改

14.1 修改權

HackIt 可以依本憲章的治理流程修改本憲章。除非另有政策，修改本憲章的權力屬於根圈。根圈可以提出、討論、整合並採用憲章修正案。若某項修改涉及 HackIt 的根本使命、品牌信任、法律責任、核心資產、創辦人保留權或組織存在邊界，應同時依本憲章中關於根圈與創辦人的規則處理。

14.2 修改程序

當根圈成員，或被政策授權的人，感知到本憲章造成限制、模糊、不適用或無法處理真實張力時，可以提出憲章修改提案。提案應清楚說明要新增、修改或移除哪些內容，以及為什麼需要修改；憲章不應只因個人偏好、臨時不方便或單一事件情緒而被修改。

憲章修改提案應由根圈依治理流程處理。若提案涉及 HackIt 的根本邊界，創辦人可以依創辦人保留權提出暫停、要求復核或否決；但創辦人保留權不應被用來干預一般文字修正、普通治理調整或日常運作細節。

憲章修改通過後，書記應更新版本，記錄修改日期、修改內容、修改原因與採用方式，並將新版本發布到正式來源。舊版本應保留作為歷史紀錄，且目前有效版本應被清楚標示。

14.3 修改原則

修改本憲章時，應讓權力更清楚，而不是更模糊；讓角色更能行動，而不是讓所有事情回到批准；讓張力更容易被處理，而不是被壓下去。

憲章應服務 HackIt，而不是讓 HackIt 服務憲章。每一次修改，都應讓青少年更能共同建造，讓安全、信任與責任被保護，並讓文件更接近真實運作，而不是變成漂亮但沒人使用的制度。