# 現在のworking copyの上に新しいcommitを作成
$ jj new
# → 現在の変更が確定し、新しい空のworking copy commitが作成される
 
# 特定のcommitの上に新しいcommitを作成
$ jj new qpvuntsm
# → qpvuntsm の子として新しいworking copy commitを作成
# → 元のworking copyの位置にあったcommitは自動的に上に移動
 
# マージcommitの作成（複数の親を指定）
$ jj new commit-a commit-b
# → commit-a と commit-b の両方を親に持つmerge commitを作成
 
# メッセージ付きで新しいcommitを作成
$ jj new -m "feat: 新機能の基盤"
# → 新しいcommitを作成し、同時にメッセージを設定
 
# 特定のrevisionの後に挿入
$ jj new --after aaa --before bbb
# → aaa と bbb の間に新しいcommitを挿入

# 過去のcommitをworking copyにする
$ jj edit qpvuntsm
# → qpvuntsm がworking copyになり、直接編集可能に
# → その上にあるcommitは自動的にリベースされる
 
$ vim src/config.js  # qpvuntsmのcommitを直接編集
# → 子commitが自動リベースされる
 
# change IDで指定（推奨）
$ jj edit rlvkpntz
# → commit IDではなくchange IDを使うことで、rebase後も追跡可能
 
# ブックマーク名で指定
$ jj edit feature-auth
# → ブックマークが指すcommitをworking copyにする

# working copyの変更を親commitに統合
$ jj squash
# → working copyの全変更が親commitに移動
# → working copyは空になる
 
# メッセージを同時に設定
$ jj squash -m "feat: 認証機能の完成版"
# → 統合後のcommitにメッセージを設定
 
# 特定のファイルだけ親commitに統合
$ jj squash --keep src/auth.js
# → src/auth.js の変更だけ親に移動、他はworking copyに残る
 
# 特定のcommitに対してsquash
$ jj squash --from rlvkpntz --into qpvuntsm
# → rlvkpntzの変更をqpvuntsmに統合
 
# パスを指定して部分的にsquash
$ jj squash src/auth.js src/middleware.js
# → 指定ファイルの変更のみ親に移動
 
# インタラクティブにsquashする内容を選択
$ jj squash -i
# → diff-editorが開き、squashする変更を選択できる

# working copyの変更をインタラクティブに分割
$ jj split
# → エディタが開き、最初のcommitに含める変更を選択
# → 残りは新しいcommitになる
 
# ファイル単位で分割
$ jj split src/auth.js src/middleware.js
# → 指定ファイルの変更が最初のcommitに
# → 残りのファイルの変更が次のcommitに
 
# 過去のcommitを分割
$ jj split -r rlvkpntz
# → rlvkpntz をインタラクティブに分割
# → 子commitは自動リベース
 
# パスパターンで分割
$ jj split "src/**/*.test.js"
# → テストファイルの変更を最初のcommitに
# → それ以外を次のcommitに

# 注意: jj move は古いコマンドで、jj squash --from --into に置き換えられた
# 互換性のために残っているが、squashの使用を推奨
 
# 旧: jj move --from A --to B
# 新: jj squash --from A --into B
 
# 使用例（squashで代替）
$ jj squash --from rlvkpntz --into qpvuntsm
# → rlvkpntz の変更を qpvuntsm に移動

# working copyの変更をdiffエディタで編集
$ jj diffedit
# → diff-editorが開き、変更を追加・削除できる
 
# 過去のcommitをdiffエディタで編集
$ jj diffedit -r rlvkpntz
# → rlvkpntz の変更内容をdiffエディタで直接編集
# → 子commitは自動リベース
 
# 特定のファイルのみ編集
$ jj diffedit -r rlvkpntz src/auth.js

# 3つのcommitが積まれた状態
$ jj log
@  ccc  feat: UI実装
○  bbb  feat: APIエンドポイント
○  aaa  feat: 初期設定
◆  root()
 
