thisisjun786 · thisisjun786 · Sep 7, 2026 · Sep 7, 2026
diff --git a/.github/README.md b/.github/README.md
@@ -0,0 +1,26 @@
+# Contributing to Lina
+
+[POLICY](../POLICY.md) is the authority for development, checks, merges and
+releases. Start with [CONTRIBUTING](../CONTRIBUTING.md) for setup and verification;
+[the project README](../README.md) explains Lina and how to run it.
+
+- [Open an issue](https://github.com/thisisjun786/lina/issues/new/choose) for a bug,
+  feature, compatibility report or design decision. The [issue forms](ISSUE_TEMPLATE)
+  show the information to include; small fixes do not require an issue first.
+- [Open a pull request](https://github.com/thisisjun786/lina/compare)
+  targeting `dev`. Follow the [PR template](PULL_REQUEST_TEMPLATE.md): explain the
+  problem, resulting behavior, checks actually run and material limitations.
+- Report vulnerabilities through the private route in [SECURITY](../SECURITY.md),
+  keeping exploit details and user data out of public issues and logs.
+
+`dev` is the default integration branch. Behavior changes start with a failing
+regression test. Before merging, the current candidate must pass `dev-gate`, be
+up to date with its target, have no conflicts and have resolved review conversations.
+Use merge commits only; do not bypass protection. Required approving reviews are
+zero, while confirmed defects still need resolution.
+
+[CI operation](../docs/CI.md) explains the checks and branch protections;
+[validation](../docs/VALIDATION.md) defines their acceptance limits. A future
+same-repository `dev -> main` promotion requires explicit owner instruction,
+release notes and `release-gate`. Source checks do not authorize publication or
+deployment.
diff --git a/README.md b/README.md
@@ -4,7 +4,6 @@ LINA는 Codex를 실행 엔진으로 사용하는 개인 에이전트 시스템
 하나의 장기 대화를 유지하며, 별도의 Codex 코딩 작업을 관리합니다. 프로바이더 계정,
 인증 정보, 사용 가능한 모델 목록은 OpenCodex에서 관리합니다.
 
-현재 공개 전 로컬 소스 후보이며, 이 준비 작업에서 저장소나 릴리스를 공개하지 않았습니다.
 개발·머지 규칙은 [POLICY.md](POLICY.md), 기여 절차와 이슈·PR 작성법은
 [CONTRIBUTING.md](CONTRIBUTING.md), CI 구성과 GitHub 적용 절차는 [CI 안내](docs/CI.md)에 있습니다.
 기본 런타임 구조는 [Codex 실행 구조](docs/CODEX_RUNTIME.md)에서 확인할 수 있습니다.
@@ -191,7 +190,7 @@ bun run lint
 확인한 외부 프로젝트의 버전과 라이선스, 서비스 사용과 코드 재배포·수정의 구분은
 [외부 소프트웨어 고지](THIRD_PARTY_NOTICES.md)를 참고하세요.
 
-## 라이선스와 공개 준비
+## 라이선스와 출처
 
 Lina의 자체 소스 코드·문서·유지관리자가 작성한 페르소나 프리셋 텍스트와
 확인된 아바타 9개·앱 아이콘 2개는 보유 권리 범위에서
@@ -205,8 +204,7 @@ Lina의 자체 소스 코드·문서·유지관리자가 작성한 페르소나
 사용자의 대화·메모리·인증 정보와 개인 설치에서 변경한 페르소나는 이 소스의
 라이선스 부여나 공개 범위에 포함하지 않습니다.
 
-이 소스는 **공개 전 로컬 후보**입니다. [공개 준비 체크리스트](docs/PUBLICATION.md)는
-권리·보안 신고 경로·개인 식별 정보 검토와 별도 공개 승인 조건을 기록합니다.
-공개 대상은 개인 운영 이력과 기존 Git·호스팅 이력을 포함하지 않는 별도 검토된 소스여야 합니다.
-취약점 제보는 현재 이용 가능한 경로와 제한을 설명한 [SECURITY.md](SECURITY.md)를
-따르세요.
+Lina는 독립적인 소스 프로젝트입니다. 소스와 이력의 공개 범위, 권리·개인정보 검토 기준은
+[공개 안내](docs/PUBLICATION.md)에 있습니다. 소스 공개와 릴리스·배포는 별도 절차이며,
+검증 결과는 해당 소스와 실행 환경을 기준으로 확인합니다.
+취약점은 [SECURITY.md](SECURITY.md)의 비공개 경로로 제보해 주세요.
diff --git a/SECURITY.md b/SECURITY.md
@@ -1,39 +1,26 @@
 # Security reporting
 
-This source candidate is prepared locally and has not been published by this preparation. There is no public security-support release
-matrix or guaranteed response time. Include the affected commit or installed
-release ID so the maintainer can reproduce a report against the right version.
+Include the affected commit or installed release ID so the maintainer can
+reproduce a report against the right version. There is no guaranteed response time
+or security-support release matrix.
 
 ## Reporting route
 
-When **Security → Advisories → Report a vulnerability** is available on this
-repository's GitHub page, use it to submit a private report. GitHub documents the
-[enablement requirement](https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/configure-vulnerability-reporting/configure-for-a-repository).
-
-No newly hosted repository or reporting feature has been activated by this local
-preparation. A dedicated security email address is not designated here.
-
-Existing collaborators should contact the repository owner through the private
-channel used to arrange their repository access and request a confidential
-handoff before sending vulnerability details. If you have no such channel, do
-not guess an address from commit metadata. This interim route applies during
-private development; a public reporting feature is not required to continue
-private preparation.
-
-At an explicitly authorized public visibility change, the maintainer must
-immediately enable GitHub private vulnerability reporting, read back its enabled
-state, and verify that the **Report a vulnerability** button is available to
-reporters. These are coupled activation steps, not a promise that the feature is
-already active. Do not announce public activation as complete until they pass.
-If enablement fails, report public activation as incomplete and resolve the
-failure before declaring it complete. See the
-[publication checklist](docs/PUBLICATION.md) for the owner-controlled sequence.
+Submit vulnerabilities through GitHub's
+[private reporting form](https://github.com/thisisjun786/lina/security/advisories/new),
+also reached through **Security → Advisories → Report a vulnerability**.
+
+If the form is unavailable, open an
+[issue requesting a private contact route](https://github.com/thisisjun786/lina/issues/new)
+without vulnerability details. Wait for a confidential handoff before sharing the
+report. No dedicated security email address is designated here; do not infer one
+from commit metadata.
 
 Do not put exploit details, credentials, private transcripts, or user data in
 public issues, pull requests, discussions, or CI logs. A repository issue is
 visible to its readers and is not a dedicated confidential reporting channel.
 
-## What to include after arranging private contact
+## What to include in a private report
 
 - Affected revision, operating system, runtime mode, and relevant dependency versions.
 - Minimal reproduction using synthetic data, expected and observed behavior,

diff --git a/docs/CI.md b/docs/CI.md
@@ -1,7 +1,8 @@
 # CI operation and activation
 
 [POLICY.md](../POLICY.md) owns the rules. This page maps those rules to commands
-and GitHub settings. It is not evidence that remote protection is already active.
+and GitHub settings. Keep verification evidence with the corresponding PR or
+release record.
 
 ## Checks
 
@@ -59,42 +60,47 @@ JavaScript or prove live exploitability.
 
 ## Activation
 
-The local source candidate has no newly activated GitHub settings or hosted CI
-results. For an explicitly authorized repository, configure and verify the
-following target settings after the checked-in workflow is available:
+`dev` is the default branch and the target for normal contributions. `main` has
+not been created; it is reserved for a future owner-authorized release promotion.
+Public source activation does not include creating `main` or promoting a release.
+
+Keep the following protection settings in place and verify them from GitHub
+after any settings or visibility change:
 
 | Setting | `dev` | `main` |
 | --- | --- | --- |
+| Protection mechanism | Classic branch protection | Active ruleset targeting `refs/heads/main` |
 | Required check | `dev-gate` | `release-gate` |
 | Check producer | GitHub Actions, app ID `15368` | GitHub Actions, app ID `15368` |
 | Up-to-date base and PR required | Yes | Yes |
 | Required approving reviews | 0 | 0 |
-| Resolved conversations and admin enforcement | Yes | Yes |
+| Resolved conversations | Required | Required |
+| Bypass | Admin enforcement; no bypass | Zero bypass actors |
 | Force pushes and branch deletion | Blocked | Blocked |
 
-Merge commits are enabled; squash/rebase merging and automatic merge are disabled.
-Required linear history is off. These are intended settings; their presence in
-this document does not establish remote enforcement or a green candidate.
+The ruleset for future `main` is active even while the branch is absent. Its strict
+`release-gate` requirement also applies when creating the branch; there is no
+first-branch exemption or bypass procedure.
 
-For a newly created repository, land the CI contribution files through a checked
-PR, then apply the settings above and re-read them from GitHub. Bind checks to
-GitHub Actions rather than accepting a matching check name from any producer.
-Do not bypass a required check to bootstrap it. Setting the default to `dev`
-exposes its contribution templates and makes integration the ordinary PR base.
+Merge commits are the only enabled merge method. Squash/rebase merging, automatic
+merge and required linear history are off. Actions use a read-only default token
+and cannot create or approve pull requests. Bind required checks to GitHub Actions
+so a matching name from another producer cannot satisfy protection.
 
-Visibility remains a separate owner decision. Public activation must enable and
-verify the confidential reporting route immediately;
-see [publication preparation](PUBLICATION.md) and [SECURITY.md](../SECURITY.md).
-Re-read protection after a visibility change. Admins who can edit repository
-settings can change the policy itself; the restrictions above are not immutable.
+Verify hosted checks against the actual PR candidate; checked-in workflows and
+local results do not establish a hosted result. Public activation also requires
+reporter-visible access to the private route in [SECURITY.md](../SECURITY.md), as
+described in [publication guidance](PUBLICATION.md). Administrators with settings
+access can change the rules themselves; the protections are not immutable.
 
 Before any merge, re-read the PR head/base, required checks, draft status,
 mergeability and unresolved conversations. Match the reviewed head when invoking
 the merge action (`gh pr merge --merge --match-head-commit <SHA>` is one option).
 Strict status checks cover target-branch movement; an expected-head argument
 alone protects only the source branch. Refresh checks when either input changes.
-After promotion, reconcile the new `main` merge commit into `dev` through a PR
-before the next promotion; do not use a direct push to synchronize branches.
+After a future authorized promotion, reconcile the new `main` merge commit into
+`dev` through a PR before the next promotion; do not use a direct push to
+synchronize branches.
 
 ## Failures and changes to CI
 

diff --git a/docs/PUBLICATION.md b/docs/PUBLICATION.md
@@ -1,13 +1,10 @@
-# Publication preparation
+# Public source and publication
 
-Status: **LOCAL CANDIDATE — PREPARED FOR REVIEW, NOT PUBLISHED**.
-This preparation does not create a GitHub repository, activate its settings or CI,
-change visibility, publish an artifact, or deploy a service. Final candidate checks
-and the exact publication action remain separate under [POLICY](../POLICY.md).
-
-Codex is the sole supported execution engine. Product contracts and future scope
-are documented in [runtime](CODEX_RUNTIME.md), [plans](PLANNING.md) and
-[validation](VALIDATION.md).
+Lina is an independent Apache-2.0 project with Codex as its sole execution engine.
+[POLICY](../POLICY.md) owns publication and release authority. This guide defines
+what belongs in the public source and what evidence to retain when publishing it.
+Product contracts and future scope are documented in [runtime](CODEX_RUNTIME.md),
+[plans](PLANNING.md) and [validation](VALIDATION.md).
 
 ## License and provenance
 
@@ -19,65 +16,62 @@ are documented in [runtime](CODEX_RUNTIME.md), [plans](PLANNING.md) and
   nine avatars and two app icons in the owner's 2026-09-07 attestation, to the
   extent of the rights held. Dependencies, upstream services, and third-party
   material retain their own terms.
-- [Third-party notices](../THIRD_PARTY_NOTICES.md) pin the reviewed upstream
+- [Third-party notices](../THIRD_PARTY_NOTICES.md) identify reviewed upstream
   sources and distinguish HTTP integration from copying or distributing software.
   They are a scoped record, not a complete transitive dependency or ancestry audit.
-- [Persona provenance](../data/personas/README.md) explains the 18 original
-  source digests, current content digests, and the authored SOUL and CHARACTER modifications.
-  It also records the owner's explicit confirmation of directly creating/generating
-  all nine avatars and both app icons and holding their input rights. That
-  attestation and the scoped Apache-2.0 grant resolve the recorded image blocker.
-  Hashes identify the covered files; no creation tool or specific input is inferred.
+- [Persona provenance](../data/personas/README.md) preserves original source
+  digests, current content digests, and authored SOUL and CHARACTER modifications.
+  It records the owner's confirmation of directly creating/generating all nine
+  avatars and both app icons and holding their input rights. Hashes identify the
+  covered files; no creation tool or specific input is inferred.
 - User conversations, memory, credentials, and adopted/customized personas in a
   user's installation are outside the project license grant and source export.
 
 ## Source and history boundary
 
-This candidate contains portable product plans under `docs/plans`, authored source
-resources and public third-party notices. Private operational records, session
-handoffs, screenshots and archival repository references are excluded. Persona
-provenance keeps original import digests; current digests identify edited bytes.
-Synthetic fixtures and documented default/loopback configuration are examples,
-not disclosures of a private installation.
-
-A clean working tree does not erase existing Git or hosting history. The export
-must start from a separately reviewed root, without inherited commits, branches,
-tags, reflogs, remotes, PRs, issues or Actions records. Preserve the original
-private source and its backup separately. Do not merge, fetch or copy private
-history or operational records into the public candidate. Ignore rules do not
-untrack files already in the index: inspect the final tracked-file set explicitly.
-
-Detailed privacy scans, metadata comparisons and backup receipts stay outside
-the candidate. Pattern scans are leads for contextual review, not proof that all
-unknown identifiers or secrets are absent. Review all selected blobs, commit
-identities, image metadata and any new hosting attachments before publication.
-Keep required copyright, licensing and public source attribution intact.
-
-## Final review and activation
-
-Each unchecked item needs evidence for the exact final candidate. This page does
-not inherit earlier test totals, hosted results or repository settings.
-
-- [ ] Verify source files, all local Markdown targets, 18 current persona digests,
-  retained original digests, image identity and distribution notices.
-- [ ] Review current files and binary metadata for secrets and private identifiers;
-  verify generated operational records are excluded from the tracked export.
-- [ ] Create and inspect the independent root history and commit identity; verify
-  no private history, remotes or additional refs enter the export.
-- [ ] Run source, dependency, secret and isolated installation checks from
-  [VALIDATION](VALIDATION.md); retain exact-candidate evidence privately.
-- [ ] Present the exact new-repository/publication operation for explicit owner
-  approval, preserving the original repository's private history.
-- [ ] On authorized hosting, apply and read back default branch, merge methods,
-  required checks and protections using [CI activation](CI.md#activation).
-  New hosted checks must run against their actual candidate.
-- [ ] At public activation, enable and verify the confidential reporting route
-  described in [SECURITY](../SECURITY.md), including reporter-visible access.
-- [ ] Verify the published files and settings, and keep release promotion,
-  package/container publication and deployment within their separately approved scope.
-
-No new GitHub repository, settings, hosted CI result or public reporting route is
-claimed by this local preparation. A failed activation step remains incomplete.
+Publish portable product plans, authored source resources and public third-party
+notices. Keep private operational records, session handoffs, screenshots and
+personal environment metadata out of the source and hosting attachments.
+Synthetic fixtures and documented default or loopback configuration must remain
+clearly identifiable as examples. Preserve required copyright, licensing and
+public source attribution.
+
+Public source history begins at an independently reviewed root. Do not import
+private history or operational records into it. A clean working tree does not
+establish that history is safe to publish: inspect the tracked-file set, commits,
+identities, branches and tags, as well as PRs, issues, Actions logs and attachments.
+Ignore rules do not remove already tracked files.
+
+Review selected files and binary metadata in context. Pattern scans identify
+items for review; they cannot prove the absence of every unknown identifier or
+secret. Keep detailed privacy findings and backup records outside the public
+repository. Public evidence must be redacted without losing the information
+needed to assess the result.
+
+## Review and activation
+
+Before publishing source or changing visibility:
+
+1. Review the exact files and history being published. Verify Markdown links,
+   persona digests, image identity, redistribution rights and retained notices
+   using [VALIDATION](VALIDATION.md).
+2. Record source, dependency, secret and applicable installation checks against
+   that revision. Include commands, outcomes and limits; distinguish local checks
+   from hosted checks on the PR's combined merge candidate.
+3. Confirm owner authorization for the publication action. Apply and read back
+   the default branch, merge methods, required checks and protections described
+   in [CI activation](CI.md#activation); recheck them after visibility changes.
+4. Enable GitHub private vulnerability reporting and verify reporter-visible
+   access to the form linked in [SECURITY](../SECURITY.md). A configured setting
+   alone does not prove that a reporter can submit privately.
+5. Inspect the published files and contributor entry points. Record the relevant
+   hosted results and settings verification without exposing private records.
+
+Retain evidence with the corresponding PR or release record. Report failed,
+skipped and unrun checks distinctly; this guide does not replace those results.
+Source publication does not authorize a release promotion, tag, package or
+container publication, deployment, provider calls or changes to installed data.
+Any such action follows its own owner authorization and acceptance evidence.
 
 ## Reproducible documentation checks