正式な計画というより個人用メモですが、せっかく詳細な手順まで書いたので公開してみます。読みにくい箇所があるのはご容赦ください。
フォントを作るために必要なのは、各Unicodeポイント（とVariation Sequence）が参照すべきグリフデータを決めることである。Glyphwikiから採用するグリフはUCS（uXXXX）（https://glyphwiki.org/wiki/GlyphWiki:prefixによると無印はそのうち廃止されるらしいので以降はjソース利用？）あるいはIVS(uXXXX-ue01XX)を使うことを原則とする。また、フォーマットはCIDキーを用いたOpenTypeフォントとし、可能な限りAJ1に準拠することを目指す。ビルドにはhttps://github.com/adobe-type-tools/afdkoを使用する。
まず、CMapにおいてAJ1の漢字CID（https://github.com/adobe-type-tools/Adobe-Japan1#kanji-glyphsやhttps://raw.githubusercontent.com/adobe-type-tools/Adobe-Japan1/master/aj17-kanji.txtを参照）を参照しているUnicodeのコードポイントについて、CID及びGlyphwiki実体を決定する。
CID+19130に31350,E0100が追加で割り当てられたため、「2つのIVSから参照されるものが19個ある。また非漢字CIDである+12869（ルビ用の"注"）を参照するIVSが1つあるため、AJ1のIVSは合計14684個となる。」が正しいGlyphWikiはJIS X 0213:2004の例示字形に準拠しており、"UniJIS2004-UTF32-H"というCMapを参照している限りはUCSとCID（に対応するIVS（2つある場合はその両方））でGlyphWiki実体が一致していることが期待される。
大半のグリフではそうなっており、これらは採用を確定し、該当CIDを割り当ててよい。ただ実用的にはCIDからIVSをルックアップするのは面倒なので、UCSグリフとaj1-グリフの相違（CMapを用いる）、IVSグリフとaj1-グリフの相違（こちらはhttps://www.unicode.org/ivd/data/2020-11-06/IVD_Sequences.txtを用いる）をそれぞれ検出する。そして、両方で相違が出なかったCIDを参照しているコードポイントはUCSグリフで埋め、CMapの内容はそのまま使う。
また、aj1-のみが違う実体を指しているがUCSとIVSのグリフは一致しているもの（これは両方で相違が検出されることになる）も採用してよい(2021/11/10時点では、"毛"と"毬"のみ)。
ただ、不一致があるものも多数存在し、康熙部首をはじめとして2021/11/10時点で300個以上あった（https://glyphwiki.org/wiki/Group:turgenev_異体字シーケンス・Adobe-Japan1に関する矛盾 ）。これらは全てUCSとaj1-の不一致であり、aj1-とIVSは一致していたため、以後そうであると仮定して述べる。これらは以下に分類できる。
いずれにしても、どちらかといえば規格票の要素を必要十分に満たした標準的なデザインを採用しているUCSのデザインをデフォルトとして採用するのが望ましい場合が多い（先ほどのu8481のようにUCSグリフが孤立していてaj1-のほうはHanyo_Denshi等のIVSとも一致しているというような状況であればaj1-のほうを採用してもよさそう）（以下、UCSグリフを採用すると仮定して述べるが、状況によって適宜aj1-などのグリフを採用することももちろん可能である）。
まず3.において片方だけ収録する場合は（両方収録する場合は2に同じ）、GlyphWikiのUCSグリフをAJ1のIVSグリフとしても使用することにし、（CMapの参照先の）CIDをUCSグリフで埋め、該当コードポイントのCMapの内容はそのまま採用する（なお、仮に複数IVSから参照されるCIDであればそのIVSグリフを両方ともUCSで置き換えることになる）。
1.と2.については、コードポイントのデフォルトグリフがAJ1と異なる字形になるため、CMapを変更する必要がある。まず、これらのコードポイントに与えられたCIDをAJ1のIVSグリフで埋める。さらに1.についてのみ、CMap上でのこれらのコードポイントの参照先のCIDを、GlyphWikiのUCSグリフと字形が一致しているほうのCIDに書き換える。そして2.については、コードポイントのUCSグリフの採用が確定し、これに割り当てるCIDをCMapに指定することになるが、この時点でCIDの空きが予測できないため具体的なCMapの変更は後回しにする。
ここまででCMapで参照されている漢字CIDが全て埋まる。
次にAJ1のIVSに対応する。なおAFDKOでフォントをビルドする際、IVSやSVSなどは通常のUnicodeコードポイントと異なり別途Sequenceファイルで指定する（書式はhttps://github.com/adobe-type-tools/Adobe-Japan1/blob/master/Adobe-Japan1_sequences.txt とか https://github.com/adobe-fonts/source-han-sans/blob/master/SourceHanSans_JP_sequences.txt を参照）。IVSグリフとaj1-グリフの相違については既に確認した。特にAJ1のIVSのうちCMapに含まれる漢字CIDを参照するものについては先ほど既に採用グリフが決定しておりCIDも埋まっているためこれ以上の対応は必要ない（Sequenceファイルもそのままでよい）。複数のIVSがCIDを共有している18組が同じ実体を持っていることも、先ほど相違が出なかったのであればそれで確認できる。そして、CMapに含まれないCIDについては2021/11/10時点で相違が無かったため対応は必要ない（あったとしても字形に大差がなければどちらか好きな方を採用してよい）。ただしこのタイミングで、CIDを共有してはいないが字形が同一であるべき3組が同一の実体を持っているかを手動で確認する必要がある（組になるCIDのうち片方はCMapに含まれていないことに注意）（これも2021/11/10時点では問題なし）。以上を済ませた上で、CIDの浪費を避け（て、かつAJ1のCIDとの整合性を維持す）るため、AJ1用の各IVS（UCSグリフでの置き換えを反映させたもの）がGlyphwiki上で異なる実体を指しているかどうかチェックする。もし前述の18+3(+1)個以外に同じ実体を指しているものがあれば、それらは一つのCIDに統合してもいいのかもしれない（ただし2021/11/10時点では18+3のみだったし、普通はないはずである）（仮に統合する場合featureファイルの書き換えが必要になる）。特にない場合、ここで今まで埋まっていないAJ1の漢字CID全てとCID+12869を、対応するIVSのGlyphWikiのグリフで埋める（複数IVSから参照されるCIDならどちらか一方を見ればよい）。やはりSequenceファイルを変更する必要はない。これによりAJ1のIVSへの対応は完了する。