# 中間のcommitを直接編集
$ jj edit bbb
$ vim src/api.js
$ jj new  # 編集を確定して新しいworking copyへ
 
# → ccc が自動的にリベースされる！
$ jj log
@  ddd  (empty)
○  ccc' feat: UI実装           ← 自動リベース済み（SHA変更）
○  bbb' feat: APIエンドポイント ← 編集された
○  aaa  feat: 初期設定
◆  root()

# 複数の子commitがある場合も全て自動リベース
$ jj log --no-graph
aaa  feat: 基盤
├── bbb  feat: 認証
│   └── ccc  feat: 認証テスト
└── ddd  feat: UI
    └── eee  feat: UIテスト
 
# aaa を編集すると、bbb, ccc, ddd, eee の全てが自動リベース
$ jj edit aaa
$ vim src/base.js
# → 5つの子commit全てが新しいaaa'の上にリベースされる

# 自動リベース時にコンフリクトが発生した場合
$ jj edit aaa
$ vim src/shared.js   # bbb でも変更しているファイルを編集
 
$ jj log
○  ccc' feat: 認証テスト
○  bbb' feat: 認証          conflict    ← コンフリクト発生
○  aaa' feat: 基盤          ← 編集された
 
# コンフリクトは記録されるが、リベースは完了している
# bbb' に移動してコンフリクトを解決
$ jj edit bbb'
$ vim src/shared.js   # コンフリクトマーカーを解決
 
# コンフリクト解決後、ccc' も自動的にリベースされる
$ jj log
○  ccc'' feat: 認証テスト    ← 再リベース
○  bbb'' feat: 認証           ← コンフリクト解決済み
○  aaa'  feat: 基盤

# ブックマークの作成（Git branchに相当）
$ jj bookmark create feature-auth -r @
# → 現在のworking copy commitに "feature-auth" ブックマークを設定
 
# ブックマークの一覧
$ jj bookmark list
feature-auth: rlvkpntz abc12345
main: qpvuntsm def67890
 
# 全てのブックマーク（リモート含む）を表示
$ jj bookmark list --all
feature-auth: rlvkpntz abc12345
main: qpvuntsm def67890
main@origin: qpvuntsm def67890
 
# ブックマークの移動
$ jj bookmark set feature-auth -r @
 
# ブックマークの削除
$ jj bookmark delete feature-auth
 
# リモートブックマークの追跡
$ jj bookmark track main@origin
 
# ブックマークの名前変更
$ jj bookmark rename old-name new-name
 
# ブックマークの追跡解除
$ jj bookmark untrack feature@origin

# Jujutsuではブランチ名をつけなくても開発できる
$ jj new main          # mainの上に新しいcommitを作成
$ vim src/feature.js
$ jj describe -m "feat: 新機能のプロトタイプ"
 
# 別の作業をしたくなったら
$ jj new main          # mainの上にもう1つcommitを作成
$ vim src/hotfix.js
$ jj describe -m "fix: 緊急バグ修正"
 
# ログで確認
$ jj log
○  xxx  fix: 緊急バグ修正
│ ○  yyy  feat: 新機能のプロトタイプ
├─┘
◆  main  ...

# ブックマークなしではpushできない
$ jj git push
# Nothing to push
 
# pushするにはブックマークが必要
# 方法1: 明示的にブックマークを作成してpush
$ jj bookmark create feature-auth -r @
$ jj git push --bookmark feature-auth --allow-new
 
# 方法2: --change オプションで自動ブックマーク
$ jj git push --change @
# → change IDからブックマーク名が自動生成される
# → 例: "push-rlvkpntzqwop" のようなブランチ名
 
# 方法3: 複数のブックマークを一度にpush
$ jj git push --bookmark feature-auth --bookmark feature-ui
 
