この２つを直結しても実は何も良いことはない。
と云うか別に何も起きない。
と云うか混乱が起こるだけなのだ。
DOSのコマンドプロンプトでシェルのコマンドを打つようにプログラムを組むのは非常に難しい。
なぜなら一発で最初から最後まで一気に書き通せるなら、viの様なテキストエディタは全くの不要だからだ。
利点があるとすれば、ワザワザXMLなどを使って一本にコンパイルしたプログラムを無理ヤリに分割管理して悦に浸る様なマゾ的な管理が不要になることだ。ワークフレームは極当たり前の様に機能不足に陥り、際限の無い機能拡張を繰り返していくものなので5年以上も使い続けると何コレ？なシロモノになってしまう。そうワークフレームとはその場しのぎの足場に過ぎないのだから、長期運用なんて考えるだけ、おかしな話だ。
だが、そんな枠組みという縛りもなくコマンドラインからトリガ要因と一緒に実行するプログラムを登録するのは良いとして、電源が切れたら終わりでは大変なので、登録内容を保管するリポジトリィっぽいものが必要になる。面倒くさいので簡単に・・・
トリガー：L2ボタンを押した。
実行プログラム：メニューが左に流れる。
な形式のリポジトリィを作ってしまうと厄介なことになる。
そう複数のプロジェクトが混在するサーバーでは、やはり適用範囲（スコープ）が必要だ。
スコープ：PS4
状態：メニュー画面
トリガー：L2ボタンを押した。
実行プログラム：メニューが左に流れる。
ぐらいは必要だろう。
また開発途上を考慮すると、リリース・リポジトリィとテスト・リポジトリィに分けたり、履歴を残したり、色々必要になるだろう。
結果：お化けのようなリポジトリィの完成と云うことになる。⇒これが混乱。
だから、普通はその場しのぎのやっつけ仕事はシェルの様なインタープリタでかき捨て、速く動かしたいとか長く使いまわしたいものはコンパイラで固めてしまうのが無難だ。
そうすることで、長く使うものだけリポジトリィ化してしまえば、物量が減る。
だが、それも大量人員を投入するプロジェクトになれば、あまり意味はない。
ドレが長く使うものなのか、最初から決まってはいないからだ。
※全てが間に合わせのために作られたプロジェクトも存在する。（というか大半が該当する。
となれば、物事を簡単に、しかも応用が利くように、リポジトリィを組み立てなくてはいけない。
多分それが出来上がった時には『当たり前すぎる内容が書かれたレポジトリィ』で興味が湧くようなシロモノではないだろう。
しかし、それこそが『使えるレポジトリィ』で、奇を照らしても意味は無い。
そして、大抵は「運用マニュアル」がそれに該当する。
多分、先に「読める運用マニュアル」が書ければ、大抵のプロジェクトを成功に導くことができるだろう。