# ブックマークのpush状態を確認
$ jj bookmark list --all
feature-auth: rlvkpntz abc12345
  @origin: rlvkpntz abc12345    ← リモートと同期済み
feature-ui: qpvuntsm def67890
  @origin (behind): rlvkpntz old12345  ← ローカルが先行

# ブックマークが設定されたcommitを編集すると
# ブックマークは自動的に新しいcommit IDを追跡する
 
$ jj log
@  rlvkpntz  feature-auth  feat: 認証機能
○  main ...
 
$ jj edit rlvkpntz    # feature-auth のcommitを編集
$ vim src/auth.js     # ファイルを修正
 
# ブックマークは自動的に新しいcommitを追跡
$ jj bookmark list
feature-auth: rlvkpntz abc12345   ← change IDは同じ
# → commit IDは変わるが、change IDは変わらない
# → ブックマークはchange IDを介して追跡される

# 単一commitの親を変更（子commitは元の位置に残る）
$ jj rebase -r rlvkpntz -d main
# → rlvkpntz のみが main の子に移動
# → rlvkpntz の元の子commitは rlvkpntz の親に接続される
 
# commitとその子孫全体を移動
$ jj rebase -s rlvkpntz -d main
# → rlvkpntz以降の全commitをmainの上に移動
 
# 範囲指定でのリベース（ブランチの先端まで）
$ jj rebase -b feature-auth -d main
# → feature-authブックマークまでのcommitをmainの上に移動
 
# 複数の親を指定（マージcommitの作成を伴うリベース）
$ jj rebase -r rlvkpntz -d main -d feature-other
# → rlvkpntz がmainとfeature-otherの両方を親に持つようになる

# 既存の2つのcommitの間に新しいcommitを挿入
$ jj new --after aaa --before bbb
# → aaa と bbb の間に新しいcommitが挿入される
# → bbb以降は自動リベース
 
# 結果:
# ○  bbb'  feat: API      ← 自動リベースされた
# ○  new   (working copy)  ← 挿入された新commit
# ○  aaa   feat: 初期設定

# 2つのcommitの順序を入れ替える
# Before:
# ○  B  feat: UI
# ○  A  feat: 認証
 
# Aを B の上に移動
$ jj rebase -r A -d B
# → A が B の上に移動
 
# After:
# ○  A' feat: 認証
# ○  B  feat: UI
 
# より複雑な入れ替え（3つのcommitの順序変更）
# Before: C → B → A → main
# Goal:   A → C → B → main
 
$ jj rebase -r A -d main     # まずAをmainの直上に
$ jj rebase -s B -d A        # B以降をAの上に
# → A → B → C → main になる
# さらに
$ jj rebase -r C -d A        # CをAの直上に（Bの前に挿入）
# → A → C' → B' → main になる

# 作業1: 認証機能
$ jj new main
$ jj describe -m "feat: 認証機能"
$ vim src/auth.js
 
# 作業2: 認証機能の上にUI
$ jj new
$ jj describe -m "feat: ログインUI"
$ vim src/Login.jsx
 
# 作業3: mainから別の作業を開始（認証とは独立）
$ jj new main
$ jj describe -m "fix: パフォーマンス改善"
$ vim src/perf.js
 
# 全ての作業を一覧
$ jj log -r 'heads(all())'
 
# 作業の切り替え
$ jj edit rlvkpntz    # 認証機能の作業に戻る
$ jj edit qpvuntsm    # パフォーマンス改善の作業に切り替え

# 2つの作業をマージ
$ jj new feature-auth perf-fix
$ jj describe -m "merge: 認証とパフォーマンス改善を統合"
 
# あるいは特定のcommitをrebaseで合流
$ jj rebase -r perf-fix -d feature-auth

# ワークスペースは同一リポジトリを複数のディレクトリで扱う機能
# 各ワークスペースは独立したworking copyを持つ
 
# 新しいワークスペースの作成
$ jj workspace add ../my-project-hotfix
# → ../my-project-hotfix/ に新しいワークスペースが作成される
# → 同じリポジトリを共有しつつ、独立したworking copyを持つ
 
# ワークスペースの一覧
$ jj workspace list
default: rlvkpntz abc12345
hotfix: qpvuntsm def67890
 
# hotfixワークスペースで作業
$ cd ../my-project-hotfix
$ jj new main
$ vim src/fix.js
$ jj describe -m "fix: 緊急修正"
 
# 元のワークスペースに戻る
$ cd ../my-project
$ jj log  # hotfixの変更も見える
 
# ワークスペースの削除
$ jj workspace forget hotfix

# パターン1: フィーチャーフラグを使った段階的開発
$ jj new main
$ jj describe -m "feat: フィーチャーフラグ基盤"
$ vim src/feature-flags.js
$ jj new
$ jj describe -m "feat: ダークモード（フラグ付き）"
$ vim src/dark-mode.js
 
# パターン2: レビュー待ちの間に次の作業を開始
$ jj log
○  review-1  feat: 認証機能  ← レビュー中
◆  main
 
$ jj new review-1    # レビュー中のcommitの上に積む
$ jj describe -m "feat: 認証に基づくAPI"
$ vim src/api.js
# → review-1 がマージされてmainが更新されたら
# → jj git fetch && jj rebase -d main@origin で更新
 
# パターン3: 複数の独立した修正
$ jj new main -m "fix: ヘッダーのレイアウト修正"
$ vim src/header.css
 
$ jj new main -m "fix: フッターのリンク修正"
$ vim src/footer.html
 
$ jj new main -m "docs: READMEの更新"
$ vim README.md
 
# 各修正を個別にpush
$ jj git push --change rlvkpntz   # ヘッダー修正
$ jj git push --change qpvuntsm   # フッター修正
$ jj git push --change xtkvpqwm   # README更新

# commitの破棄（内容は削除、子commitは親に接続）
$ jj abandon rlvkpntz
# → rlvkpntz が削除され、子commitの親がrlvkpntzの親に変更される
 
# 複数のcommitを一度にabandon
$ jj abandon rlvkpntz qpvuntsm
# → 2つのcommitを同時に破棄
 
# revsetで条件指定してabandon
$ jj abandon 'empty() & mine()'
# → 自分の空のcommitを全て破棄
 
# working copyをabandon（変更の破棄）
$ jj abandon @
# → 現在のworking copyの変更を全て破棄
# → 新しい空のworking copyが親の上に作成される

# 操作の取り消し
$ jj undo
# → 直前のjjコマンドを完全に取り消す
 
# 特定ファイルの復元
$ jj restore --from main src/config.js
# → mainのsrc/config.jsの内容をworking copyに復元
 
# 特定のrevisionから複数ファイルを復元
$ jj restore --from @- src/auth.js src/api.js
# → 親commitから2つのファイルを復元
 
# 全ファイルを特定のrevisionから復元
$ jj restore --from main
# → working copyの全ファイルをmainの状態に復元
 
# パスパターンで復元
$ jj restore --from @- "src/**/*.test.js"
# → テストファイルのみを親commitの状態に復元

# 特定のcommitの変更を打ち消す新しいcommitを作成
$ jj backout -r rlvkpntz
# → rlvkpntz の変更を逆にした新しいcommitが作成される
# → Git の git revert に相当
 
# 打ち消しcommitの配置先を指定
$ jj backout -r rlvkpntz -d @
# → working copyの子として打ち消しcommitを作成

# PRを積み上げて段階的にレビュー・マージする
 
# Step 1: 基盤となる型定義
$ jj new main
$ vim src/types.ts
$ jj describe -m "feat: 型定義の追加"
$ jj bookmark create pr/types -r @
 
# Step 2: 型定義を使った認証ロジック
$ jj new
$ vim src/auth.ts
$ jj describe -m "feat: 認証ロジック"
$ jj bookmark create pr/auth -r @
 
# Step 3: 認証を使ったAPIエンドポイント
$ jj new
$ vim src/api.ts
$ jj describe -m "feat: APIエンドポイント"
$ jj bookmark create pr/api -r @
 
# 各ブックマークをpush
$ jj git push --bookmark pr/types --allow-new
$ jj git push --bookmark pr/auth --allow-new
$ jj git push --bookmark pr/api --allow-new
 
# ベースの変更を修正（型定義を更新）→ 全てが自動リベース
$ jj edit pr/types
$ vim src/types.ts
$ jj new    # 修正を確定
# → pr/auth と pr/api が自動リベース！
# → 各PRを再pushするだけ
$ jj git push --bookmark pr/types
$ jj git push --bookmark pr/auth
$ jj git push --bookmark pr/api

# レビューコメントに対応する
 
# レビュー対象のcommitを直接編集
$ jj edit pr/auth
$ vim src/auth.ts    # レビューコメントに対応した修正
$ jj new             # 修正を確定
 
# あるいは新しいcommitとして修正を追加し、後でsquash
$ jj new pr/auth
$ vim src/auth.ts
$ jj describe -m "fix: レビュー対応 - エラーハンドリング追加"
$ jj squash          # 修正を pr/auth に統合
 
# 再push
$ jj git push --bookmark pr/auth

# mainが更新された場合のリベース
 
# リモートの最新を取得
$ jj git fetch
 
# 現在の作業をmainの最新にリベース
$ jj rebase -d main@origin
 
# スタック全体をリベース
$ jj rebase -s <stack-root> -d main@origin
 
# コンフリクトが発生した場合
$ jj log -r 'conflict()'
# → コンフリクトのあるcommitを確認
$ jj edit <conflict-commit>
$ vim <conflicting-file>
$ jj new    # 解決を確定

# 開発中に緊急のhotfixが必要になった場合
 
# 現在の作業の状態を記録（不要、全てcommit済み）
$ jj log  # 現在の作業を確認
 
# mainからhotfixを作成
$ jj new main@origin
$ vim src/critical-fix.js
$ jj describe -m "fix: セキュリティ脆弱性の修正"
 
# 即座にpush
$ jj bookmark create hotfix -r @
$ jj git push --bookmark hotfix --allow-new
 
# 元の作業に戻る
$ jj edit <元のchange-id>
# → stash不要、コンテキスト切り替えが瞬時
 
# hotfixがマージされた後、自分の作業をリベース
$ jj git fetch
$ jj rebase -d main@origin

# 開発中にリファクタリングの必要性に気づいた場合
 
# 現在の作業にリファクタリングとフィーチャーが混在
$ jj log
@  feature-commit  feat: 新機能（リファクタリング含む）
○  main
 
# splitでリファクタリングとフィーチャーを分離
$ jj split src/refactored-file.js
# → 1つ目のcommit: リファクタリング部分
# → 2つ目のcommit: フィーチャー部分
 
# メッセージを修正
$ jj describe -r @- -m "refactor: コード構造の改善"
$ jj describe -m "feat: 新機能の実装"
 
# リファクタリングを先にmainにマージすることも可能
$ jj bookmark create pr/refactor -r @-
$ jj git push --bookmark pr/refactor --allow-new

# 大きな変更を段階的にcommitに分割するワークフロー
 
# まず全ての変更を1つのcommitに入れる
$ jj describe -m "feat: 大規模な機能追加（WIP）"
 
# ファイル単位で分割
$ jj split src/types.ts
# → types.ts の変更が1つ目のcommit
$ jj describe -r @- -m "feat: 型定義の追加"
 
$ jj split src/auth.ts src/auth.test.ts
# → auth関連の変更が1つ目のcommit
$ jj describe -r @- -m "feat: 認証ロジックの実装"
 
# 残りの変更に最終的なメッセージを設定
$ jj describe -m "feat: UIコンポーネントの実装"
 
# 結果:
$ jj log
@  xxx  feat: UIコンポーネントの実装
○  yyy  feat: 認証ロジックの実装
○  zzz  feat: 型定義の追加
◆  main

# NG: jj newを使わずに全変更を1つのcommitに蓄積
$ vim src/auth.js
$ vim src/ui.js
$ vim src/api.js
$ jj describe -m "feat: 全部入り"
# → 巨大な1つのcommitになり、レビューしづらい
 
# OK: 論理的な単位でcommitを分ける
$ vim src/auth.js
$ jj describe -m "feat: 認証ロジック"
$ jj new
$ vim src/api.js
$ jj describe -m "feat: APIエンドポイント"
$ jj new
$ vim src/ui.js
$ jj describe -m "feat: UI実装"

# NG: commit ID（SHA-1）でrevisionを参照し続ける
$ jj rebase -r abc12345 -d main
# → rebase後にSHA-1が変わり、以前のIDが無効になる可能性
 
# OK: change IDで参照する
$ jj rebase -r rlvkpntz -d main
# → change IDはrebase後も変わらない

# NG: commitを編集するたびにブックマークを手動で移動
$ jj edit feature-auth
$ vim src/auth.js
$ jj new
$ jj bookmark set feature-auth -r ???  # どこに設定すべきか混乱
 
# OK: ブックマークは push 直前に設定する
$ jj edit rlvkpntz     # change IDで参照
$ vim src/auth.js
$ jj new
$ jj bookmark set feature-auth -r rlvkpntz  # push直前に設定
$ jj git push --bookmark feature-auth

# NG: 新しい作業を始めるのに jj edit を使う
$ jj edit main    # ← immutableで編集できない上、意図と異なる
 
# OK: 新しい作業は jj new で始める
$ jj new main     # mainの上に新しいcommitを作成
 
# NG: 過去のcommitを修正するのに jj new を使う
$ jj new rlvkpntz   # ← 新しいcommitが作成されてしまう
 
# OK: 過去のcommitの修正は jj edit を使う
$ jj edit rlvkpntz   # そのcommitを直接編集

# 演習1: 基本実装のテンプレート
class Exercise1:
    """基本的な実装パターンの演習"""
 
    def __init__(self):
        self.data = []
 
    def validate_input(self, value):
        """入力値の検証"""
        if value is None:
            raise ValueError("入力値がNoneです")
        return True
 
    def process(self, value):
        """データ処理のメインロジック"""
        self.validate_input(value)
        self.data.append(value)
        return self.data
 
    def get_results(self):
        """処理結果の取得"""
        return {
            'count': len(self.data),
            'data': self.data
        }
 
# テスト
def test_exercise1():
    ex = Exercise1()
    assert ex.process(1) == [1]
    assert ex.process(2) == [1, 2]
    assert ex.get_results()['count'] == 2
 
    try:
        ex.process(None)
        assert False, "例外が発生するべき"
    except ValueError:
        pass
 
    print("全テスト合格!")
 
test_exercise1()

# 演習2: 応用パターン
from typing import List, Dict, Optional
from datetime import datetime
 
class AdvancedExercise:
    """応用パターンの演習"""
 
    def __init__(self, max_size: int = 100):
        self._items: List[Dict] = []
        self._max_size = max_size
        self._created_at = datetime.now()
 
    def add(self, key: str, value: any) -> bool:
        """アイテムの追加（サイズ制限付き）"""
        if len(self._items) >= self._max_size:
            return False
        self._items.append({
            'key': key,
            'value': value,
            'timestamp': datetime.now().isoformat()
        })
        return True
 
    def find(self, key: str) -> Optional[Dict]:
        """キーによる検索"""
        for item in reversed(self._items):
            if item['key'] == key:
                return item
        return None
 
    def remove(self, key: str) -> bool:
        """キーによる削除"""
        for i, item in enumerate(self._items):
            if item['key'] == key:
                self._items.pop(i)
                return True
        return False
 
    def stats(self) -> Dict:
        """統計情報"""
        return {
            'total_items': len(self._items),
            'max_size': self._max_size,
            'usage_percent': len(self._items) / self._max_size * 100,
            'uptime': str(datetime.now() - self._created_at)
        }
 
# テスト
def test_advanced():
    ex = AdvancedExercise(max_size=3)
    assert ex.add("a", 1) == True
    assert ex.add("b", 2) == True
    assert ex.add("c", 3) == True
    assert ex.add("d", 4) == False  # サイズ制限
    assert ex.find("b")['value'] == 2
    assert ex.remove("b") == True
    assert ex.find("b") is None
    stats = ex.stats()
    assert stats['total_items'] == 2
    print("応用テスト全合格!")
 
test_advanced()

# 演習3: パフォーマンス最適化
import time
from functools import lru_cache
 
# 最適化前（O(n^2)）
def slow_search(data: list, target: int) -> int:
    """非効率な検索"""
    for i in range(len(data)):
        for j in range(i + 1, len(data)):
            if data[i] + data[j] == target:
                return (i, j)
    return (-1, -1)
 
# 最適化後（O(n)）
def fast_search(data: list, target: int) -> tuple:
    """ハッシュマップを使った効率的な検索"""
    seen = {}
    for i, num in enumerate(data):
        complement = target - num
        if complement in seen:
            return (seen[complement], i)
        seen[num] = i
    return (-1, -1)
 
# ベンチマーク
def benchmark():
    import random
    data = list(range(5000))
    random.shuffle(data)
    target = data[100] + data[4000]
 
    start = time.time()
    result1 = slow_search(data, target)
    slow_time = time.time() - start
 
    start = time.time()
    result2 = fast_search(data, target)
    fast_time = time.time() - start
 
    print(f"非効率版: {slow_time:.4f}秒")
    print(f"効率版:   {fast_time:.6f}秒")
    print(f"高速化率: {slow_time/fast_time:.0f}倍")
 
benchmark()

# デバッグ用ユーティリティ
import logging
import traceback
from functools import wraps
 
# ロガーの設定
logging.basicConfig(
    level=logging.DEBUG,
    format='%(asctime)s [%(levelname)s] %(name)s: %(message)s'
)
logger = logging.getLogger(__name__)
 
def debug_decorator(func):
    """関数の入出力をログ出力するデコレータ"""
    @wraps(func)
    def wrapper(*args, **kwargs):
        logger.debug(f"呼び出し: {func.__name__}(args={args}, kwargs={kwargs})")
        try:
            result = func(*args, **kwargs)
            logger.debug(f"戻り値: {func.__name__} -> {result}")
            return result
        except Exception as e:
            logger.error(f"例外発生: {func.__name__}: {e}")
            logger.error(traceback.format_exc())
            raise
    return wrapper
 
@debug_decorator
def process_data(items):
    """データ処理（デバッグ対象）"""
    if not items:
        raise ValueError("空のデータ")
    return [item * 2 for item in items]

# 設計判断の記録テンプレート
class ArchitectureDecisionRecord:
    """ADR (Architecture Decision Record) の作成"""
 
    def __init__(self, title: str):
        self.title = title
        self.context = ""
        self.decision = ""
        self.consequences = []
        self.alternatives = []
 
    def set_context(self, context: str):
        """背景と課題の記述"""
        self.context = context
        return self
 
    def set_decision(self, decision: str):
        """決定内容の記述"""
        self.decision = decision
        return self
 
    def add_consequence(self, consequence: str, positive: bool = True):
        """結果の追加"""
        self.consequences.append({
            'description': consequence,
            'type': 'positive' if positive else 'negative'
        })
        return self
 
    def add_alternative(self, name: str, reason_rejected: str):
        """却下した代替案の追加"""
        self.alternatives.append({
            'name': name,
            'reason_rejected': reason_rejected
        })
        return self
 
    def to_markdown(self) -> str:
        """Markdown形式で出力"""
        md = f"# ADR: {self.title}\n\n"
        md += f"## 背景\n{self.context}\n\n"
        md += f"## 決定\n{self.decision}\n\n"
        md += "## 結果\n"
        for c in self.consequences:
            icon = "✅" if c['type'] == 'positive' else "⚠️"
            md += f"- {icon} {c['description']}\n"
        md += "\n## 却下した代替案\n"
        for a in self.alternatives:
            md += f"- **{a['name']}**: {a['reason_rejected']}\n"
        return md

# チーム間のAPI契約定義
from dataclasses import dataclass
from typing import List, Optional
from enum import Enum
 
class Priority(Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"
 
@dataclass
class APIContract:
    """チーム間のAPI契約"""
    endpoint: str
    method: str
    owner_team: str
    consumers: List[str]
    sla_ms: int  # レスポンスタイムSLA
    priority: Priority
 
    def validate_sla(self, actual_ms: int) -> bool:
        """SLA準拠の確認"""
        return actual_ms <= self.sla_ms
 
    def to_openapi(self) -> dict:
        """OpenAPI形式で出力"""
        return {
            'path': self.endpoint,
            'method': self.method,
            'x-owner': self.owner_team,
            'x-consumers': self.consumers,
            'x-sla-ms': self.sla_ms
        }
 
# 使用例
contracts = [
    APIContract(
        endpoint="/api/v1/users",
        method="GET",
        owner_team="user-team",
        consumers=["order-team", "notification-team"],
        sla_ms=200,
        priority=Priority.HIGH
    ),
    APIContract(
        endpoint="/api/v1/orders",
        method="POST",
        owner_team="order-team",
        consumers=["payment-team", "inventory-team"],
        sla_ms=500,
        priority=Priority.CRITICAL
    )
]

# 以下は同等の操作
$ jj describe -m "feat: 新機能" && jj new
$ jj commit -m "feat: 新機能"

# Gitでのstash相当の操作（Jujutsu）
$ jj new main       # mainの上に新しいcommitを作成して作業開始
# → 前のworking copyの変更はそのまま確定済みcommitとして残る
# → 戻りたくなったら jj edit <change-id> で即座に戻れる

# jj edit: 過去のcommitを直接修正したい時
# → commitの内容を直接変更する
# → ファイルを編集してそのcommit自体を変更
$ jj edit rlvkpntz
$ vim src/auth.js    # commitの内容を修正
$ jj new
 
# jj squash: working copyの変更を親commitに統合したい時
# → 現在の作業を直前のcommitにまとめる
$ vim src/auth.js    # working copyで作業
$ jj squash          # 変更を親commitに統合
 
# jj squash --from --into: 任意の2つのcommit間で統合
$ jj squash --from bbb --into aaa

# ワークスペースの主な違い
# - Git worktree: 各worktreeが独立したブランチを持つ
# - jj workspace: リポジトリ全体の状態を共有、各workspaceは独立したworking copyを持つ
 
# ワークスペースの作成
$ jj workspace add ../my-project-test
# → 同じリポジトリを参照する新しいディレクトリが作成される
 
# ワークスペース間の操作
# workspace-1 で行った変更は、workspace-2 の jj log でも見える

# -r: 単一commitのみ移動
$ jj rebase -r B -d main
# B のみが main の子に。B の元の子は B の親に接続される
 
# -s: サブツリー全体を移動
$ jj rebase -s B -d main
# B とその全ての子孫が main の下に移動
 
# -b: ブランチのルートから先端まで
$ jj rebase -b tip -d main
# tip までの全commitが main の下に移動